Manual de Integração 3DS
Passo a passo para integração com a SDK de 3DS
O 3DS é um protocolo de segurança que visa proteger compras online com cartões de débito e crédito. Esta tecnologia adiciona uma camada extra de autenticação durante o processo de pagamento para garantir que é realmente o titular do cartão quem está realizando a transação.
Este manual tem como objetivo orientar o desenvolvedor na integração do 3DS, apresentando o passo a passo que deve ser seguido para garantir uma integração simples e fluida.
Antes de seguir para a integração em si, vale destacar alguns conceitos que podem surgir ao longo do desenvolvimento e que podem ser interessantes que o desenvolvedor esteja familiarizado.
Glossário
- Autorização: processo que sensibiliza o limite de crédito do portador do cartão junto ao banco emissor, geralmente utilizado para análise de prevenção, análise de limite de crédito e validação dos dados de cartão utilizado. A autorização não gera cobrança na fatura do comprador.
- Captura: processo que confirma uma transação autorizada. Após a captura o valor é debitado dos créditos do portador do cartão gerando a cobrança na fatura do mesmo.
- Emissor: é a instituição financeira que emite o cartão de crédito ou débito.
- Portador: é o proprietário do cartão, comprador do produto.
- Estabelecimento Comercial: é a entidade responsável pelo e-commerce
- MPI: sistema responsável em autenticar junto ao emissor as transações de crédito e débito.
- Postback: Retorno síncrono da API, por exemplo, no fluxo de autenticação 3DS.
- Callback: Retorno assíncrono da API, por exemplo, na API de cancelamento.
- SK: Secret Key, é a chave da API do lojista
- Liability Shift: Trata-se de transferência de responsabilidade, associado ao 3DS significa que o emissor se torna o responsável pela transação, inclusive em possíveis casos de fraude.
Pré-requisitos técnicos para integração
Adiante será descrito o passo a passo para a integração. De todo modo, é importante que os desenvolvedores responsáveis tenham conhecimentos em linguagem de programação para web, requisições HTTPS e manipulação de objetos em JSON.
Iniciando a Integração
Como obter as chaves da API
Antes de começar, você precisa obter suas chaves de API. Para isso, siga os seguintes passos:
- Acesse este link e faça login com seu usuário;
- Após acessar o Dash, navegue até a área de Desenvolvimento e em seguida clique em Chaves.
Atenção:
Caso você já é cliente Pagar.me e está integrado na versão anterior da API, entre em contato com o nosso time de suporte.
Tipos de Chave
Chaves para utilizar em ambiente de testes (Sandbox)
- Exemplo de prefixo da Chave Secreta de Sandbox: sktest*
Chaves para utilizar em ambiente de produção
- Exemplo de prefixo da Chave Secreta de Produção: sk_*
- Exemplo de prefixo da Chave Pública de Produção: pk_*
Gerando JWT
O Backend do integrador deve enviar a Chave de API (secret_key) no cabeçalho Authorization, seguindo o padrão universal HTTP Basic Authentication.
Faça um GET na rota: https://api.pagar.me/test/3ds2/tds-token
const fs = require('fs');
const request = require("request");
const options = {
method: 'GET',
uri: 'https://api.pagar.me/test/3ds2/tds-token',
headers: {
'Authorization': 'Basic ' + Buffer.from("sk_test_*:").toString('base64'),
'Content-Type': 'application/json'
}
};
request(options, function(error, response, body) {
console.log(response.body);
O retorno obtido deverá ser:
{
tds_token: JWT gerado pelo 3DS - Pagar.me
}
Com isso, será gerado um JWT pela rota tds-token que será usado na inicialização do SDK e tem validade de 20 segundos. Ou seja, caso o request enviado demore mais do que 20s haverá retorno de erro conforme imagem abaixo:
faltou a imagem no doc em word
A correção deste erro é apenas garantir que não haja expiração do JWT, ou seja, que os 20s serão respeitados.
Parametrizações
Na tag <form>
insira o atributo data-pagarmecheckout-form para que o script identifique de onde serão extraídos os dados.
<form action="{{url de sua action}}" method="POST" data-pagarmecheckout-form>
</form>
Lembre-se
Nunca trafegar os dados abertos de qualquer cartão no servidor (número, cvv, vencimento e nome do titular).
Uma vez que foi definido onde ocorrerá a extração dos dados, coloque nos campos <input>
do seu formulário os atributos "data-pagarmecheckout-element" correspondentes a cada um dos campos do cartão, conforme HTML abaixo. Estes serão capturados pelo script para a geração do token na submissão do formulário.
<form action="{{url de sua action}}" method="POST" data-pagarmecheckout-form>
<input type="text" name="holder-name" data-pagarmecheckout-element="holder_name">
<input type="text" name="card-number" data-pagarmecheckout-element="number">
<span data-pagarmecheckout-element="brand"></span>
<input type="text" name="card-exp-month" data-pagarmecheckout-element="exp_month">
<input type="text" name="card-exp-year" data-pagarmecheckout-element="exp_year">
<input type="text" name="cvv" data-pagarmecheckout-element="cvv">
<input type="text" name="buyer-name">
<button type="submit">Enviar</button>
</form>
Como o protocolo 3DS é suscetível ao desafio, reserve um espaço no checkout para comportá-lo, caso seja uma solicitação do emissor. Ao exibir a página deixe o iFrame oculto para o portador.
<iframe id="challengeIframe" data-pagarmecheckout-element="challengeIframe">
</iframe>
// css para o iFrame ficar oculto
#challengeIframe { display: none; }
Durante os testes é importante garantir que o desafio esteja sendo exibido na mesma página do checkout, dessa forma garantimos o correto funcionamento da integração.
Informações importantes a respeito da configuração do Checkout
- Quaisquer outros campos podem ser adicionados ao mesmo formulário, sem o atributodata-pagarmecheckout-element, e estes serão enviados normalmente ao seu servidor, sem a intervenção do script, como, por exemplo, buyer-name.
- O campo referente a data da expiração do cartão pode ser informado de duas formas:
- Em campo único, marcado como
exp_date
(O formato esperado é YYYY-MM); - Futuramente, em dois campos,
exp_month
eexp_year
.
- Em campo único, marcado como
Após realizar as parametrizações referentes ao checkout, deve-se inserir no final da sua página uma tag <script>
com o pagarme3ds.js.
/// Script para Sandbox:
<script src="https://3ds2-sdx.pagar.me/v1/3ds2.min.js"></script>
/// Script para produção:
Lembre-se de sempre utilizar cartões de teste em ambiente de Sandbox. Para ambiente produtivo utilizar cartões aptos a transacionar.
Lista de cartões teste:
Tipo de Cartão | Cartão de teste |
---|---|
BIN não preparado para 3DS | 900010011111_1111 |
3DS presente na pré-autorização | 400010051111_2003 |
Não passou pelo 3DS pré-autorização | 400010051111_2103 |
Timeout | 400010051111_2203 |
Transação 3DS sem fricção | 600010061111_2103 |
Desafio manual sem 3DS | 300010081111_2172 |
Desafio aprovado sem 3DSmethod | 300010081111_2170 |
Falha no desafio | 300010081111_2171 |
Transação aprovada no 3DS sem desafio | 600010061111_2003 |
Desafio manual com 3DS | 300010081111_2072 |
Desafio aprovado com 3DS | 300010081111_2070 |
Falha no desafio (com 3DS) | 300010081111_2071 |
Timeout (Transação sem desafio, com 3DS) | 600010061111_2203 |
Timeout (desafio manual, com 3DS) | 300010081111_2272 |
Timeout (desafio aprovado, com 3DS) | 300010081111_2270 |
Timeout | 300010081111_2271 |
Após inserir o script é preciso iniciar a detecção dos campos com a chamada da função PagarmeCheckout.init(). Com isso o método init(), receberá os 4 parâmetros, abaixo:
- JWT : Token gerado pelo back-end do lojista para ser usado no processo do 3DS.
- tdsData: JSON com as informações do Pedido para serem autenticadas pelo 3DS
- Callback(data): Para execução após a finalização do processo 3DS.
- ChallengeWindowSize: Indicação do tamanho da janela do desafio.
A tabela abaixo detalha os dados que devem ser enviados no parâmetro tdsData:
Atributos | Obrigatório | Tipo | Descrição |
---|---|---|---|
bill_addr | Required | Objeto Address | Endereço de cobrança |
ship_addr | Required | Objeto Address | Endereço de entrega |
Required | string | Email do portador do cartão | |
phones | Required | Array de Objeto Phone | Lista de telefones. Máximo 3, Mínimo 1 |
merchant | Required | Objeto | Objeto com as informações do Lojista |
purchase | Required | Objeto Purchase | Objeto de informações do carrinho |
acct_type | Optional | string | “01” - Não aplicável | “02” - Crédito | “03” - Débito |
Phone é um array de objetos phone
Atributos | Obrigatório | Tipo | Descrição |
---|---|---|---|
country_code | Required | String | Código do País |
subscriber | Required | String | Número com DDD |
phone_type | Required | String | Tipo do telefone, valores aceitos: home, work, mobile |
Purchase
Atributos | Obrigatório | Tipo | Descrição |
---|---|---|---|
amount | Required | int | Valor em centavos da transação |
currency | Required | string | Indicação da moeda que a transação está sendo cobrada em 3-digit ISO 4217 Default: BRL - Brasil |
date | Required | Data | Data e horário da cobrança no horário de UTC yyyymmddhhmmss |
instal_data | null | int | Número de parcelas da transação. (Diferente das parcelas brasileiras). Valor entre 2 e 99 |
Atenção
Campos indicados como Required são obrigatórios, Optional são opcionais e Conditional são obrigatórios, caso não for adicionado a tag data-pagarmecheckout-element.
Quando a função de callback é chamada recebe por parâmetro um objeto data, que é um JSON com o tds_id, trans_status. Indicando o ID do 3DS que deve ser usado na criação do Pedido e o Status da autenticação.
<script>
function callback(data) {
return true;
};
tdsData = { ... }
Script3ds.init3ds(tdsToken, tdsData, callback, challengeWindowSize)
</script>
É possível que a tela tenha uma das dimensões citadas abaixo:
- 250 x 400
- 390 x 400
- 500 x 600
- 600 x 400
- Full screen
Retorno do JS
Resposta do SDK JavaScript é um JSON no Formato abaixo:
{
trans_status: 'Y',
tds_server_trans_id: 'uuid-3ds-123',
error: 'MENSAGEM DE ERROR AQUI'
}
URLS importantes:
3ds-js
Formulário para testes
Status das transações 3DS
Abaixo a descrição do que significa cada um dos status disponíveis no 3DS.
Status | Descrição | Responsabilidade em caso de fraude |
---|---|---|
Y | Transação Autenticada | Emissor |
N | Transação não autenticada | Lojista |
C | Solicitação de desafio | Lojista |
U | Autenticação indisponível | Lojista |
A | Tentativa de Autenticação | Emissor |
R | Autenticação negada pelo emissor | Lojista |
I | Apenas informação | Lojista |
Vale destacar que as transações que possuem Liability Shift são as transações com retorno “Y”, ou seja, essas são as transações que o emissor do cartão de crédito se responsabiliza por eventuais fraudes.
Cadastro
Para garantir que todos os testes funcionem corretamente, não se esqueça de validar junto ao time comercial responsável por sua conta que o cadastro da account está realizado tanto em ambiente de Sandbox como em ambiente de Produção.
Importante:
Erros do tipo “Account not Found” em geral estão atrelados a ausência de cadastro, logo basta validar se o cadastro está efetuado. Caso receba este retorno de erro, lembre-se de se certificar junto ao comercial que o cadastro foi solicitado na account correta!
Updated 3 days ago