# 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`) |

::: tip 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](/es/pix-cashout-status) 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

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

## Respuesta de Exito -- 200

```json
{
  "worked": true,
  "receipt": {
    "transaction_id": "PIXOUT20260309a1b2c3d4e5f6",
    "end_to_end_id": "E46026562202603091530abcdef01",
    "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": "Monetarie",
      "cnpj": "46.026.562/0001-05",
      "ispb": "46026562"
    }
  }
}
```

## 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 | Direccion del movimiento en el comprobante: `outbound`, `inbound`, `credit` o `debit` |
| 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](/es/pix-cashout-status#valores-del-campo-status) |
| 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 || t.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` |

::: tip 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`.
:::

::: danger El comprobante **NO** retorna los campos de contraparte
Este endpoint **explicitamente omite** los siguientes campos que aparecen en otras consultas (ej: [`GET /transactions/:id`](/es/pix-cashout-status), [`GET /transactions/e2e/:e2e_id`](/es/pix-cashout-e2e), [Consulta PIX IN por ID](/es/pix-cashin-status)):

- `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`.
:::

::: info 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

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