Para fazer uma cobrança você deve usar a rota /transactions para criar a sua transação, que pode ser feita por Cartão de crédito ou por Boleto bancário.
No caso de Cartão de crédito é possível utilizar um card_id, card_hash ou todos os dados do cartão diretamente. A segunda opção é a mais indicada, por fatores de segurança
Atenção: Essa versão de API será descontinuada
Essa versão da API Pagar.me já não é mais atualizada e, em breve, deixará de funcionar. Para que sua loja possa vender sem problemas, você precisa realizar sua integração usando a versão mais recente da nossa API, a V5.
No canto superior esquerdo da tela é indicado qual versão da documentação você está vendo. Clique na seta onde indica a versão e altere para a V5 para acessar a documentação.
Se você já é cliente, precisa realizar obrigatoriamente a migração para a versão V5.
Em caso de dúvidas, basta entrar em contato com o nosso time de atendimento através do e-mail, enviando a sua dúvida para [email protected] e por telefone, ligando para 4004-1330. Se você já é cliente pode também entrar em contato através do chat dentro da sua Dashboard.
Boleto em PDF
Além da versão HTML dos boletos retornada pela API, é possível gerar uma versão em PDF. Para tal basta adicionar o sufixo ?format=pdf na url retornada. Segue um exemplo:
URL ORIGINAL: https://api.pagar.me/1/boletos/test_ckj9yiyvy1obb0gm5g9yfpgbw
URL PDF: https://api.pagar.me/1/boletos/test_ckj9yiyvy1obb0gm5g9yfpgbw?format=pdf
Compradores estrangeiros
Ao contrário das versões 2013-03-01 e 2017-07-17 da nossa API, essa versão aceita documentos de compradores estrangeiros e endereços internacionais, e não apenas CPF/CNPJ e CEP. Dessa forma, é possível passar dados de
customer
,billing
eshipping
com essas características para que o antifraude faça a análise corretamente.
Transações recusadas
Em ambiente de teste é possível simular uma transação recusada pela operadora do cartão usando um cvv iniciado com 6
Não guardamos CVV
Em nosso card_id, não armazenamos o cvv do cartão. Mas você pode passar o campo na request, para adicionar uma camada de validação e segurança para a sua transação.
Campo 'customer.name'
Para transações usando boleto como método de pagamento, o campo 'customer.name' é obrigatório.
Campo 'session'
O campo 'session' permite que a visita do usuário à sua loja seja utilizada para análises de fraude. Ele funciona a partir do identificador de sessão do usuário no seu site. Você deve fornecê-lo se estiver com o antifraude habilitado e fizer uso do script de fingerprint na sua loja.
Transação síncrona com postback
Se o parâmetro async for
false
e você passar umapostback_url
, a transação continua sendo síncrona (isto é, a resposta é recebida na hora), mas o seu sistema mesmo assim recebe notificações para a mudança de status da transação.
card_hash
O card_hash, representação dos dados do cartão encriptados, não pode ser usado mais de uma vez e deve ser consumido em até 5 minutos! Veja mais neste link.
Boletos
Para transações por boleto, não aplicamos multa ou repasse de juros. Caso queira qualquer alteração na cobrança, é necessário criar uma nova transação.
Antifraude
Dados do cliente e de compra (customer, billing e items) são obrigatórios para transações de Cartão de crédito, devido ao antifraude.
Parâmetro local_time
O campo
local_time
deve ser enviado apenas em transações de mundo físico, nas quais o método de captura sejaEMV
ouMagstripe
. Ele representa o horário atual do dispositivo que está realizando a transação.
Análise manual pelo antifraude
Caso a sua loja esteja habilitada com análise manual pelo antifraude, é imprescindível que toda transação possua o campo async com o valor
true
. É necessário também fornecer um postback_url, através do qual você receberá atualizações sobre o status da transação.
Metadata
A API espera que o schema do metadata enviado seja consistente, ou seja, se em uma transação é enviado um metadado com o formato:
{ ... "metadata": { "pedido": 1 } }
a seguinte mudança não deve ser feita (mudança do tipo de 'pedido'):
{ ... "metadata": { "pedido": "2" } }
Apesar disso não restringimos a adição de novas chaves em transações posteriores como:
{ ... "metadata": { "pedido": 3, "cliente": 1 } }
Metadata 2
O metadata deve ser um objeto json. Logo os metadados a seguir são inválidos:
{ ... "metadata": ["order", "cart"] }
{ ... "metadata": "order" }