pay_...) and goes through a lifecycle of statuses until it is processed at the
gateway or via bank transfer (in the case of boleto).
This page covers the retrieval and manual decision endpoints for refunds: fetch by ID, list by
transaction or by payment, and approve or decline a pending refund.
Creating a refund is not done here. To open a refund request, use the refund endpoint in
Payments (
POST /transactions/{transactionId}/payments/{paymentId}/refund).
This page documents what happens after the refund already exists.x-api-key header. See Authentication.
Endpoints
| Method | Route | Description |
|---|---|---|
GET | /refunds/{id} | Fetch a refund by ID |
GET | /refunds/transaction/{transactionId} | List all refunds for a transaction |
GET | /refunds/payment/{paymentId} | List all refunds for a payment |
POST | /refunds/{id}/approve | Approve a pending refund and send it for processing |
POST | /refunds/{id}/refuse | Decline a pending refund |
Refund statuses
Thestatus field indicates where in the lifecycle the refund currently is. Terminal statuses
(no further transitions) are refunded, refused, and failed.
| Status | Meaning |
|---|---|
pending | Awaiting manual decision (approve or decline) |
approved | Approved; transitioning to processing |
processing | Being processed at the gateway |
refunded | Refund completed (terminal) |
refused | Request declined (terminal) |
failed | Processing failed (terminal) |
awaiting_bank_details | Boleto: waiting for the customer to provide bank account details |
bank_details_received | Boleto: bank details received, ready for transfer |
invalid_bank_details | Boleto: bank details invalid; a new request for details has been sent |
ted_processing | Boleto: bank transfer (PIX/TED) in progress |
Company auto-approve. Each company has an automatic refund approval setting (enabled by
default). With auto-approve on, a card refund is created, approved, and processed immediately —
meaning it may be born in
approved/processing and never pass through pending. With
auto-approve off, the refund starts in pending and must be approved via the endpoints below.Boleto flow. Boleto refunds are not reversed at the gateway: the amount is returned via bank
transfer (PIX/TED), so the customer’s bank details must be collected. For this reason, when a boleto
refund is approved, it moves to
awaiting_bank_details instead of processing. Once the details
arrive (bank_details_received), the transfer is processed (ted_processing) until completion
(refunded). Bank detail collection happens via a link/invitation sent to the customer, outside
this set of endpoints.Fetch refund by ID
Refund ID (prefix
ref_).Refund ID (
ref_...).Transaction ID (
txn_...).ID of the refunded payment (
pay_...).Refunded amount in cents (e.g.,
4990 = R$ 49.90).Currency. Always
BRL.Current refund status (see the status table above).
Reason provided when the refund was created.
Identifier of whoever requested the refund.
Source of the request:
api, admin, customer, or gateway.Payment method of the refunded payment (e.g.,
credit_card, boleto). Can be null.Failure reason when
status is failed. Otherwise null.Who approved or declined the refund.
null while not yet reviewed.Date/time of the review (ISO 8601).
null while not yet reviewed.Date/time the refund was completed (ISO 8601).
null while not yet completed.Creation date/time (ISO 8601).
Date/time of the last update (ISO 8601).
Soft-deletion date/time. Normally
null.| Status | When it occurs |
|---|---|
404 | Refund not found |
List refunds by transaction
Transaction ID (prefix
txn_).Page number (starts at 1).
Items per page. Minimum
1, maximum 100.List of refunds (same structure as Fetch refund by ID).
List refunds by payment
Payment ID (prefix
pay_).Page number (starts at 1).
Items per page. Minimum
1, maximum 100.data + pagination) as the by-transaction endpoint.
Approve refund
awaiting_bank_details, waiting for
the customer’s bank account information.
Refund ID (prefix
ref_).Idempotency-Key header does
not produce a duplicate effect. See Conventions.
Unique key to ensure the approval is applied only once.
| Status | When it occurs |
|---|---|
404 | Refund not found |
409 | The refund cannot be approved in its current status (e.g., already in a terminal state) |
Decline refund
refused.
Refund ID (prefix
ref_).Reason for the decline. When provided, must be between 1 and 4000 characters. The field is
validated but does not replace the original
reason of the refund in the response (which
retains the reason provided at creation time).Idempotency-Key header for safe retries.
Unique key to ensure the decline is applied only once.
| Status | When it occurs |
|---|---|
404 | Refund not found |
409 | The refund cannot be declined in its current status (e.g., already in a terminal state) |
See also
Payments
Create a refund by reversing a payment.
Transactions
Understand the transaction that originated the payment.
Chargebacks
Reversals initiated by the card issuer.
Errors
Error format and how to handle them.

