Saltar al contenido principal
GET
Get a Pix refund by ID

Autorizaciones

Authorization
string
header
requerido

JWT bearer token issued by the identity provider.

Encabezados

X-Account-Id
string
requerido

Account UUID

Ejemplo:

"019606a1-3b4c-7d8e-9f01-234567890abc"

Parámetros de ruta

id
string
requerido

Refund UUID

Ejemplo:

"0196080a-1234-7890-abcd-ef0123456789"

Respuesta

OK

amount
string
requerido
Ejemplo:

"100.00"

createdAt
string<date-time>
requerido
Ejemplo:

"2026-05-06T10:45:00Z"

id
string
requerido
Ejemplo:

"019606b1-3b4c-7d8e-9f01-234567890dee"

originalEndToEndId
string
requerido
Ejemplo:

"E12345678202605061030abcdef12345"

reasonCode
string
requerido
Ejemplo:

"MD06"

status
string
requerido
Ejemplo:

"COMPLETED"

type
string
requerido
Ejemplo:

"OUTBOUND"

updatedAt
string<date-time>
requerido
Ejemplo:

"2026-05-06T10:45:30Z"

accountId
string
Ejemplo:

"019606a0-1a2b-7c3d-8e4f-567890123abc"

deletedAt
string<date-time>
description
string
Ejemplo:

"Estorno solicitado pelo pagador"

ledger
object
metadata
object
returnEndToEndId
string
Ejemplo:

"D12345678202605061045fedcba54321"

feeCharge
object

Fee the ledger reported on the create that moved the refund's money. Absent when no fee answer was recorded for this refund (its ledger create never landed, an error was logged at the time, or the refund was created before fees were read back); {"applied": false} when the ledger reported that no fee was charged; the full object when it charged one. A refund carries no ledger.revert field and needs none here: a FAILED refund that carries feeCharge was reverted first -- every path that writes a refund FAILED after its ledger create landed reverts the debit before marking it (a revert that does not complete leaves the refund PROCESSING), and every other path fails before any create -- so the fee was returned with the amount; applied reports what the create did and the object records the create.