Skip to main content
Endpoint público de confirmação. Usado pelo browser do comprador (na hosted page ou no seu frontend custom) para concluir a sessão de compra. A chamada confirma a checkout.session; a Chargefy resolve o customer, confirma a cobrança server-side pelo lifecycle de payment_intent e atualiza a session. Para PIX e boleto, complete significa que o comprador fechou o formulário e recebeu os dados de pagamento. A confirmação financeira chega de forma assíncrona via webhook checkout.session.async.payment.succeeded. Para cartão, o payment_status pode virar paid na própria resposta, mas webhooks continuam sendo a fonte confiável para fulfillment.
A confirmação da session não expõe nem exige IDs internos de processamento. Para reconciliar, use a checkout.session, o payment_intent relacionado quando aplicável e os webhooks.

Autenticação

Nenhuma. O client_secret na URL é a credencial.

Parâmetros de caminho

string
required
Secret opaco da checkout session, retornado no campo client_secret do create.

Attributes

string
Data de vencimento do boleto (YYYY-MM-DD). Padrão: 3 dias depois da confirmação. Aplica só quando payment_method: "boleto".
string
Bandeira do cartão (visa, mastercard, elo, etc). Usado pra cálculo de juros — opcional, a Chargefy infere quando ausente.
string
Cartão já salvo que pertence a este comprador. Alternativa ao token_id para credit_card. A propriedade do cartão é validada antes de usar: um card_id que não pertence ao comprador é recusado. Prefira token_id no fluxo padrão.
object
Endereço de cobrança. Obrigatório para boleto e também quando a sessão quando o Checkout Builder exige endereço. Para boleto, exige endereço brasileiro completo: city, country ("BR"), neighborhood, number, postal_code, state (UF de 2 letras) e street.
string
CPF ou CNPJ do comprador. Obrigatório para boleto e quando a sessão quando o Checkout Builder exige documento. Caso contrário, opcional. Usado na emissão de boleto e na identificação fiscal.
string
Tipo do documento. Opcional, acompanha customer_document.
string
required
Email do comprador. Sempre obrigatório.
string
required
Nome completo do comprador. Sempre obrigatório.
object
Dados do comprador coletados na hosted page.
string
Cupom de desconto aplicado pelo comprador.
integer
default:"1"
Número de parcelas (1–12). Aplica só com credit_card. Em uma sessão de assinatura com trial, nada é cobrado agora: a escolha fica registrada na assinatura e a primeira cobrança após o trial — e cada renovação — é feita no cartão salvo com esse número de parcelas, limitado ao teto permitido pelo valor do ciclo. Indisponível para assinaturas mensais e para no_payment_required (422).
string
required
Método de pagamento escolhido pelo comprador. no_payment_required só vale para trial de assinatura criado com payment_method_collection: "if_required". Os demais métodos devem estar em configuração atual de meios de pagamento da organização (caso contrário 400).
string
Token de uso único do cartão, gerado client-side. Caminho recomendado para credit_card: a Chargefy associa o token ao comprador e conclui a cobrança server-side, inclusive salvando o cartão de forma reutilizável para assinaturas. Veja tokenização abaixo.

Campos obrigatórios por método

O comprador sempre informa nome e email. O boleto, por exigência do meio de pagamento, também precisa de endereço e documento. Além disso, a configuração atual da organização pode tornar obrigatórios documento, telefone e endereço para qualquer método. A política só adiciona exigências sobre o piso do método; nunca remove uma exigência do meio de pagamento. O telefone, quando exigido, vem em customer_details.phone. Faltar um campo exigido (pelo método ou pela política da sessão) retorna 422.

Três variantes

(a) PIX

Mais simples: só nome e email. A resposta traz payment_data.qr_code (string EMV pra colar no app do banco) e payment_data.qr_code_url (PNG hospedado).

(b) Boleto

Exige endereço brasileiro completo (FEBRABAN), opcionalmente com data de vencimento custom. A resposta traz payment_data.barcode, payment_data.digitable_line e payment_data.pdf_url.

(c) Cartão de crédito

Caminho padrão: envie token_id (token de uso único gerado client-side — nunca envie número de cartão direto pra esse endpoint). A Chargefy associa o token ao comprador e cobra server-side; a cobrança pode ser autorizada na hora e payment_status: "paid" na resposta indica sucesso. Para um cartão já salvo que pertence a este comprador, use card_id no lugar de token_id — a propriedade é validada antes de cobrar.

(d) Trial sem cartão

Use payment_method: "no_payment_required" quando a sessão de assinatura foi criada com trial e payment_method_collection: "if_required". A confirmação cria a assinatura em trial, não cria cobrança no momento e retorna payment_status: "no_payment_required".

Tokenização do cartão

A Chargefy não aceita número de cartão em texto plano neste endpoint. O token_id precisa ser um token de uso único gerado client-side por uma das duas vias:
  • Hosted page (recomendado) — você redireciona o comprador pra resposta.url e o formulário de cartão da Chargefy tokeniza, confirma e devolve em success_url. Sem PCI no seu lado.
  • Frontend custom — tokenize o cartão no browser com um fluxo client-side compatível e envie somente o token em token_id. O cartão nunca deve tocar seu servidor; a Chargefy associa o token ao comprador e conclui server-side.

Resposta

Retorna o DTO completo da sessão com payment_data preenchido conforme o método. Para métodos assíncronos (PIX, boleto), o campo certo pra ler os dados de exibição é next_action — um formato tipado com union discriminada por type. payment_data permanece preenchido por compatibilidade durante a transição; novas integrações devem ler next_action. O código PIX tem validade curta (next_action.pix_display_qr_code.expires_at). No checkout hospedado, o comprador renova o código na própria tela — inclusive depois de expirado — enquanto a sessão estiver dentro do seu prazo de 24h. Integrações diretas usam /regenerate_pix para emitir um código novo no mesmo payment_intent.

PIX

Boleto

Cartão de crédito (sucesso)

Trial sem cartão

Webhooks disparados

Erros

Ao receber payment_result_unconfirmed, não envie outra confirmação. A tentativa pode ter sido criada. Consulte a sessão e aguarde os webhooks até payment_status chegar a um estado final; uma nova tentativa cega pode duplicar a cobrança.