Atualizações Recentes
Documentação: v2 como padrão, guia de integração e recursos em breve
A API não mudou nesta atualização. Mudou a documentação, para que você integre a v2 de ponta a ponta sem depender de outras fontes.v2 como versão padrão. A documentação abre na v2, com uma home própria. A v1 continua disponível no seletor de versão, marcada como Legado.Novas páginas da v2:Ambiente de Sandbox. O ambiente de testes passa a se chamar Ambiente de Sandbox em toda a documentação. Ele tem endereços próprios, separados da produção, e não há um botão para trocar de ambiente:
Correção. O
llms.txt indicava https://api.4seletpay.com.br/api/v1 como base da v1. O endereço correto é https://app.4seletpay.com.br/api/v1.Em breve. Estes recursos já podem ser testados no Ambiente de Sandbox e ainda não estão em produção, onde as rotas respondem 404. As páginas estão marcadas com Em breve:- Links de pagamento
- Contestações (
/v2/chargebacks) - Checkout.js e 3D Secure
- Alterar próxima cobrança na v1 (na v2,
next-billing-datejá está em produção) - Dados de teste da análise de fraude
API v2: três rotas de assinatura mudam de verbo
O path, o corpo da requisição, as respostas, os códigos de erro e o header
Idempotency-Key continuam iguais. Só o verbo HTTP mudou.Em PATCH /v2/subscriptions/{id}/items/{code}, a atualização é parcial: quantity, amount e description são opcionais, e é preciso enviar pelo menos um deles.API v2
Lançamento da API v2: pedidos com vários meios de pagamento, assinaturas, faturas e cartões salvos, com autenticação por chave de API e respostas planas. Selecione a versão v2 no topo da documentação.Novos endpoints:Principais mudanças em relação à v1:
- Autenticação por chave de API (
Authorization: Bearer sk_...), sem headeraccount. - Valores em centavos inteiros em todos os campos.
- Vários pagamentos no mesmo pedido — dois cartões ou cartão + PIX, com split por pagamento.
- Erros padronizados no envelope
{ "error": { "type", "code", "message" } }e pagamento recusado como402comfailure_reason. - Idempotência com o header
Idempotency-Key. - Webhooks no formato v2 para recursos criados pela v2, identificados por
webhook_version.
Cartões: um único endpoint para salvar e tokenizar
Unificamos o cadastro de cartão em um só endpoint. Antes, salvar um cartão para uso posterior exigia duas chamadas — uma para criar o cartão e outra, separada, apenas para tokenizá-lo. Agora a criação do cartão já dispara a tokenização, e não existe mais rota de tokenização avulsa.Endpoints removidos:Endpoint único de cadastro:
202 Accepted e tokenization_status: "pending", e o resultado da tokenização chega por webhook (card.token_created / card.token_failed). Não é necessário fazer polling.card_token em toda representação de cartão:O campo card_token passa a aparecer em todas as respostas e eventos de cartão — não apenas no card.token_created. Ele é o identificador do cartão salvo e continua sendo o valor enviado em payment.card.card_token ao criar uma cobrança.Webhooks: campo webhook_version no payload
Todo webhook desta documentação passa a incluir o campo webhook_version no envelope, identificando o formato do payload:v1 para os eventos documentados aqui. É uma adição ao payload — nenhum campo existente mudou de nome ou de formato. Trate valores desconhecidos de forma tolerante para conviver com formatos futuros.Novo evento: tax_invoice.issued
A emissão de nota fiscal agora notifica sua aplicação. O evento tax_invoice.issued é disparado quando todas as notas de um pedido são autorizadas, e traz os links públicos dos PDFs prontos para entregar ao cliente.Payload
Cartões salvos, tokenização e cobrança com card_token
Novo conjunto de rotas para gerenciar os cartões salvos de um cliente e reutilizá-los nas cobranças, além de melhorias no /charge.Novos endpoints — Cartões:Cobrança com cartão salvo (
/charge):- Agora é possível enviar
payment.card.card_token(o token retornado ao salvar o cartão / no eventocard.token_created) no lugar dos dados completos do cartão. Os camposnumber,name,month,yearesecurity_codetornam-se opcionais quandocard_tokené enviado (continue enviandoinstallments). - Toda cobrança com cartão passa a retornar o
card_tokenemdata.orders[].charges[].payment.card_token— tanto ao enviarcard_tokenquanto os dados completos (nesse caso o cartão é salvo e ocard_tokené devolvido). Em pagamentos sem cartão (ex.: PIX), vemnull. - O billing address não é tokenizado: ao cobrar com
card_token, informe o billing address (client.address) na requisição.
- O número completo do cartão (PAN) e o CVV nunca são retornados — apenas
first_six_digitselast_four_digits. - As rotas de cartão e o uso de
card_tokensão escopados por conta — umcard_tokende outra conta é rejeitado com422. - Tokenização assíncrona por webhook: ao salvar um cartão (
POST .../cards/tokens), a resposta retorna imediatamente comtokenization_status: "pending"e o resultado é entregue por webhook. Novos eventos de cartão:card.created,card.updated,card.deleted,card.expired,card.token_pending,card.token_createdecard.token_failed. - Exclusão é soft delete e é bloqueada (
409) quando o cartão está vinculado a uma assinatura ativa.
Request
Links de Pagamento
Lançamento dos Links de Pagamento — um novo recurso que permite criar checkouts pré-configurados e compartilhá-los diretamente com seus clientes, sem precisar construir uma página de pagamento do zero.Cada link gera uma URL única com token de segurança. O cliente acessa, confirma os dados e paga. Você recebe a notificação via webhook.Novos endpoints:Principais funcionalidades:
- Dados do cliente pré-preenchidos — nome, e-mail, telefone, documento e endereço já chegam preenchidos no checkout
- Métodos de pagamento configuráveis —
CreditCard,PIXouBoleto; se omitido, todos os métodos ativos da conta são exibidos - Parcelamento por milestones — defina faixas de parcelas com taxas de juros específicas; o sistema expande automaticamente de 1x a 12x
- Imagem no checkout — envie uma URL pública ou string base64; o servidor processa e armazena automaticamente (fail-soft: se falhar, o link é criado sem imagem e a resposta inclui
image_warning) - Desconto exclusivo PIX — percentual ou valor fixo aplicado apenas para pagamentos via PIX
- Expiração automática — defina
expires_atpara desativar o link em uma data futura - Limite de usos — defina
max_usespara encerrar o link após um número máximo de pagamentos - Split de pagamento — divida o recebimento automaticamente entre múltiplos recebedores por percentual ou valor fixo
- Privacidade no checkout —
obfuscate_clientmascara os dados do pagador;obfuscate_itemsoculta itens e valores - URLs de navegação —
back_urlpara o botão “Voltar” eredirect_urlpara redirecionar após pagamento confirmado - Frete — valor adicional somado ao total dos itens
Request
Resposta (HTTP 201)
