Mesma conta, mesmas cobranças: o que o time comercial vê no painel é o que a sua aplicação lê pela API. Comece pelo ambiente de testes, que já vem liberado.
No painel, em Configurações → Chaves de API. Toda conta nasce com um par de chaves de teste; as de produção liberam depois da aprovação do cadastro.
Mesma URL, mesma estrutura de payload da produção — muda só a chave. O QR devolvido é simulado e pode ser marcado como pago pelo painel.
Cadastre a URL que vai receber os eventos e confira a assinatura antes de dar baixa no pedido. Enquanto sua aplicação não responde 2xx, a gente reenvia.
Sem SDK: uma chamada HTTP com a sua chave. O QR volta pronto pra mostrar ao cliente.
curl -X POST \
https://api.dvpay.com.br/charges \
-H "Authorization: Bearer sk_test_..." \
-H "Content-Type: application/json" \
-H "Idempotency-Key: pedido-10428" \
-d '{"amount":"349.00","paymentMethodKind":"pix","description":"Pedido #10428"}'{
"data": {
"id": "b319b649-9eeb-4f6c-a3b4-54bbaf936813",
"status": "pending",
"amount": "349.00",
"currency": "BRL",
"paymentMethodKind": "pix",
"paymentInstructions": {
"pixCopyPaste": "00020126...",
"pixQrCode": "data:image/png;base64,..."
},
"createdAt": "2026-08-18T14:00:00.000Z"
}
}Toda chamada leva a chave no header Authorization, no formato Bearer. Chave de teste e de produção têm prefixos diferentes — nunca use a de produção no front-end.
POST para criar (Pix, cartão ou boleto), GET para consultar o estado atual e POST de estorno para devolver, total ou parcialmente.
Eventos de mudança de estado da cobrança, assinados com HMAC-SHA256. Reenvio automático com espera crescente e replay manual pelo painel.
Toda criação aceita o header Idempotency-Key. Se a chamada repetir por timeout, você recebe a mesma cobrança de volta em vez de uma segunda.
Enquanto ela não sai, a gente te passa a coleção de exemplos e acompanha sua integração de perto — inclusive no sandbox.