Skip to main content
Quando um pagamento no cartão é confirmado, a gente faz POST na callbackUrl daquela cobrança.

As duas diferenças que importam

O identificador é orderCode, não paymentId.O valor vem em amount (reais, decimal), não em amountCents.
Se o seu handler é genérico, normalize na entrada em vez de espalhar if pelo código:
Math.round(amount * 100) e não amount * 100. Ponto flutuante transforma 49.90 * 100 em 4989.999999999999, e o !== contra o valor esperado passa a falhar de forma aleatória.

Campos

string
required
Sempre card_payment.paid.
string
required
Código do pedido no cartão. É o mesmo usado em GET /v1/card-payments/{orderCode}.
number
required
Valor em reais, decimal.
string
required
Sempre paid neste evento.
string
required
Data e hora da confirmação, em ISO 8601.
object
name e email, quando informados na criação.
string
A string JSON enviada na criação. Vem null quando não houve.

Garantias

As mesmas do PIX: assinatura HMAC em X-Webhook-Signature, idempotência em X-Webhook-Id, timeout de 5 segundos e até 7 tentativas com backoff. Detalhes em Visão geral.
Cartão não tem webhook em sandbox, porque cartão não roda em sandbox. Para testar o handler, faça uma cobrança real de valor baixo em produção.

Lembrete sobre a successUrl

O cliente cair na sua successUrl não é confirmação de pagamento. É só o navegador voltando, e a URL pode ser aberta na mão por qualquer um. Libere o produto por este webhook ou por GET /v1/card-payments/{orderCode}.