Processar payments
Pagamentos
Processar pagamentos
Cobra os pagamentos que foram criados sem dados de pagamento — a segunda etapa de quem separa o pedido da cobrança.
POST
Processar payments
POST /transactions/:transactionId/payments/process
Faz parte do recurso Pagamentos — o objeto e os status estão lá.
Cobra os pagamentos que já existem na transação mas ainda não foram ao gateway.
Quando você precisa deste endpoint
Na maior parte das integrações, você não precisa. Ao criar a transação com o objeto do meio de pagamento dentro depayments — creditCard, boleto ou pix — a cobrança
acontece na mesma requisição, e a resposta já diz se foi aprovada.
Este endpoint existe para quem separa o pedido da cobrança em duas etapas:
1
Crie a transação declarando o pagamento, sem os dados dele
pending — registrado, não cobrado. Nada foi ao gateway.2
Cobre, quando tiver os dados
txn_ para exibir o
número do pedido, gravar no seu banco e mandar o e-mail de “pedido recebido”. A cobrança vem na tela
seguinte. Numa chamada só, você teria de esperar o cartão para a transação sequer existir.
O outro uso é retentar: o cartão foi recusado, o comprador informa outro, e você chama este
endpoint de novo com o cartão novo.
O que enviar
Pix e boleto dispensam o objeto.
pix e boleto existem só para mudar a expiração — omitidos,
valem os mesmos defaults da criação: 30 minutos no Pix, 3 dias no boleto. O campo é
expirationDate, o mesmo nome de POST /transactions.Os dados enviados valem para todos os pagamentos processados na chamada. Se a transação tem dois
pagamentos e você não restringe, os dois recebem o mesmo
creditCard. Para cobrar cartões
diferentes em cada um, faça uma chamada por pagamento, usando paymentIds.paymentIds restringe quais pagamentos processar. Omitido, a Z2Pay processa todos os que estão
em pending ou waiting_payment. Informe apenas IDs de pagamentos ainda não pagos — o campo
serve para escolher entre os pendentes, não para reprocessar o que já foi cobrado.Envie o header
Idempotency-Key — idempotência evita cobrança duplicada se a
requisição for reenviada por timeout ou retry.Nada pendente é
409. Se nenhum pagamento se qualifica, a resposta é 409 com
error.details.code: "NO_PENDING_PAYMENTS" — não um 200 vazio. Repare no caminho: o
error.code é sempre a classe do erro ("CONFLICT", neste caso); o código específico vem
dentro de error.details.code. Costuma significar que a transação já foi cobrada, ou que os
paymentIds informados não estão pendentes.O mesmo 409 responde quando outra requisição com a mesma Idempotency-Key ainda está em
curso. Nesse caso o corpo é { "error": "texto" }, sem objeto nenhum — trate pelo status, não
pelo código.Authorizations
API Key da Credential (gerada no Backoffice)
Headers
Chave única para garantir idempotência da requisição
Path Parameters
ID da transação
Body
application/json
Dados do comprador exigidos pelo gateway.
Cartão a processar: cardId do vault ou token do Tokenizer.
Dados do boleto para processamento via gateway.
Dados do Pix para processamento via gateway.
IP do comprador (antifraude).
IDs específicos de payments a processar; omitido/vazio processa todos os pendentes.