pay_...) y atraviesa un ciclo de estados hasta ser
procesado en el gateway o mediante transferencia (en el caso de boleto).
Esta página cubre los endpoints de consulta y decisión manual de refunds: buscar por ID, listar
por transacción o por pago, y aprobar o rechazar un refund pendiente.
La creación de un refund no se realiza aquí. Para abrir una solicitud de reembolso, utiliza el endpoint de
contracargo en Payments (
POST /transactions/{transactionId}/payments/{paymentId}/refund).
Esta página documenta lo que ocurre después de que el refund ya existe.x-api-key. Consulta Autenticación.
Endpoints
| Método | Ruta | Descripción |
|---|---|---|
GET | /refunds/{id} | Obtiene un refund por ID |
GET | /refunds/transaction/{transactionId} | Lista los refunds de una transacción |
GET | /refunds/payment/{paymentId} | Lista los refunds de un pago |
POST | /refunds/{id}/approve | Aprueba un refund pendiente y lo envía a procesamiento |
POST | /refunds/{id}/refuse | Rechaza un refund pendiente |
Estados del refund
El campostatus indica en qué punto del ciclo se encuentra el refund. Los estados terminales (que no cambian)
son refunded, refused y failed.
| Status | Significado |
|---|---|
pending | Esperando decisión manual (aprobar o rechazar) |
approved | Aprobado; en transición hacia el procesamiento |
processing | En proceso en el gateway |
refunded | Reembolso completado (terminal) |
refused | Solicitud rechazada (terminal) |
failed | Error en el procesamiento (terminal) |
awaiting_bank_details | Boleto: esperando que el cliente informe los datos bancarios |
bank_details_received | Boleto: datos bancarios recibidos, listo para la transferencia |
invalid_bank_details | Boleto: datos bancarios inválidos; nueva solicitud de datos enviada |
ted_processing | Boleto: transferencia (PIX/TED) en procesamiento |
Auto-approve de la company. Cada empresa tiene una configuración de aprobación automática de reembolsos
(habilitada por defecto). Con auto-approve activado, un refund de tarjeta se crea, aprueba y procesa
de inmediato — es decir, puede nacer directamente en
approved/processing y nunca pasar por pending.
Con auto-approve desactivado, el refund nace en pending y debe ser aprobado mediante los endpoints que se describen a continuación.Flujo de boleto. El boleto no se contracarga en el gateway: el valor se devuelve mediante transferencia
bancaria (PIX/TED), por lo que es necesario recopilar los datos bancarios del cliente. Por eso, un refund de
boleto, al ser aprobado, pasa a
awaiting_bank_details en lugar de processing. Una vez que los datos
llegan (bank_details_received), la transferencia se procesa (ted_processing) hasta completarse
(refunded). La recopilación de datos bancarios ocurre a través de un enlace/invitación enviado al cliente, fuera de este
conjunto de endpoints.Buscar refund por ID
ID del refund (prefijo
ref_).ID del refund (
ref_...).ID de la transacción (
txn_...).ID del pago contracargado (
pay_...).Valor reembolsado, en centavos (ej.:
4990 = R$ 49,90).Moneda. Siempre
BRL.Estado actual del refund (ver tabla de estados arriba).
Motivo informado en la creación del refund.
Identificador de quien solicitó el refund.
Origen de la solicitud:
api, admin, customer o gateway.Método del pago contracargado (ej.:
credit_card, boleto). Puede ser null.Motivo del error cuando
status es failed. En caso contrario, null.Quién aprobó/rechazó el refund.
null mientras no haya sido revisado.Fecha/hora de la revisión (ISO 8601).
null mientras no haya sido revisado.Fecha/hora de la conclusión del reembolso (ISO 8601).
null mientras no haya concluido.Fecha/hora de creación (ISO 8601).
Fecha/hora de la última actualización (ISO 8601).
Fecha/hora de eliminación lógica. Normalmente
null.| Status | Cuándo ocurre |
|---|---|
404 | Refund no encontrado |
Listar refunds de una transacción
ID de la transacción (prefijo
txn_).Página (comienza en 1).
Ítems por página. Mínimo
1, máximo 100.Lista de refunds (misma estructura que Buscar refund por ID).
Listar refunds de un pago
ID del pago (prefijo
pay_).Página (comienza en 1).
Ítems por página. Mínimo
1, máximo 100.data + pagination) que el endpoint por transacción.
Aprobar refund
awaiting_bank_details).
ID del refund (prefijo
ref_).Idempotency-Key no genera
un efecto duplicado. Consulta Convenciones.
Clave única para garantizar que la aprobación no se aplique más de una vez.
| Status | Cuándo ocurre |
|---|---|
404 | Refund no encontrado |
409 | El refund no puede aprobarse en el estado actual (ej.: ya es terminal) |
Rechazar refund
refused.
ID del refund (prefijo
ref_).Motivo del rechazo. Cuando se envía, debe tener entre 1 y 4000 caracteres. El campo es validado, pero
no reemplaza el
reason original del refund en la respuesta (que conserva el motivo informado en la creación).Idempotency-Key para reenvíos seguros.
Clave única para garantizar que el rechazo no se aplique más de una vez.
| Status | Cuándo ocurre |
|---|---|
404 | Refund no encontrado |
409 | El refund no puede rechazarse en el estado actual (ej.: ya es terminal) |
Ver también
Payments
Crea un refund contracargando un pago.
Transactions
Comprende la transacción que originó el pago.
Chargebacks
Contracargos iniciados por el emisor de la tarjeta.
Errores
Formato de los errores y cómo gestionarlos.

