Comprobante Cash-Out

Obtiene el comprobante de una transaccion PIX en formato estructurado, con datos formateados para exhibicion al usuario final.

Endpoint

GET /api/external/transactions/:id/receipt

Headers

Header	Tipo	Obligatorio	Descripcion
Authorization	String	Si	ApiKey {client_id}:{client_secret}

Path Parameters

Parametro	Tipo	Obligatorio	Descripcion
id	String	Si	ID de la transaccion (transaction_id)

Disponibilidad

El comprobante consulta la tabla transactions — disponible para transacciones con status final (settled o failed). Transacciones aun en procesamiento (estado processing en outbound_requests, stage 1–2) retornan 404 aqui; consulte primero via GET /transactions/:id y aguarde la promocion para transactions antes de solicitar el comprobante.

QRs pagados aparecen en el comprobante de la transaccion real linkeada (no del QR en si) — use el transaction_id retornado en el webhook pix.charge.paid o via consulta.

Ejemplo

curl -X GET https://api.owem.com.br/api/external/transactions/PIXOUT20260309a1b2c3d4e5f6/receipt \
  -H "Authorization: ApiKey $CLIENT_ID:$CLIENT_SECRET"

Respuesta de Exito -- 200

{
  "worked": true,
  "receipt": {
    "transaction_id": "PIXOUT20260309a1b2c3d4e5f6",
    "end_to_end_id": "E37839059202603091530abcdef01",
    "external_id": "order-9876",
    "type": "pix",
    "direction": "outbound",
    "status": "settled",
    "amount": 300000,
    "amount_formatted": "R$ 30,00",
    "fee_amount": 350,
    "fee_formatted": "R$ 0,035",
    "net_amount": 300350,
    "description": "Pagamento fornecedor",
    "counterparty_name": "Joao Silva",
    "recipient_key": "12345678901",
    "created_at": "2026-03-09T15:30:00Z",
    "completed_at": "2026-03-09T15:30:02Z",
    "institution": {
      "name": "Owem Pay",
      "cnpj": "37.839.059/0001-88",
      "ispb": "37839059"
    }
  }
}

Campos del Comprobante

El objeto receipt contiene exactamente 17 campos (incluyendo el sub-objeto institution). Este es el inventario completo — no hay otros campos retornados por este endpoint:

#	Campo	Tipo	Descripcion
1	receipt.transaction_id	String	Identificador unico de la transaccion
2	receipt.end_to_end_id	String	Identificador End-to-End en el SPI/BACEN
3	receipt.external_id	String	ID externo proporcionado por el cliente en el cash-out. null cuando no informado, o cuando el ID externo no paso el sanitize (max 128 chars, solo a-zA-Z0-9._:-)
4	receipt.type	String	Tipo de la transaccion. Valores observados: pix (default), pix_return (devolucion). Rows legacy pueden retornar otros valores (ted, tef, etc.) — el controller hace passthrough de t.type sin filtrar
5	receipt.direction	String	outbound o inbound cuando el campo esta persistido en transactions.direction. Cuando nil, el controller hace fallback para Helpers.infer_direction/2, que retorna solo credit (cuenta objetivo es la del receptor) o debit (cuenta objetivo es la del pagador) — nunca inbound/outbound en el camino de inferencia
6	receipt.status	String	Status de la transaccion resuelto via Helpers.format_status/1. Valores posibles: settled (normal), pending (transactions.status=2), failed (status=3), completed (fallback legacy para rows donde status=1 y payment_status=nil). Vea valores posibles
7	receipt.amount	Integer	Valor en unidades base (÷ 10.000 para reales). 300000 = R$ 30,00
8	receipt.amount_formatted	String	Valor formateado en reales (R$ 30,00)
9	receipt.fee_amount	Integer	Tarifa en unidades base
10	receipt.fee_formatted	String	Tarifa formateada en reales (incluye sub-centavos cuando aplicable, ej: R$ 0,035)
11	receipt.net_amount	Integer	Valor neto en unidades base (fallback `t.net_amount
12	receipt.description	String	Descripcion de la transferencia
13	receipt.counterparty_name	String	Nombre de la contraparte (pagador o receptor, conforme direction)
14	receipt.recipient_key	String	Clave PIX del destinatario (solo salidas)
15	receipt.created_at	String	Fecha de creacion (ISO 8601, viniendo de t.started_at)
16	receipt.completed_at	String	Fecha de conclusion (ISO 8601, viniendo de t.finished_at)
17	receipt.institution	Object	Datos de la institucion emisora — sub-objeto con name, cnpj (formateado XX.XXX.XXX/XXXX-XX) e ispb

Campos formateados

El comprobante incluye campos _formatted con valores ya convertidos a reales (ej: R$ 30,00, R$ 0,035 para tarifas sub-centavo). Use estos campos para exhibicion al usuario. Use los campos numericos (amount, fee_amount, net_amount) para calculos. No hay net_amount_formatted — derive la exhibicion del amount_formatted + fee_formatted.

El comprobante NO retorna los campos de contraparte

Este endpoint explicitamente omite los siguientes campos que aparecen en otras consultas (ej: GET /transactions/:id, GET /transactions/e2e/:e2e_id, Consulta PIX IN por ID):

• payer_document
• recipient_document
• payer_ispb
• payer_bank_name

Si su integracion asumio esos campos en /receipt basada en ejemplos de cash-in, ella esta leyendo undefined en tiempo de ejecucion. Para acceso a los datos completos de la contraparte (documentos, ISPB, nombre del banco), use GET /transactions/:id o GET /transactions/e2e/:e2e_id — ambos usan la tabla transactions (misma fuente) pero exponen el shape completo via Helpers.format_external_transaction/1.

Comprobante vs consulta por ID

El endpoint /receipt y el endpoint GET /transactions/:id usan la misma fuente (transactions) pero retornan shapes distintos:

• /receipt (17 campos): foco en exhibicion — agrega _formatted, institution, y omite los 4 campos de contraparte listados arriba.
• GET /transactions/:id (18 campos en el shape "settled"): foco en integracion — incluye contexto completo de la contraparte (payer_document, recipient_document, payer_ispb, payer_bank_name, counterparty_name) util para conciliacion, y omite los campos _formatted.

Use /receipt para generar PDFs/emails/pantallas de confirmacion al usuario final. Use GET /transactions/:id para integracion programatica y reconciliacion interna.

Respuesta de Error -- 404

{
  "worked": false,
  "detail": "Transação não encontrada"
}