Sessões de checkout
Confirmar uma sessão de checkout
Confirma uma checkout session.
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.
Autenticação
Nenhuma. Oclient_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 emcustomer_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 trazpayment_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 trazpayment_data.barcode, payment_data.digitable_line e payment_data.pdf_url.
(c) Cartão de crédito
Caminho padrão: envietoken_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
Usepayment_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. Otoken_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.urle o formulário de cartão da Chargefy tokeniza, confirma e devolve emsuccess_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 compayment_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.

