Nesta seção, você encontrará todos as especificações técnicas das REST APIs do produto IDPay para gerenciar transações de pagamento
Suas requisições de API são autenticadas utilizando um access-token. Qualquer requisição que não inclua um access-token válido retornará um erro.
Você pode ver mais sobre como gerar um access-token aqui.
O campo orderNumber deve ser preenchido com o número de pedido ÚNICO daquela compra no e-commerce, sendo errado o envio de um ID distinto transacional.
É importante ter atenção com relação a este campo, pois pode impactar negativamente na experiência do usuário no fluxo final, ocasionando problemas no uso do produto.
Como possíveis impactos podemos citar:
Baixa conversão:
O número do pedido é usado para ajudar o usuário final a realizar a conclusão do fluxo;
Erros na API:
É possível que você receba erros como: replicated transaction
caso seja usado o mesmo número do pedido, bin e last4¹.
¹ Caso a empresa esteja configurada para reaproveitar transações com mesmos dados, confira a seção Reaproveitamento de transações.
Caso as validações realizadas decidam que não é necessário realizar a captura da biometria, a resposta de retorno terá um status diferente e não será gerado um link para a captura, como a seguir:
Este cenário acontecerá caso utilize os módulos Pré ou Super Pré, para os casos onde utiliza o IDPay no Checkout, conforme especificado na seção Funcionalidades.
É possível configurar a empresa para reaproveitar transações que possuam os mesmos dados, evitando erros de replicated transaction
. O reaproveitamento acontecerá nas seguintes condições:
Uma transação está sendo criada com o mesmo orderNumber, identity.key, identity.value, company, card.binDigits, card.lastDigits e value de uma transação já anteriormente criada;
A transação anterior ainda não ultrapassou o tempo de expiração configurado na empresa.
Se a transação a ser criada e a transação anterior NÃO respeitem estas condições, uma nova transação será criada. Caso contrário, estas serão as respostas possíveis:
Caso a transação anterior esteja em um status final, como approved
ou inconclusive
:
Caso a transação anterior ainda esteja em um status inicial, como waiting
ou shared
:
Neste último caso, a transação ainda em um status inicial terá sua data de expiração recalculada, tendo como base a data desta requisição.
Para ver todos os status possíveis, consulte a seção Enumerados.
Para otimizar a performance da sua aplicação, você também pode implementar nosso Webhook para saber quando realizar a consulta do status da transação. Veja mais na seção Webhook.
Só é possível gerar o conjunto probatório de transações aprovadas.
O link retornado para conjunto probatório tem validade de cinco minutos após a obtenção. Então é importante que esse link não seja salvo, e sim usado para efetuar o download do conjunto probatório.
Também é possível configurar o reenvio de notificações através do portal, sem a necessidade de implementar via API. Para entender as possibilidades, fale com o responsável pelo seu projeto.
Para que seja possível cancelar uma transação, ela deve estar no status inicial (waiting
).
Para ver todos os status possíveis, consulte a seção Enumerados.
Dúvidas?
Não encontrou algo ou ainda precisa de ajuda? Se já é um cliente ou parceiro, pode entrar em contato através da Central de Ajuda.
Endpoint para consultar o status atual de uma transação específica.
ID da transação para verificar o status.
Access-token válido. O valor deve ser enviado no formato Bearer {token}.
Status da transação obtido com sucesso.
Status atual da transação.
"processing"
Endpoint para reenviar notificações via e-mail e telefone para uma transação específica.
ID da transação para a qual a notificação será enviada.
Access-token válido. O valor deve ser enviado no formato Bearer {token}".
Número de telefone para o envio da notificação.
"CELULAR_NOTIFICACAO"
Endereço de e-mail para o envio da notificação.
"EMAIL_NOTIFICACAO"
Notificação enviada com sucesso.
ID único da notificação gerada.
"b50ee24c-71eb-4a5d-ade1-41c48b44c240"
Link gerado para a notificação.
"https://aces.so/example"
Endpoint para recuperar o conjunto probatório de uma transação específica.
ID da transação para a qual o conjunto probatório será recuperado.
Access-token válido. O valor deve ser enviado no formato Bearer {token}.
Link do arquivo probatório obtido com sucesso.
URL do arquivo probatório.
"https://unico.io/probative.pdf"
Endpoint para cancelar uma transação de crédito especificada.
ID da transação que será cancelada.
Access-token válido. O valor deve ser enviado no formato Bearer {token}".
Transação cancelada com sucesso.
Status atualizado da transação.
"canceled"
Endpoint para criar uma nova transação.
Access-token válido. O valor deve ser enviado no formato Bearer {token}".
Dados de identificação do usuário.
Tipo de chave de identificação do usuário.
"cpf"
Valor da chave de identificação do usuário. Deve ser enviado sem pontos ou traços.
"CPF_DO_USUARIO"
Número do pedido associado à transação. É o dado que será utilizado como indexador no portal e você pode utilizar como forma de associação (foreign key) entre seu sistema e o IDPay.
"123456"
ID da empresa responsável pela transação. Este campo é fornecido pela Unico.
"f44f02e5-320e-497b-b346-8cf19b3ee2a4"
URL para onde o usuário será redirecionado após a finalizar a transação. Valores possíveis são: Uma URL https para redirecionar páginas web ou uma URL Schema para redirecionamento em aplicações móveis nativas.
"https://exemplo.com/redirect"
Informações do cartão utilizado na transação.
6 ou 8 primeiros dígitos do cartão.
"12345678"
Últimos 4 dígitos do cartão.
"7890"
Data de validade do cartão.
"12/24"
Nome do titular do cartão. O campo name deve ser enviado o nome correto e tomar cuidado com problemas de encode, valores incorretos e/ou inválidos podem ocasionar problemas com aprovação no fluxo. Já que esse dado é utilizado na experiência e na comunicação com o usuário final.
"João da Silva"
Valor total da compra.
100.5
Telefone para notificação. O parâmetro é opcional e caso envie o telefone na criação da transação, enviaremos uma notificação para o usuário via WhatsApp.
"5511998551010"
E-mail para notificação. O parâmetro é opcional e caso envie o telefone na criação da transação, enviaremos uma notificação para o usuário via E-mail.
"usuario@exemplo.com"
Comportamento de captura definido para a transação. Temos as seguintes opções: 'biometric': O modelo de autenticação de identidade utilizado é apenas a biometria, para fluxos onde queremos sempre ter a captura biometrica. 'silent': O modelo de autenticação de identidade utilizado é silencioso, validando apenas metadados do dispositivo nesse caso, para fluxos onde não queremos fricção nenhuma (a taxa de aprovação é baixa). 'adaptive': É um híbrido entre as duas acima, se utiliza da validação adaptativa e da biometria. É fluxo com uma menor fricção, segurança e melhor taxa de aprovação (padrão).
"biometric"
Informações adicionais sobre a transação. Atualmente é possível enviar como informação adicional: Seller: Informações sobre o seller daquela transação. Pode ser enviado a identificação daquele seller (cpf ou cnpj).
Informações do vendedor.
Tipo de chave de identificação do vendedor.
"cpf"
Valor da chave de identificação do vendedor.
"12345678909"
Transação criada com sucesso.
ID da transação criada.
"6ab1771e-dfab-4e47-8316-2452268e5481"
Status atual da transação.
"waiting"
Link relacionado à transação.
"https://aces.so/teste"
Token assinado que contém os parâmetros necessários para inicializar o SDK web do Unico IDPay.
"eyJhbGciOiJIUzI1NiIsInR5cC[...]Ok6yJV_adQssw5c"