txn_) é o objeto central da Core API: ela agrupa o que o comprador está pagando
(os items) e como está pagando (os payments). Cada payment representa uma tentativa/forma de
pagamento (cartão, boleto ou Pix). O status da transação nunca é definido diretamente — ele é
sempre calculado a partir do estado agregado dos seus payments.
Todas as rotas exigem o header
x-api-key (sua chave de sandbox). Veja
Autenticação. Os exemplos abaixo usam a base URL de sandbox
https://api.sandbox.z2pay.com.Endpoints
| Método | Rota | Descrição |
|---|---|---|
GET | /transactions | Lista paginada de transações, com filtros |
GET | /transactions/:id | Busca uma transação com seus payments e items |
GET | /transactions/:id/items | Lista apenas os items da transação |
POST | /transactions | Cria uma nova transação |
POST | /transactions/:id/refund | Estorna todos os payments pagos da transação |
Status da transação
O status é derivado dos payments por um cálculo central. Em resumo (regras avaliadas em ordem):Como o status é calculado
Como o status é calculado
- Payments com status
replacedoudeletedsão ignorados no cálculo. - Se a transação tem valor zero →
paid. - Se não há payment ativo →
pending. - Se todos os payments não-falhos são
refused→refused. Se todos sãofailed/expired→failed. - Entre os payments válidos (excluindo
refused/failed/expired): se todos sãochargeback→chargeback; se todos sãocanceled→canceled; se todos sãoin_protest→in_protest. - Se o valor efetivamente pago cobre o total da transação →
paid(mesmo com estorno parcial de excedente). - Se há valor pago (> 0) menor que o total e sem atividade de estorno →
partially_paid. - Se as legs liquidadas estão todas em ciclo de estorno: todas
refunded→refunded; algumapartially_refunded→partially_refunded; caso contrário →waiting_refund. - Sobrou valor pago/retido junto com estorno ativo →
partially_refunded. - Valor estornado cobre o total →
refunded. - Sem nada pago e o valor aguardando pagamento cobre o total →
waiting_payment. - Caso nenhum dos anteriores →
pending.
| Status | Significado |
|---|---|
pending | Criada, sem pagamento confirmado nem aguardando pagamento definido |
waiting_payment | Aguardando pagamento (boleto/Pix emitido, ou payment criado sem processar) |
partially_paid | Parte do valor foi pago, mas não o total |
paid | Valor total pago |
refused | Pagamento recusado |
failed | Falha terminal no gateway |
canceled | Cancelada |
waiting_refund | Estorno solicitado, aguardando processamento |
partially_refunded | Parte do valor pago foi estornada |
refunded | Valor total estornado |
chargeback | Sofreu chargeback |
in_protest | Em protesto (disputa de chargeback em andamento) |
Como o status agrega os payments, uma transação com mais de um payment (ex.: dois cartões, ou
Pix + cartão) pode passar por estados intermediários como
partially_paid ou partially_refunded.Criar transação
POST /transactions
Cria uma transação. Você sempre informa o cliente e pelo menos um item. Os payments
são opcionais:
- Com
paymentse dados de processamento (creditCard/boleto/pix) → os payments são processados imediatamente no gateway. - Com
paymentssem dados de processamento → os payments ficam aguardando processamento. - Sem
payments→ a transação ficawaiting_payment.
Endpoint idempotente. Envie o header
Idempotency-Key (TTL de 7 dias) para garantir que reenvios
da mesma requisição não criem transações duplicadas. Veja Convenções.Regras de negócio importantes
Corpo da requisição
ID de um cliente existente (
cust_). Mutuamente exclusivo com customer.Dados do cliente inline. Mutuamente exclusivo com
customerId.Seu código de referência para a transação (1 a 255 caracteres). Use para correlacionar com seu
sistema.
Lista de items (mínimo 1).
Formas de pagamento. Se omitido, a transação fica
waiting_payment.Código de moeda ISO 4217 (3 letras, ex.:
BRL). Default: configuração da company ou BRL.URL de redirecionamento após o pagamento (URL válida).
IP do comprador.
Metadados livres da transação (objeto chave-valor). Pesquisável via filtro
metadataSearch.Número máximo de parcelas permitido (inteiro, mínimo 1).
Override da configuração de roteamento (opcional).
Exemplo: criar transação com Pix
O item custa
9990 centavos (R$ 99,90) e o payment soma 9990 — as somas batem, então a
requisição é válida.Resposta
201 Created. O exemplo de JSON é ilustrativo — confira os campos reais na resposta do seu ambiente.Exemplo: criar e cobrar cartão com cartão tokenizado
Dois items de
5000 × 2 = 10000 centavos; o payment soma 10000. As somas batem. O cartão é
enviado como token (gerado pelo Tokenizer) — nunca envie dados crus
do cartão para a Core API.Listar transações
GET /transactions
Retorna uma lista paginada. Todos os filtros são opcionais e podem ser combinados.
Parâmetros de query
Página (paginação). Veja Convenções.
Itens por página.
Filtra por status da transação.
Filtra por moeda.
Filtra por método de pagamento.
ID da transação (busca parcial, ILIKE).
Filtra pelo seu código de referência.
Filtra pelo nome do cliente.
Filtra pelo e-mail do cliente.
Filtra pelo documento do cliente.
Busca combinada em nome/e-mail/documento do cliente.
Lista de IDs de recebedores (separados por vírgula) que devem aparecer em algum split da transação.
Busca textual em qualquer valor armazenado em
additionalInfo.Busca genérica.
Data inicial. ISO 8601 com timezone (ex.:
2026-06-01T00:00:00.000Z).Data final. ISO 8601 com timezone.
Campo de data usado por
startDate/endDate. Valores: createdAt, paidAt, refundedAt,
canceledAt, chargedbackAt, protestedAt.Campo de ordenação. Valores:
createdAt, paidAt, amount, status, customerName.Direção da ordenação. Valores:
asc ou desc.Exemplo
O formato exato do envelope de paginação está em Convenções. O JSON acima é
ilustrativo.
Buscar transação por ID
GET /transactions/:id
Retorna os dados completos da transação, incluindo seus payments e items.
ID da transação (
txn_).Status calculado da transação. Veja a tabela em Status da transação.
Items da transação.
404. Veja Erros.
Listar items da transação
GET /transactions/:id/items
Retorna apenas os items (produtos/serviços) da transação, dentro de uma chave data.
ID da transação (
txn_).404.
Estornar transação
POST /transactions/:id/refund
Cria pedidos de refund para todos os payments pagos da transação de uma só vez. O comportamento
de aprovação depende da configuração refund.auto_approve da company (default: ativado):
- Com auto-approve: o refund é criado, aprovado e processado no gateway imediatamente.
- Sem auto-approve: os refunds ficam pendentes de aprovação manual.
ID da transação (
txn_).Motivo do estorno (1 a 4000 caracteres).
Status possíveis
200— refunds criados e processados.404— transação não encontrada.409— nenhum payment estornável encontrado (ex.: nenhum payment está pago).
Veja também
Payments
Detalhes de cada forma de pagamento dentro da transação.
Refunds
Estorno de um payment específico e estornos parciais.
Tokenizer
Gere o
token do cartão antes de criar a transação.Split
Configure repasses por payment com
split ou splitId.Customers
Cadastre clientes para reusar via
customerId.Webhooks
Receba notificações de mudança de status da transação.

