Uma API de pagamentos feita para quem programa.
A API de pagamentos da PurinCash é REST sobre JSON, autentica com um único header e cobre PIX, cartão, Litecoin e assinaturas com o mesmo fluxo: você cria a cobrança, o cliente paga e a confirmação chega por webhook assinado. Teste tudo no sandbox gratuito antes de ir para produção — sem mensalidade e sem taxa de setup.
Uma API, todos os meios
O ciclo é sempre o mesmo: você cria a cobrança, a resposta traz o que o cliente precisa para pagar e, quando o pagamento é confirmado, a PurinCash faz um POST assinado na sua URL. O formato da resposta muda conforme o meio — PIX volta como código copia e cola, cartão como URL de checkout hospedado e cripto como endereço de carteira —, mas do webhook em diante tudo é igual. Aprender um meio é aprender todos.
Todos os endpoints ficam sob https://api.purincash.com/v1. Valores vão em centavos inteiros (valueCents: 4990 é R$ 49,90), datas em ISO 8601 UTC e todo erro tem a mesma forma: { "error": "..." }. Se o seu foco é só PIX, veja a página do gateway PIX; para a visão completa da plataforma, o gateway de pagamentos.
PIX
POST /v1/charges ou /v1/payments. A resposta traz o copia e cola (pix.brCode) e a imagem do QR (pix.qrCodeImage); a confirmação chega em segundos.
Cartão de crédito
POST /v1/card-payments devolve uma checkoutUrl de checkout hospedado. O número do cartão nunca passa pelo seu servidor.
Litecoin (LTC)
O mesmo POST /v1/payments com paymentMethod: "ltc". O valor vai em reais e é convertido na cotação do momento.
Assinaturas
POST /v1/subscriptions usa Pix Automático: o cliente autoriza no banco e cada renovação é cobrada sozinha, com webhook.
Split
POST /v1/split-charges divide o valor entre outras contas no momento em que o dinheiro entra.
Saldo e saques
GET /v1/wallet para o saldo e POST /v1/payouts para sacar por PIX, LTC ou USDT sem sair do código.
Integre em minutos, teste sem gastar nada
Do zero ao PIX pago, tudo em sandbox. O guia de primeira cobrança da documentação segue exatamente estes passos:
Gere uma chave ps_test_
No painel, em Equipe & API → Developer API. A chave completa aparece uma única vez; guarde-a em variável de ambiente, nunca no front-end.
Crie a cobrança
Um POST com valueCents, description e a callbackUrl que vai receber o aviso. Guarde o paymentId junto do seu pedido.
Simule o pagamento
No sandbox ninguém paga de verdade: chame simulate-paid e o status vira paid, disparando o webhook como em produção.
Troque para ps_live_
Nenhuma URL, campo ou nome de evento muda. É só trocar a chave e o PIX passa a cair de verdade.
Webhooks confiáveis, do jeito certo
Quando algo acontece com o seu dinheiro — payment.paid, charge.paid, card_payment.paid, saques, contestações —, a PurinCash faz um POST com o evento em JSON. É assim que você sabe que o PIX caiu sem ficar consultando a API em loop.
A assinatura vem em todo webhook, sem opt-in: valide o HMAC sobre o corpo cru com comparação timing-safe, deduplique pelo X-Webhook-Id, responda 200 e só então processe. E antes de entregar, confira se o amountCents bate com o que você cobrou.
const esperado = crypto
.createHmac("sha256", process.env.PURINCASH_WEBHOOK_SECRET)
.update(req.body) // corpo cru
.digest("hex");
const valida =
assinatura.length === esperado.length &&
crypto.timingSafeEqual(Buffer.from(assinatura), Buffer.from(esperado));
if (!valida) return res.status(401).send("assinatura inválida");Assinatura HMAC-SHA256
Todo webhook traz X-Webhook-Signature, calculado sobre o corpo cru.
Reentrega automática
Até 7 tentativas, de 1 minuto a 12 horas depois, por pouco mais de 20 horas.
Idempotência
X-Webhook-Id no formato evento:id, igual em toda reentrega do mesmo evento.
Timeout de 5 segundos
Responda 2xx rápido e processe depois; fora disso a entrega conta como falha.
Só HTTPS público
IP numérico, localhost e rede privada são recusados já na criação da cobrança.
Destinos flexíveis
Até cinco URLs da conta, ou uma callbackUrl por cobrança com prioridade.
Documentação pronta para o seu assistente de IA
Integrando com ajuda de IA? A documentação inteira existe em texto puro em llms-full.txt, gerado a partir das próprias páginas e sempre em sincronia com elas. Cole no seu assistente e ele responde sobre a API sem inventar endpoint. Há também o índice llms.txt, com o resumo da API, a tabela de endpoints e os fluxos de PIX e Litecoin.
Prefere testar antes de escrever código? Cada página da referência da API tem um playground: cole uma chave ps_test_ e dispare a requisição direto do navegador, sem sair da documentação.
Código que você copia e roda
Não existe SDK obrigatório para instalar: qualquer linguagem que faça requisição HTTP integra, e a documentação traz cada exemplo em cURL, JavaScript, Python e PHP. Para cobrar um produto cadastrado ou em Litecoin, use POST /v1/payments com productId ou valueCents; o método padrão é PIX, e paymentMethod: "ltc" gera um endereço Litecoin.
A resposta traz o paymentId (prefixo psa_) e, no PIX, o pix.brCode para exibir ao cliente. Quando o pagamento confirma, o evento payment.paid chega assinado na callbackUrl, e você pode conferir o estado final com GET /v1/payments/:paymentId.
curl -X POST https://api.purincash.com/v1/payments \
-H "Authorization: Bearer ps_test_SUA_CHAVE" \
-H "Content-Type: application/json" \
-d '{
"valueCents": 4990,
"description": "Plano Premium",
"callbackUrl": "https://minhaloja.com/webhooks/purincash"
}'
# resposta: paymentId (psa_...) + pix.brCode
# confirmação: webhook payment.paid assinadoPerguntas frequentes
sobre a API de pagamentos.
O que os desenvolvedores mais perguntam antes da primeira requisição.
Toda requisição leva a chave de API no header Authorization, no esquema Bearer. Chaves ps_live_ operam em produção e chaves ps_test_ no sandbox — não existe parâmetro de ambiente, é o prefixo da chave que decide. As chaves são geradas no painel, aparecem completas uma única vez e cada conta pode manter até 10 chaves ativas ao mesmo tempo.
Para um PIX de valor livre, o caminho mais curto é POST /v1/charges, que também é o único que faz split. Quando o preço vem de um produto cadastrado (productId) ou quando você quer cobrar em Litecoin (paymentMethod: "ltc"), use POST /v1/payments. Em ambos, a resposta traz pix.brCode (o copia e cola) e pix.qrCodeImage (a imagem do QR).
Não é preciso instalar nada: a API é REST sobre JSON e autentica com um único header, então qualquer linguagem que faça requisição HTTP integra. A documentação traz exemplos prontos em cURL, JavaScript, Python e PHP, e a validação de webhook tem código em Node, PHP, Python e Go.
Use uma chave ps_test_. No sandbox nada é enviado a banco: o brCode gerado não é pagável, e você marca a cobrança como paga chamando o endpoint simulate-paid (/v1/sandbox/charges/{id}/simulate-paid ou /v1/sandbox/payments/{id}/simulate-paid). O webhook sai para a sua callbackUrl como em produção. Para ir ao ar, basta trocar ps_test_ por ps_live_ — nenhuma URL ou campo muda.
A entrega falha (timeout, erro de rede ou resposta fora de 2xx) e o evento entra na fila de reentrega: são até 7 tentativas — na hora, depois de 1 minuto, 5 minutos, 30 minutos, 2 horas, 6 horas e 12 horas —, cobrindo pouco mais de 20 horas. O corpo reenviado é idêntico e o header X-Webhook-Id não muda, então deduplique por ele.
120 requisições por minuto, somando todas as rotas /v1/*. Toda resposta traz os headers RateLimit-Limit, RateLimit-Remaining e RateLimit-Reset, e ao estourar a API responde 429. Saques têm limite próprio: 10 por hora por chave. A forma mais eficiente de ficar longe do teto é usar webhook em vez de consultar status em loop.
Sua primeira cobrança pela API, ainda hoje.
Gere a chave ps_test_, crie a cobrança e receba o webhook no sandbox.