Skip to main content

Visão geral

Um link de pagamento é uma URL que você compartilha com o cliente e que abre uma página de checkout hospedada pela PlugToPay. Não é preciso escrever frontend: você cria o link pela API, envia o endereço e o cliente paga.
Existem dois tipos de link:
Um link de assinatura nunca recebe amount — o valor vem do plano. O payment_method é forçado para card na criação.
Links de assinatura ainda não podem ser pagos. A criação e o gerenciamento funcionam, mas o pagamento pelo checkout hospedado está bloqueado até a cobrança recorrente ficar pronta no servidor. Use links avulsos por enquanto.
O campo checkout_url da resposta já entrega o endereço correto — prefira usá-lo em vez de montar a URL manualmente.
A página pública de um link nunca expõe cartões salvos: saved_cards volta sempre vazio, independentemente do e-mail ou CPF que o comprador anônimo digitar. A regra é aplicada no servidor, então ninguém consegue ver ou reutilizar o cartão de outra pessoa por um link público.

POST /api/v1/payment-links — requer X-Client-ID + X-API-Key.

Campos

success_url e cancel_url precisam usar https e não podem apontar para localhost, domínios .local ou IPs privados. Qualquer um desses casos devolve 422.
Um cartão recusado não redireciona. A página hospedada mostra o motivo da recusa e um botão de tentar de novo, em vez de mandar o comprador para a cancel_url — uma recusa quase sempre se resolve com outro cartão, e tirar o comprador da página encerraria a venda. Hoje só um pagamento aprovado leva à success_url; a cancel_url fica guardada para uma desistência explícita, que a página ainda não oferece.
Resposta 201:
O slug da empresa é gerado a partir do nome no cadastro e pode ser alterado depois em PUT /user/company.
Todas as rotas abaixo aceitam X-Client-ID + X-API-Key.

Listar

Resposta paginada no formato { "data": [...], "meta": { ... } }.

Atualizar

Todos os campos são opcionais. type não pode ser alterado. O slug pode ser definido pela primeira vez ou trocado — é assim que se muda a checkout_url do formato por token para o formato legível.
Resposta 200 com o mesmo formato da criação.
Em links de assinatura, payment_method continua aceitando pix na atualização, mas o checkout só processa cartão. Mantenha card.

Remover

Resposta 204 sem corpo. É uma remoção lógica: quem abrir a checkout_url depois disso recebe 404.

Rotas públicas (sem autenticação)

São as rotas que a página de checkout usa. Não exigem chave de API — o token do link já é o segredo.
Ou pelo par de slugs:
Resposta 200 — link avulso:
Resposta 200 — link de assinatura:
Esse recurso é um subconjunto seguro: não devolve company_id, as URLs de redirecionamento nem o slug do link.

Criar a sessão de checkout

Resposta 201 com o mesmo formato de uma sessão de checkout comum, incluindo success_url, cancel_url e expires_at. Guarde o token: ele é o X-Checkout-Token do passo seguinte.
A sessão é de uso único. Uma tentativa recusada consome o token — crie outra sessão para a próxima tentativa.

Submeter o pagamento

Com o token da sessão em mãos, o fluxo é exatamente o do checkout: POST /api/v1/checkout/payments/card ou /pix com o header X-Checkout-Token. A sessão trava amount, currency e merchant_order_id, e o método também é respeitado: se o link foi criado apenas para cartão, enviar para a rota de PIX devolve 422.
As rotas públicas devolvem 404 em qualquer um destes casos:

Formato do token

O token tem o prefixo pl_live_ seguido de 56 caracteres hexadecimais:

Referência rápida de rotas

As mesmas rotas de gerenciamento existem sob /api/v1/user/payment-links para uso do painel, autenticadas com Authorization: Bearer <jwt> em vez da chave de API.