Skip to main content

Visão geral

O pedido (order) é a compra do cliente na API v2. Ele reúne os itens e um ou mais pagamentos: você pode cobrar um cartão, um PIX, dois cartões ou cartão + PIX no mesmo pedido.
201 Created não significa pago. A resposta traz o resultado da autorização. Um pagamento com cartão aceito pode ficar em processing até a confirmação da adquirente. Use os webhooks order.paid e charge.paid para saber quando o pedido foi pago.

Criar um pedido

Campos principais

Campos do cliente

A v2 não tem recurso de cliente. Envie o comprador em cada pedido.

Campos do pagamento (payments[])

Campos do cartão (payments[].card)

¹ Alternativa aos dados do cartão. ² Obrigatório quando token não é enviado.

Campos do split (payments[].split[])

Campos dos itens (items[])

Análise de fraude (fraud_analysis)

Pular a análise de fraude exige permissão na sua conta. Sem ela, a resposta é 422 (fraud_bypass_not_allowed).

Regras de validação

  • A soma de items[].amount × items[].quantity precisa ser igual à soma de payments[].amount.
  • Um pagamento com cartão precisa de card.token ou de todos os dados do cartão.
  • Quando o pedido tem cartão, o pix_expiration de um pagamento PIX pode ser de no máximo 86400 segundos (24 horas). O cartão fica pré-autorizado enquanto o PIX não é pago.
  • A soma de split[].amount precisa ser igual ao amount do pagamento.
  • No split, exatamente um recebedor precisa ter options.charge_processing_fee: true, e o valor dele precisa cobrir as taxas de processamento. Pelo menos um recebedor precisa ter options.charge_remainder_fee: true e pelo menos um precisa ter options.liable: true. Um split que não pode ser aplicado retorna 422 (split_error).

Exemplos

Cartão com captura manual

Request
Resposta (HTTP 201)

PIX

Pagamento
Resposta (HTTP 201)

Cartão + PIX

Envie dois itens em payments. O pedido é criado com dois pagamentos e fica em requires_action com o QR Code em next_action. O cartão fica em requires_capture e é capturado automaticamente quando o PIX é pago.
Pagamentos

Captura

Um pagamento com cartão pode ser só autorizado (o limite fica reservado) ou capturado (a venda é concluída).
Um pedido com vários pagamentos é tudo ou nada. Se um pagamento for recusado, os que já foram autorizados são desfeitos e o pedido falha. O mesmo vale para a captura: se a adquirente recusar a captura de um cartão, os demais são desfeitos e o pedido fica failed, com o motivo em failure_reason.

O objeto pedido

Status do pedido

O status do pedido é calculado a partir de todos os pagamentos, não apenas do primeiro.

Pagamentos

Cada item de payments é um objeto payment_intent. O id do pagamento é o mesmo id da cobrança: use-o em GET /v2/charges/{id} e no estorno.

Status do pagamento


Próxima ação (next_action)

Quando o cliente precisa fazer algo, o pedido traz um next_action. Se nada for necessário, o campo vem null.

QR Code PIX

Exiba o qr_code (código copia e cola) ou a imagem de qr_code_url para o cliente.

Código de verificação

A análise de fraude pode pedir que o cliente confirme um código antes do pagamento:
  1. Peça ao cliente o código que ele recebeu.
  2. Envie o código em POST /v2/orders/{id}/confirm.
  3. Se o código expirar, gere outro com POST /v2/orders/{id}/confirm/resend.
Nenhum pagamento é cobrado antes da confirmação. O código de verificação tem prioridade sobre o QR Code PIX. A verificação por código não gera webhook: acompanhe pelo next_action da resposta.
O reenvio do código aceita 5 requisições por minuto por IP de origem. O limite não é separado por conta: se a sua plataforma atende várias contas a partir do mesmo servidor, todas dividem os mesmos 5 reenvios por minuto. Ao exceder, a resposta é 429 fora do envelope de erro da v2 ({ "message": "Too Many Attempts." }).

Fluxo de um pedido


Limites e bloqueios

  • Por comprador: POST /v2/orders aceita no máximo 2 tentativas por minuto do mesmo comprador (e-mail ou documento) para os mesmos itens. Acima disso, a resposta é 429 (rate_limit_exceeded) com customer_message e Retry-After.
  • Bloqueios: conta, item ou cliente bloqueado (e-mail, documento ou BIN do cartão, inclusive de cartão salvo) retorna 403 com customer_message.
Veja todos os limites em Idempotência e limites.

Pontos de atenção

  • GET /v2/orders/{id} só encontra pedidos criados pela API v2. Pedidos da v1 retornam 404.
  • Os pedidos da v2 não têm o campo international.
  • Os pedidos da v2 não salvam cartão. O id de um cartão salvo vem de POST /v2/cards, de uma assinatura ou de um cartão salvo no checkout da v1.

Erros específicos

Resposta (HTTP 422)
Veja o catálogo completo em Erros.