txn_) es el objeto central de la Core API: agrupa lo que el comprador está
pagando (los items) y cómo está pagando (los payments). Cada payment representa un
intento/método de pago (tarjeta, boleto o Pix). El estado de la transacción nunca se define
directamente — siempre es calculado a partir del estado agregado de sus payments.
Todas las rutas requieren el header
x-api-key (su clave de sandbox). Consulte
Autenticación. Los ejemplos a continuación usan la URL base de sandbox
https://api.sandbox.z2pay.com.Endpoints
| Método | Ruta | Descripción |
|---|---|---|
GET | /transactions | Lista paginada de transacciones, con filtros |
GET | /transactions/:id | Obtiene una transacción con sus payments e ítems |
GET | /transactions/:id/items | Lista únicamente los ítems de la transacción |
POST | /transactions | Crea una nueva transacción |
POST | /transactions/:id/refund | Revierte todos los payments pagados de la transacción |
Estado de la transacción
El estado se deriva de los payments mediante un cálculo centralizado. En resumen (reglas evaluadas en orden):Cómo se calcula el estado
Cómo se calcula el estado
- Los payments con estado
replacedodeletedse ignoran en el cálculo. - Si la transacción tiene valor cero →
paid. - Si no hay payment activo →
pending. - Si todos los payments no fallidos son
refused→refused. Si todos sonfailed/expired→failed. - Entre los payments válidos (excluyendo
refused/failed/expired): si todos sonchargeback→chargeback; si todos soncanceled→canceled; si todos sonin_protest→in_protest. - Si el monto efectivamente pagado cubre el total de la transacción →
paid(incluso con reversión parcial de excedente). - Si hay monto pagado (> 0) menor que el total y sin actividad de reversión →
partially_paid. - Si las liquidaciones están todas en ciclo de reversión: todas
refunded→refunded; algunapartially_refunded→partially_refunded; en caso contrario →waiting_refund. - Queda monto pagado/retenido junto con reversión activa →
partially_refunded. - El monto revertido cubre el total →
refunded. - Sin nada pagado y el monto en espera de pago cubre el total →
waiting_payment. - Si ninguno de los anteriores aplica →
pending.
| Estado | Significado |
|---|---|
pending | Creada, sin pago confirmado ni en espera de pago definido |
waiting_payment | En espera de pago (boleto/Pix emitido, o payment creado sin procesar) |
partially_paid | Parte del monto fue pagada, pero no el total |
paid | Monto total pagado |
refused | Pago rechazado |
failed | Fallo terminal en el gateway |
canceled | Cancelada |
waiting_refund | Reversión solicitada, en espera de procesamiento |
partially_refunded | Parte del monto pagado fue revertida |
refunded | Monto total revertido |
chargeback | Sufrió un chargeback |
in_protest | En protesta (disputa de chargeback en curso) |
Como el estado agrega los payments, una transacción con más de un payment (ej.: dos tarjetas, o
Pix + tarjeta) puede pasar por estados intermedios como
partially_paid o partially_refunded.Crear transacción
POST /transactions
Crea una transacción. Siempre debe indicar el cliente y al menos un ítem. Los payments
son opcionales:
- Con
paymentsy datos de procesamiento (creditCard/boleto/pix) → los payments se procesan inmediatamente en el gateway. - Con
paymentssin datos de procesamiento → los payments quedan en espera de procesamiento. - Sin
payments→ la transacción queda enwaiting_payment.
Endpoint idempotente. Envíe el header
Idempotency-Key (TTL de 7 días) para garantizar que los
reenvíos de la misma solicitud no creen transacciones duplicadas. Consulte Convenciones.Reglas de negocio importantes
Cuerpo de la solicitud
ID de un cliente existente (
cust_). Mutuamente exclusivo con customer.Datos del cliente en línea. Mutuamente exclusivo con
customerId.Su código de referencia para la transacción (1 a 255 caracteres). Úselo para correlacionar con su
sistema.
Lista de ítems (mínimo 1).
Métodos de pago. Si se omite, la transacción queda en
waiting_payment.Código de moneda ISO 4217 (3 letras, ej.:
BRL). Por defecto: configuración de la company o BRL.URL de redirección tras el pago (URL válida).
URL para recibir notificaciones de esta transacción (URL válida). Consulte Webhooks.
IP del comprador.
Metadatos libres de la transacción (objeto clave-valor). Permite búsqueda mediante el filtro
metadataSearch.Número máximo de cuotas permitido (entero, mínimo 1).
Override de la configuración de enrutamiento (opcional).
Ejemplo: crear transacción con Pix
El ítem cuesta
9990 centavos (R$ 99,90) y el payment suma 9990 — las sumas coinciden, por lo
que la solicitud es válida.Respuesta
201 Created. El ejemplo de JSON es ilustrativo — verifique los campos reales en la respuesta de su entorno.Ejemplo: crear y cobrar con tarjeta tokenizada
Dos ítems de
5000 × 2 = 10000 centavos; el payment suma 10000. Las sumas coinciden. La
tarjeta se envía como token (generado por el Tokenizer) — nunca envíe
datos en bruto de la tarjeta a la Core API.Listar transacciones
GET /transactions
Devuelve una lista paginada. Todos los filtros son opcionales y pueden combinarse.
Parámetros de query
Página (paginación). Consulte Convenciones.
Ítems por página.
Filtra por estado de la transacción.
Filtra por moneda.
Filtra por método de pago.
ID de la transacción (búsqueda parcial, ILIKE).
Filtra por su código de referencia.
Filtra por nombre del cliente.
Filtra por correo electrónico del cliente.
Filtra por documento del cliente.
Búsqueda combinada en nombre/correo/documento del cliente.
Lista de IDs de destinatarios (separados por coma) que deben aparecer en algún split de la transacción.
Búsqueda textual en cualquier valor almacenado en
additionalInfo.Búsqueda genérica.
Fecha inicial. ISO 8601 con timezone (ej.:
2026-06-01T00:00:00.000Z).Fecha final. ISO 8601 con timezone.
Campo de fecha utilizado por
startDate/endDate. Valores: createdAt, paidAt, refundedAt,
canceledAt, chargedbackAt, protestedAt.Campo de ordenamiento. Valores:
createdAt, paidAt, amount, status, customerName.Dirección del ordenamiento. Valores:
asc o desc.Ejemplo
El formato exacto del envelope de paginación está en Convenciones. El JSON
anterior es ilustrativo.
Obtener transacción por ID
GET /transactions/:id
Devuelve los datos completos de la transacción, incluyendo sus payments e items.
ID de la transacción (
txn_).Estado calculado de la transacción. Consulte la tabla en Estado de la transacción.
Ítems de la transacción.
404. Consulte Errores.
Listar ítems de la transacción
GET /transactions/:id/items
Devuelve únicamente los ítems (productos/servicios) de la transacción, dentro de una clave data.
ID de la transacción (
txn_).404.
Revertir transacción
POST /transactions/:id/refund
Crea solicitudes de refund para todos los payments pagados de la transacción de una sola vez. El
comportamiento de aprobación depende de la configuración refund.auto_approve de la company
(por defecto: activado):
- Con auto-approve: el refund se crea, aprueba y procesa en el gateway inmediatamente.
- Sin auto-approve: los refunds quedan pendientes de aprobación manual.
ID de la transacción (
txn_).Motivo de la reversión (1 a 4000 caracteres).
Estados posibles
200— refunds creados y procesados.404— transacción no encontrada.409— ningún payment revertible encontrado (ej.: ningún payment está pagado).
Ver también
Payments
Detalles de cada método de pago dentro de la transacción.
Refunds
Reversión de un payment específico y reversiones parciales.
Tokenizer
Genere el
token de la tarjeta antes de crear la transacción.Split
Configure transferencias por payment con
split o splitId.Customers
Registre clientes para reutilizarlos mediante
customerId.Webhooks
Reciba notificaciones de cambio de estado de la transacción.

