CREDHELP API Nov23

[Capture a atenção do leitor com uma ótima citação do documento ou use este espaço para enfatizar um
ponto-chave. Para colocar essa caixa de texto em qualquer lugar na página, basta arrastá-la.]
Facilita Sua Vida!
ESPECIFICAÇÃO
MÉTODOS CHECK OUT

PAGAMENTOS
CRED-HELP: 0002/2023
CRED-HELP: 0002/2023
VERSÕES:
Data Versão Alteração Autor
16/01/2023 1.0 Criação Humberto Almeida

19/01/2023 1.1 Inserção de valores do retorno das consultas Humberto Almeida
02/06/2023 1.2 Documentação de Cancelamento da pré-operação Humberto Almeida
27/06/2023 1.3 Documentação da consulta por Chave Humberto Almeida
15/07/2023 1.4 Ajustes na documentação para 3Ds Humberto Almeida
26/07/2023 1.4 Ajustes na documentação para Split Humberto Almeida
28/09/2023 1.5 Ajuste Efetivar Pré-operação Bruno Pellegrino
26/10/2023 1.6 Alterações no item Recorrência Humberto Almeida
28/10/2023 1.7 Ajustes finais na documentação Humberto Almeida
30/10/2023 1.8 Revisão Compliance Mara Suarez
2
Página
CRED-HELP (pt-br): 0002/2023

Sumário
GLOSSÁRIO ................................................................................................................................. 5
1 – AUTENTICAÇÃO .................................................................................................................... 5
2 – PRÉ OPERAÇÃO ..................................................................................................................... 6
2.1 – Simulação ....................................................................................................................... 7
2.1.1 – Método de Simulação ............................................................................................. 7
2.2 – Criação da Pré-operação ................................................................................................ 9
2.3 Cancelamento da Pré-Operação ..................................................................................... 12
3 – FLUXO DE CHECKOUT ......................................................................................................... 12
3.1 – Soft Descriptor ............................................................................................................. 13
3.1.1 – Regras de uso ........................................................................................................ 13
3.2 – Autorização .................................................................................................................. 14
3.2.1 – O que é 3DS ........................................................................................................... 14
3.2.2 – Bandeiras, Emissores e Adquirentes ..................................................................... 14
3.2.3 – Como é a autenticação? ........................................................................................ 15
3.3 – Checkout Transparente ............................................................................................ 16
3.4 – Autorização – Utilizando o 3DS 2.0 .............................................................................. 19
3.5 – Captura ......................................................................................................................... 19
3.6 – Método de Cancelamento ........................................................................................... 21
3.7 – Método de Cancelamento Parcial ............................................................................... 22
4 – TOKENIZAÇÃO ..................................................................................................................... 25
4.1 – Criar Token ................................................................................................................... 25
4.2 – Obter Todos os Tokens ................................................................................................ 27
4.3 – Obter Um Token........................................................................................................... 29
4.4 – Excluir Token ................................................................................................................ 31
4.5 – Pagar ............................................................................................................................ 31
4.6 – Obter Tokens do Cliente. ............................................................................................. 34
5 – RECORRÊNCIA ..................................................................................................................... 35
5.1 - Conceito de Recorrência ............................................................................................... 35
5.2 – Criar Recorrência/Token .............................................................................................. 36
3
Página
5.3 – Alterar Toda Recorrência ............................................................................................. 38

5.4 – Alterar Dados de Pagamento da Recorrência .............................................................. 39
5.5 – Renovar Dados da Recorrência .................................................................................... 40
5.6 – Alterar Valor e Quantidade da Recorrência (Renovar) ................................................ 41
5.7 – Alterar a Data de Pagamento na Recorrência ............................................................. 42
5.8 – Alterar o Valor da Recorrência ..................................................................................... 43
5.9 – Alterar a Quantidade de Parceladas da Recorrência ................................................... 44
5.10 – Cancelar a Recorrência .............................................................................................. 44
6 – CONSULTAS ......................................................................................................................... 45
6.1 – Obter Operação por ReferenceId ................................................................................ 46
6.2 – Obter Operação por TransactionId .............................................................................. 47
6.3 – Obter Operação por Subdomínio com Faixa de Datas ................................................ 48
6.4 – Obter Operação por Subdomínio por mês/ano ........................................................... 49
6.5 – Obter Operação por Contrato...................................................................................... 49
6.6 – Obter Operação por Número Interno .......................................................................... 50
6.7 – Obter Operação por Subdomínio + Loja ID .................................................................. 51
6.8 – Obter as Operações pela Chave da Operação ............................................................. 52
7 – SPLIT DE PAGAMENTOS ...................................................................................................... 53
4
Página

GLOSSÁRIO
Item Descrição
(Ambiente) UAT User Acceptance Testing
(Ambiente) Hml Homologação
Acordo Tela de pagamento do link
Chave Chave única de composição e operação para acesso ao link
ReferenceId Chave única da operação para consultas
Token de Acesso Token Bearer usado para autenticar as chamadas na API.
1 – AUTENTICAÇÃO
A API funciona com autenticação modelo bearer. Obtém se um token de acesso e este é adicionado
as chamadas dos métodos da API.
A autenticação deve ser realizada antes de qualquer chamada. Ela dura 60 minutos. Portanto o token
pode ser reaproveitado em várias chamadas. Uma vez obtido o token deve ser acoplado a chamada
no header.
A seguir vamos entender o processo de como obter o token, efetuando um post na URL:
Ambiente URL
HML/UAT https://api-homolog.credpay.com.br/AuthCredPay
PROD https://api.credpay.com.br/AuthCredPay
Os parâmetros de acesso para autenticar na API (UAT/hml):

Parâmetro Valor
User UAT
Key QAWSEDRFTG
grant_type password
Observação: Os dados de usuário e chave serão criados pela nossa equipe para acesso em ambiente
UAT/homologação e passados para a sua equipe. Este User e senha acima são apenas exemplos e
não é válido para a sua homologação.
{
"User": "UAT",
"Key": "QAWSEDRFTG",
"grant_type": "password"
}
Em caso de teste no POSTMAN, enviar para autenticação usando x-www-form-URLencoded.
JSON Retornado
5
{
Página
"access_token": "<token(string>",
"token_type": "bearer",

"expires_in": 3599,
"EnderecoIp": "201.0.21.4",
"CriadoEm": "07/12/2022 15:45:20",
"ExpiraEm": "07/12/2022 16:45:20",
"TempoExpiracao": "60",
"SubDominioId": "2",
"UsuarioId": "3029",
"Nome": "UAT",
"Literal": "UAT",
"Permissoes": ""
}
Observação, a chave de produção será liberada futuramente.
Postman
2 – PRÉ OPERAÇÃO
A pré-operação é basicamente uma operação criada com uma finalidade de pagamento.
Pode ser considerada um pedido para pagamento de serviço, compra ou pagamento de uma conta.
Por exemplo, o estabelecimento vendeu um celular a um cliente por R$ 2.000,00 e o cliente deseja
pagar em mais de uma vez. O estabelecimento efetua uma consulta de um pagamento para os R$
2.000,00 e apresenta um simulador de valores e quantidade de parcelas. O cliente escolhe que
deseja pagar em 5 parcelas e o estabelecimento via o seu sistema faz a chamada à API da Credpay e é
criado a operação com os dados do cliente, tais como, nome, documento, e-mail, telefone (fixo e ou
celular), número de contrato, dentre outros.
Após efetivar a criação desta pré-operação, ela é armazenada em nosso ambiente e o cliente recebe
um link de pagamento para quitar a operação. Neste modelo o cliente acessa uma tela e faz o
pagamento da operação.
Existe a possiblidade de que o estabelecimento faça todo o processo de pagamento via API Credpay,
que estaremos em tópicos adiante descrevendo os checkouts para isto.
6
Página

Abaixo o fluxo de pagamento feito via link e via checkout/API.
Com Link:
O fluxo de pagamento via API funciona da seguinte forma:
Checkout via API:
2.1 – Simulação
Antes da criação de uma operação, a simulação é o primeiro passo para escolha, forma e como
será o pagamento ao cliente. Em resumo, será apresentada as opções para o cliente escolher.
A interface do estabelecimento deverá chamar a simulação e apresentar ao cliente as opções de

parcelamento para que o cliente escolha e siga para finalizar o fluxo do pagamento via API.
2.1.1 – Método de Simulação
O endpoint de simulação é:
Ambiente URL
HML/UAT https://api-homolog.credpay.com.br/Simulador/Simular/Parcelamento
PROD https://api.credpay.com.br/Simulador/Simular/Parcelamento
Tipo do Método: POST

Na chamada deve adicionar o token de autenticação no HEADER da requisição da seguinte forma:
Key: "Authorization"
Value: "Bearer <token obtido>"
“Authorization”: “Bearer <token>”
7
Onde <token> é exatamente o token recebido na autenticação da API (item 1 deste documento). É
Página
importante adicionar o token, ou a API devolverá erro 401, não autorizado.

No postman:
JSON de Entrada
{
"valorPrincipal": 2000.00,
"valorHonorarios": 0,
"servicoId": 1
}
Campo Obrigatório Descrição

valorPrincipal SIM Valor da Simulação
valorHonorarios Opcional Valor da Tarifa que o Estabelecimento cobra (caso haja tarifa)
servicoId SIM Id do serviço. Importante para obter a simulação e taxas aplicadas
O Retorno virá:
{
"retorno": {
"simulacaoParcelas": [
{
"parcela": 1,
"servicoId": 1,
"existeRentencao": false,
"valor": 1057.8,
"valorLiquido": 0,
"valorDaParcelaFixa": 1000,
"tipoOperacao": "Crédito",
"tipoOperacaoId": 2,
"valorTotal": 1057.8,
"valorRetencao": 0,
"taxaFixa": 5.78,
"taxaMensal": 5.78,
"taxaCobrada": 5.78
}
8
],
Página
"principal": 1000,
"valorRetencao": 0,

"temRetencao": false
},
"statusCode": 200,
"erros": [
],
"codigoMessagem": 0,
"messagem": null,
"valid": true,
"invalid": false,
"warning": false
}
O Campo de SimulacaoParcelas é um array de dados. Aqui no exemplo ilustrado ele foi resumido.
Vamos apresentar os mais importantes:
• Campo retorno: é o objeto de retorno da solicitação
• statusCode: Se tudo OK, virá com o valor de 200 (OK) ou 201 (Created).
• valid/invalid: indicam validação. Pode usar o retorno de valid como true para entender que o
procedimento foi ok. Caso contrário a propriedade ERROS mostrará as inconsistências.
• erros: array de mensagens que tem os erros e ou inconsistências encontradas.
Campo Descrição
parcela Quantidade de parcelas
servicoId Id do serviço
existeRentencao Se existe retenção – campo usado em parcelamento sem jutos e ou quando o
estabelecimento arca com os custos do parcelamento.
valor Valor total a ser passado no cartão
valorDaParcelaFixa Valor da parcela Fixa (sem o valor dos encargos)
Exemplo R$ 1.000,00 em 5X de R$ 110,00 por parcela. O valor da parcela fixa
será de R$ 100,00 (pois R$ 10,00 é o valor dos encargos)
tipoOperacao Descrição do tipo de operação (Crédito ou débito)
tipoOperacaoId ID do tipo => 1 para Crédito, 2 para Débito
valorTotal Valor total a ser passado no cartão (Valor da Parcela X Quantidade de parcelas)
valorRetencao Em caso de valor de parcela fixa, onde o estabelecimento arca com as taxas de
financiamento, este valor é o valor de desconto no repasse da venda
taxaFixa Valor da taxa aplicada no financiamento (% do valor principal em relação ao
valor total com encargos cobrados)
taxaMensal Valor da taxa ao mês do financiamento
2.2 – Criação da Pré-operação
Para criar uma pré-operação faz-se uma chamada a um endpoint
Ambiente URL
HML/UAT https://api-homolog.credpay.com.br/Operacao/EfetivarPreOperacao
9
PROD https://api.credpay.com.br/Operacao/EfetivarPreOperacao
Página
Tipo do Método: POST

Onde <token> é exatamente o código recebido na autenticação da API (item 1 deste documento). É
importante adicionar o token ou a API devolverá erro 401, não autorizado.
No postman:
O JSON de entrada será como o exemplo a seguir:

{
"nomeDoCliente": "João da Silva",
"documento": "14785744593",
"email": "joao.silva@credpay.com.vc",
"telefone": "00-0000-0000",
"celular": "00-00000-0000",
"lojaId": 1,
"servicoId": 1,
"codigoDeBarras": "<se tiver boleto inserir o código de barras>",
"contrato": "344545",
"contato": "José",
"credor": "Empresa Xpto",
"descricaoServico": "Compra de Aparelho Mobile",
"numeroInterno": "34454",
"quantidadeDeParcelas": 5,
"custoConveniencia": 0,
"valorInicial": 2000,
"softDescriptor": "XPTO Pagamentos"
}
Campo Obrigatório Descrição

nomeDoCliente Sim Nome do Cliente que vai pagar a operação
documento Sim Documento do cliente
10
email Sim E-mail do cliente

telefone Sim Número de Telefone do cliente
Página
celular Sim Número de Telefone Celular do cliente

lojaId Não Caso queira agrupar os pagamentos por seção/loja etc.

servicoId Sim Código do Serviço (Geralmente é 1 – Diversos)
codigoDeBarras Opcional Caso haja um boleto a ser pago pela operação este valor deve vir
preenchido com o código de barras.
contrato Não Número do contrato com o cliente
contato Não Contato que criou a operação
credor Não Nome do Credor. Usado geralmente em caso de empresas de
cobrança
descricaoServico Não Descrição da operação que será paga
numeroInterno Não Seu código interno
quantidadeDeParcelas Sim Quantidade de parcelas desejada para ser paga
custoConveniencia Não Caso queira cobrar uma taxa de serviço o valor será colocado
aqui. Não cobrando taxa, mandar 0, ou null.
valorInicial Sim Valor da operação
softDescriptor Não Descrição do gasto que aparecerá na fatura do cartão, na
ausência de preenchimento será colocado um valor padrão
cadastrado para vocês. Limite de 22 caracteres.
O campo “codigoDeBarras” é obrigatório quando a operação envolver um pagamento de boleto e o código

de barras deverá ser preenchimento. Nos demais casos ele não é um campo obrigatório.
O valor cobrado dependerá das taxas aplicadas que serão calculadas pela soma do (valor inicial + custo
adquirencia). Por exemplo, um débito de R$ 2.000,00 em 5 parcelas e considerando hipoteticamente uma
taxa de 10% para este prazo, o valor total desta transação seria de R$ 2.200,00 dividida em 5 parcelas iguais
de R$ 440,00.
Portanto, o método de simulação visa demonstrar o valor da transação composta dos encargos.
Fatos importantes:

• valid / invalid: indicam validação. Pode usar o retorno de valid como true para entender que o
procedimento foi ok. Caso contrário a propriedade ERROS mostrará as inconsistências.
JSON Retornado
{
"retorno": {
"link":"https://link.credpay.com.br/Pagamentos/Acordo/2922c75c-8d90-4277-94fd-907c89a8b479",
"chave": "2922c75c-8d90-4277-94fd-907c89a8b479",
"referenceId": "CP-COYOEWQQ7Y",
"nomeDoCliente": "Nome Cliente",
"eMail": "teste.teste@credpay.com.vc"
}
"statusCode": 200,
"erros": [],
11
"messagem": null,
Página
"valid": true,
"invalid": false,
"warning": false
}

2.3 Cancelamento da Pré-Operação
A pré-operação é definida pelo ciente informando o prazo de expiração do link e o cancelamento

é realizado automaticamente quando o prazo do link expira.
O link expira após X dias depois de ter sido gerado. Esse número de dias é configurável. E por
padrão é de dois dias. Se um link foi criado dia 23 de maio as 12h23, ele expira dia 25 de maio as
12h22. Ou seja, é considerado o Horário.
Havendo necessidade de cancelar uma pré-operação, existe dois endpoints que podem ajudar
nesta tarefa, a chave da PreOperação (uma string tipo GUID) ou o campo de Reference Id e se faz
necessário fazer uma chamada a um endpoint
Por Reference Id
Ambiente URL
HML/UAT https://api-homolog.credpay.com.br/Operacao/Cancel/ReferenceId/{referenceId}
PROD https://api.credpay.com.br /Operacao/Cancel/ReferenceId/{referenceId}
Tipo do Método: DELETE
Por Chave
Ambiente URL
HML/UAT https://api-homolog.credpay.com.br/Operacao/Cancel/Chave/{chave}
PROD https://api.credpay.com.br/Operacao/Operacao/Cancel/Chave/{chave}
Tipo do Método: DELETE
JSON Retornado
{
"retorno": “<mensagem de cancelado com sucesso>”
"statusCode": 200,
"erros": [],
"messagem": null,
"valid": true,
"invalid": false,
"warning": false
}
Caso haja erros, observar a propriedade Valid que será como false. E o Array de erros na propriedade “erros”.
3 – FLUXO DE CHECKOUT
O Fluxo de checkout é composto por um ciclo de chamadas na API composto pela autorização e
seguido pela captura.
12
Dentro do fluxo podemos usar algumas chamadas a respeito de validar a autenticação, como a
verificação do cartão.
Página

No caso de utilização em ambiente seguro com 3DS 2.0, os métodos de autorizar e capturar não
serão precisos ser usados. O fluxo 3DS oferece um ambiente de checkout integrado com a
adquirente que faz a validação segura do cliente e evita fraudes.
3.1 – Soft Descriptor
Nos casos de pagamento via token, recorrências, e checkout transparente é solicitado um campo
opcional chamado soft descriptor.
Este campo permite que o EC envie um texto alternativo de até 22 caracteres ao Nome Fantasia
cadastrado na Adquirente para demonstração da transação na fatura do Portador.
Como exemplo, pode-se ter o nome do Estabelecimento Comercial que está no cadastro da
Adquirencia mais o nome do intermediador que está recebendo o pagamento ou a identificação
do departamento da loja, sempre usando como delimitador o caractere asterisco (*).
Caso não seja informado um Soft Descriptor, será utilizado o Nome Fantasia do cadastro do
Subdomínio junto a Credpay.
3.1.1 – Regras de uso
• Possuir no máximo 22 caracteres. Caracteres além deste limite serão desprezados.

• Utilizar apenas os seguintes caracteres:
• A-Z (todas as letras maiúsculas)
• 0123456789
• caracteres especiais permitidos: % $ , . / ( ) + = = - *
• Não utilizar os seguintes caracteres (a transação será negada se um desses caracteres for
enviado no Soft Descriptor):
• a-z (todas as letras minúsculas)
• acentuações (qualquer caractere acentuado, maiúsculo ou minúsculo)
•
13
ç (c cedilha)
• qualquer caracteres especiais, como estes: ! ? : ; [ ] { } ' " # _ @ § ^ ~ ¨ \ < > & ¹ ² ³ ª º £ ¢ ¬
Página

3.2 – Autorização
O Método de autorização é o primeiro passo do pagamento de uma transação. É relativamente o

questionamento do estabelecimento para a adquirente a respeito de validar e autorizar a
transação.
A autorização pode ser variada, podendo ser Com ou Sem 3DS. Ou seja, se você usar o 3DS, terá
de efetuar algumas tarefas a mais sem a necessidade de fazer a captura.
3.2.1 – O que é 3DS
Com o objetivo de minimizar o índice de fraude sem prejudicar a taxa de conversão, a indústria
de meio de pagamento desenvolveu um padrão de autenticação, chamado EMV 3DS ou
também chamado de 3DS 2.0.
Antes, o 3DS 1.0, sempre era com desafio, ou seja, mandava-se a autorização para a
adquirente e esta devolvia um link do emissor para se autenticar e assim desta forma
validando o pagamento e identificando. Com a versão 2.0 ficou um pouco mais ágil e
transparente.
A nova versão é capaz de analisar dezenas de variáveis que são utilizadas como critérios para
determinar se um comprador é de fato o portador cartão, permitindo em alguns casos, a
autenticação silenciosa do mesmo (autenticação sem desafio), sem prejuízo à questão do
Liability Shift dos estabelecimentos.
3.2.2 – Bandeiras, Emissores e Adquirentes
Para envio de transações com pedido de autenticação 3DS 2.0 é fundamental que a
Adquirente, Emissor e Bandeira estejam prontos com a solução. As principais bandeiras do
mercado, tais como, Visa, Mastercard e Elo já estão disponíveis no 3DS 2.0. As bandeiras Visa e
Mastercard possuem um modelo de Stand-In, caso o Emissor ainda não esteja apto a
responder um pedido de autenticação usando EMV 3DS 2.0. Nesse cenário, a bandeira avalia
os dados enviados, como por exemplo o histórico comportamental do cliente e transacional,
classificando os pedidos de autenticação como “Baixo Risco” e “Não Baixo Risco”. A partir
dessas informações, os Emissores poderão contar com uma proteção mesmo não possuindo
uma solução própria de 3DS 2.0, e terão uma maior confiança nas transações autenticadas. Em
casos de Stand-In, a autenticação ocorre de forma silenciosa (sem desafio para o portador) e,
uma vez que a transação foi autenticada, o liability em caso de fraude ficará com o Emissor. A
decisão de autorizar ou não a transação é do Emissor. Em transações autenticadas pela
14
bandeira, a decisão de autorizar ou não a transação ainda é do Emissor, que pode negar as
Página
transações na etapa de autorização da transação.

3.2.3 – Como é a autenticação?
O diagrama acima ilustra como é o fluxo interno do 3DS.
Para uso de funcionalidade 3DS a resposta JSON é:

{
"Retorno": {
"TransacaoId": null,
"Cliente": "ZZZZZZZZ",
"Documento": "4444444444444",
"Token": null,
"DataTransacao": "0001-01-01T00:00:00",
"Status": 0,
"ValorDaVenda": 1000.0,
"ValorDaParcela": 1039.50,
"QuantidadeDeParcelas": 1,
"DescricaoStatus": "Transação Iniciada;",
"ReferenceId": "CP-D4qs5lvn",
"URLRedirect": "https://cred3ds.credpay.com.br/gn/64b15b2a79303f12b3754971",
"AuthenticationURL": null,
"SubDominioId": 898,
"URLRedirectFinal": null,
"URLReturn": null,
"CodeAuthorization": null,
"AuthenticationEci": "N/A",
"AuthenticationEciDescriptor": null,
"ProviderReference": "N/A",
"ProviderMessage": null,
"ProviderCode": null,
15
"Acquirer": null,
"AcquirerTransactionId": null,
Página
"Nsu": null,
"Sucesso": true

},
"StatusCode": 200,
"Erros": [],
"CodigoMessagem": 0,
"Messagem": null,
"Valid": true,
"Invalid": false,
"Warning": false
}
Neste caso você deve recuperar o conteúdo do URLRedirect e redirecionar para este link, para
que seja pago.
No momento não temos call-back, então se faz necessário efetuar consulta do status da
transação usando o valor do referenceId.
3.3 – Checkout Transparente
É quando não se usa 3DS e se faz necessário captura o pagamento.
O status de retorno são estes:

• StatusId: 0 => Transação Iniciada (no caso de ser 3Ds)
• StatusId: 5 => Autorizado
• StatusId: 7 => Negado
• Pode ocorrer um status de falha de comunicação (11), cartão inválido (12) e pendente
de confirmação (10).
No caso do cartão inválido pode ser evitado pela verificação do cartão.
Na chamada deve adicionar o token de autenticação no HEADER da requisição da seguinte

forma:
Onde <token> é exatamente o token recebido na autenticação da API (item 1 deste
documento). É importante adicionar o token, ou a API devolverá erro 401, não autorizado.
No postman:
16
Página

A chamada para a autorização é:
Ambiente URL
HML/UAT https://api-homolog.credpay.com.br/Transacao/Autorizar
PROD https://api.credpay.com.br/ Transacao/ Autorizar
Método tipo POST
Os parâmetros de verificação para a API(UAT/hml):
Dados de Entrada
{
"nomeDoCliente": "Joao da Silva",
"documento": "12489877852",
"email": "joao.silva@credpay.com.br",
"telefone": "11-0000-0000",
"celular": "11-00000-0000",
"lojaId": 1,
"servicoId": 1,
"codigoDeBarras": "",
"contrato": "147852",
"contato": "José Pereira",
"credor": "Empresa XPTO",
"descricaoServico": "Compra de Tickets para Show",
"softDescriptor": "XPTO*PAGAMENTO",
"typeCard": "1",
"number": "40000000000000000",
"expirationMonth": "12",
"expirationYear": "2029",
"cvv": "235",
"brand": "Visa",
"holderName": "Joao Da Silva",
"holderNameDocumento": "12587488952"
}
Os campos são TODOS obrigatórios, com exceção do código de barras, obrigatório só se existir
um boleto a ser pago, a loja id, que pode vir por padrão 1, ou não ser enviado e o campo
telefone e ou celular que podem ser replicados, ou seja valores iguais para ambos. E o campo
de credor, pode ser omitido.
Campo Descrição
nomeDoCliente Nome do Cliente na operação
17
documento Documento do cliente

Página
email Email do cliente

telefone Telefone do cliente

celular Celular do cliente
lojaId Loja Id – para separar por filial, loja ou seção do estabelecimento
servicoId Id do serviço, para a aplicação o e obtenção das taxas
codigoDeBarras Caso a operação seja pagar um boleto com o cartão, preencher com o
código de barras
contrato Id do contrato com o cliente
contato Contato com o cliente – quem fez a operação por exemplo
credor Nome do credor, para caso de empresa de cobranças
descricaoServico Descrição do serviço prestado ou da operação
quantidadeDeParcelas Quantidade de parcelas da operação
custoConveniencia Custo da tarifa do estabelecimento
valorInicial Valor (inicial) da operação. Valor líquido.
softDescriptor Nome que aparecerá na fatura do cartão
numeroInterno Seu id interno da operação.
typeCard Tipo de cartão => 1 para crédito e 2 para operação a débito.
number Número do cartão de crédito
expirationMonth Mês de expiração do cartão
expirationYear Ano de expiração do cartão
cvv Código de segurança
brand Bandeira
holderName Nome do dono do cartão, como apresentado no cartão
holderNameDocumento Documento do dono do cartão
Retorno do pagamento
É retornado um objeto que chamamos de ValidationResult, onde é importante ler o

campo/propriedade “Retorno”.
Abaixo apenas o retorno será listado:
{
"TransacaoId": "010000005105241324070000066790990000000000",
"Cliente": null,
"Documento": null,
"Token": null,
"DataTransacao": "0001-01-01T00:00:00",
"Status": 5,
"DescricaoStatus": "Transação Autorizada;",
"ReferenceId": "CP-KHORORTKWF",
"URLRedirect": "",
"AuthenticationURL": "",
18
"SubDominioId": 28,
"URLRedirectFinal": "",
Página
"URLReturn": null,
"CodeAuthorization": "006087",

"AuthenticationEci": "",
"ProviderReference": "Sucesso",
"ProviderMessage": "Sucesso",
"ProviderCode": "0",
"Acquirer": null,
"AcquirerTransactionId": 0,
"Nsu": null,
"Sucesso": true
}
É importante armazenar dois valores:
• ReferenceId
• TransactionId
Estes valores servirão para as chamadas de consulta, cancelamento e captura.
Pontos importantes:
• valid / invalid: indicam validação. Pode usar o retorno de valid como true para entender
que o procedimento foi ok. Caso contrário a propriedade ERROS mostra as
inconsistências.
3.4 – Autorização – Utilizando o 3DS 2.0
A autorização usando o 3DS dispensa a chamada da Captura.
Por padrão deixamos o 3DS habilitado para que tenhamos um passo a mais de segurança. Porém,
é importante verificar com nossa equipe se haverá a utilização Com ou Sem 3DS.
3.5 – Captura
A captura é apenas a confirmação da transação autorizada e significa que o cliente tem saldo
disponível no cartão para o concluir a transação.
Muitas lojas apenas autorizam a transação de início para fazerem uma “investigação” do cliente e
dos dados para prevenir-se contra fraudes. Após confirmação da veracidade da pesquisa, a
transação é capturada.
Ressaltamos que isto é um risco para a transação apenas autorizada, uma vez que ela não
19
compromete o limite, diferente da pré-autorização que compromete o limite do cartão do cliente.

Página

Como exemplo, citamos os hotéis que fazem a pré-autorização para garantir um valor de saldo no
pagamento da estadia, ou seja, o intervalo de tempo entre autorizar e capturar o cliente não
poderá usar o cartão em outras compras e comprometer o limite da transação já autorizada.
Por isso, recomendamos que ao autorizar seja efetuada na sequência a captura da transação.
O status de retorno são estes:
• StatusId: 6 => Transação Autorizada e Confirmada

• StatusId: 7 => Negado
• Pode ocorrer um status de falha de comunicação (11), e pendente de confirmação (10).
Na chamada deve adicionar o token de autenticação no HEADER da requisição da seguinte forma
No postman:
A chamada para a autorização é:

Ambiente URL
HML/UAT https://api-homolog.credpay.com.br/Transacao/Capturar/{transacaoId}/{referenceId}
PROD https://api.credpay.com.br/Transacao/Capturar/{transacaoId}/{referenceId}
Método tipo POST – Exemplo de uma URL de captura:

https://api-homolog.credpay.com.br/Transacao/Capturar/62fd3418eb07294ddc8729c9/CP-3iXACWq3
O retorno da Captura é:
{
20
"TransacaoId": "adc50dca-c8a4-4b44-9e5a-95cfd172912e",
"Cliente": "ab02 sobrenome",
Página
"Documento": "62963022077",
"Token": null,

"DataTransacao": "2022-11-25T10:10:56.6066455-03:00",
"Status": 6,
"DescricaoStatus": "Transação Autorizada e Confirmada;",
"ReferenceId": "SV-YDXK3XU5U1",
"Sucesso": true
}
Observação: No uso de 3Ds nas operações os métodos de captura e autorização são diferentes.
Pontos importantes:
inconsistências.
3.6 – Método de Cancelamento
O cancelamento de uma transação é feito quando se deseja o cancelamento TOTAL de uma

transação.
Esse método pode ser usado apenas no dia corrente, ou seja, no dia que a transação foi efetuada.
Em caso de cancelamento TOTAL após a data da transação deverá entrar em contato com o
Financeiro da Credpay.

No postman:
21
Página

A chamada para a o cancelamento total do cartão é:
Ambiente URL
HML https://api-homolog.credpay.com.br/Transacao/Cancelar/{transacaoId}/{referenceId}
PROD https://api.credpay.com.br/ Transacao/ Cancelar/{transacaoId}/{referenceId}
Os parâmetros de verificação para a API(UAT/hml):

• TransactionId é o id da transação
• ReferenceId é o id de referência da transação.
Ambos são devolvidos no checkout (autorização) de pagamento.
Exemplo de uma URL de cancelamento:

https://api-homolog.credpay.com.br/Transacao/Cancelar/62fd3418eb07294ddc8729c9/CP-3iXACWq3
Onde: 62fd3418eb07294ddc8729c9 é o TransactionId e CP-3iXACWq3 é o referenceId. Este

método não tem dados de entrada. Os valores vão diretamente na URL.
Exemplo do retorno:
{
"TransacaoId": "62fd3418eb07294ddc8729c9",
"Cliente": "JOAO DA SILVA ",
"Documento": "12457899632",
"Token": null,
"DataTransacao": "2022-05-24T15:16:23.7588911-03:00",
"Status": 9,
"DescricaoStatus": "Transação Cancelada;",
"ReferenceId": "CP-3iXACWq3",
"Sucesso": true
}
Pontos importantes:
• valid / invalid: indicam validação. Pode usar o retorno de valid como true para entender que o
procedimento foi ok. Caso contrário a propriedade ERROS mostra as inconsistências.
3.7 – Método de Cancelamento Parcial
O cancelamento parcial de uma transação é feito quando se deseja estornar um valor diferente
do valor total da transação. Por exemplo, o hotel fez uma pré-autorização de R$ 1.000,00 na
reserva do cliente, onde o valor estimado da transação cobre a diária e demais gastos. Ao realizar
o fechamento da estadia o cliente deve R$ 750,00. Neste caso, o cancelamento parcial permite
22
que seja estornado um valor parcial de R$ 250,00 dos R$ 1.000,00 previamente reservados.
Página
Esse método só poderá ser usado após a data da transação efetivada.

O fluxo do cancelamento parcial será:
1. Solicitação
2. Financeiro Credpay Aprova/Reprova o cancelamento.
3. Cancelamento, se aprovado é efetivado

No postman:
A URL para efetuar o cancelamento parcial a ser chamada é:

Ambiente URL
HML/UAT https://api-homolog.credpay.com.br/Transacao/Cancelar/Parcial
PROD https://api.credpay.com.br/Transacao/Cancelar/Parcial
Os parâmetros de acesso para autenticar na API(UAT/hml):

Parâmetro Tipo Contexto/Conteúdo
transactionId String Id do pagamento que será cancelado, exemplo: 5c4d4a2f-c151-4ccf-abeb-
3aa32a94a9fd
amount String Valor a ser cancelado em centavos. Por exemplo R$ 100,00 deve ser
enviado como "10000"
JSON de entrada
{
"transactionId": "5c4d4a2f-c151-4ccf-abeb-3aa32a94a9fd",
"amount": "1000"
}
23
Página

Os parâmetros:
No Postman, o post deve ser feito com o body, modo raw, e formato JSON.
Qualquer outra formatação modo, pode não funcionar.
O retorno é um objeto que contém informações importantes relacionado ao post efetuado.
Pontos importantes:
inconsistências.
O resultado esperado é:
{
"transactionId": "5c4d4a2f-c151-4ccf-abeb-3aa32a94a9fd",
"mensagem": "Cancelamento parcial solicitado com sucesso",
"valor": 10.0,
"subdominioId": 873
}
24
Página

4 – TOKENIZAÇÃO
A Tokenização é o meio de guardar cartões no cofre e poder reutilizar eles em outras oportunidades.
Aplicativos de pagamentos recorrentes de mensalidades e de venda por delivery costumam salvar o

cartão tokenizados num cofre e usá-los em oportunidades de novas cobranças.
Usaremos as seguintes situações de Tokenização

• Criar Token
• Obter Todos os Tokens
• Obter um Token
• Excluir Token
• Pagar Operação
• Obter Tokens do Cliente.
O caso de cancelar uma transação tokenizada segue o método de cancelamento já descrito acima na seção 3.6.
Importante: Não devemos confundir o token do cartão com token de acesso.
4.1 – Criar Token
A criação do token envolve guardar os dados do cartão do cliente no cofre.

No postman:
25
A URL para efetuar a criação do Token a ser chamada é:

Ambiente URL
Página
HML/UAT https://api-homolog.credpay.com.br/Tokenizacao/CriarToken
PROD https://api.credpay.com.br/Tokenizacao/CriarToken

Método tipo: POST

nomeDoCliente string Nome do Cliente
email string E-mail do Cliente
documento string Documento do Cliente
telefone string Telefone do Cliente
celular string Celular do Cliente
typeCard string Tipo de cartão => 1 – crédito/ 2 - débito
number string Número do cartão
expirationMonth string Mês de Expiração
expirationYear string Ano de Expiração
cvv string Código de Segurança
brand string Bandeira do Cartão
holderName string Nome do portador do cartão exatamente como está no cartão
holderNameDocumento string Documento do portador do cartão
quantidadeVezesRecorrencia número Para caso de recorrência, inserir a quantidade de vezes
dataCobrancaRecorrente date Para cobrança recorrente, a data da cobrança
valorInicial número Valor da venda
custoConveniencia número Custo / comissão a ser adicionado ao valor da venda
Todos os parâmetros são obrigatórios.
No caso do telefone celular/fixo eles podem ser replicados e ou iguais sem problemas.
Para a recorrência, é obrigatório a quantidade de vezes da recorrência, valor inicial, valor a cobrar
e a data. Deverá ser enviado custo como 0,00 caso não haja valor a cobrar e a data. Não sendo
para uma cobrança recorrente, pode omitir estes campos.
JSON de entrada
{
"nomeDoCliente": "string",
"documento": "string",
"email": "string",
"telefone": "string",
"celular": "string",
"typeCard": "string",
"number": "string",
"expirationMonth": "string",
"expirationYear": "string",
"cvv": "string",
"brand": "string",
26
"valorInicial": 0,
Página
"quantidadeVezesRecorrencia": 0,

"dataCobrancaRecorrente": "2023-01-17T15:04:10.045Z",
"holderName": "string",
"holderNameDocumento": "string
}
Resposta (simplificada, apenas o campo retorno e campos a considerar)

{
"tokenizacaoId": 0,
"subDominioId": 0,
"clienteVendaId": 0,
"bandeira": null,
"bin": null,
"tokenId": null,
"referenceId": null,
"cpfCnpj": null,
"valor": null,
"quantidadeVezesRecorrencia": null,
"dataCobrancaRecorrente": null,
"dataInclusao": "0001-01-01T00:00:00",
"ativo": false
}
Retorno:
Retorno Tipo Contexto/Conteúdo
tokenizacaoId Id interno do token em nossa base - desconsiderar
subDominioId Id do subdomínio do estabelecimento
clienteVendaId Id interno do cliente em nossa base – desconsiderar
bandeira Bandeira do cartão
Bin Bin do cartão para uso e exibição
tokenId Token. Id do token a ser guardado e para pagar operações. Com
isto recuperamos os dados do cartão do cliente e pagamos.
referenceId Número de referência
cpfCnpj CPF ou CNPJ do cliente
valor Valor total da recorrência
quantidadeVezesRecorrencia Quantidade de vezes que irá cobrar/recorrência
dataCobrancaRecorrente Data que será cobrado recorrente, todo mês
dataInclusao Data de inclusão do Token
ativo Verdadeiro ou falso.
4.2 – Obter Todos os Tokens
Esta chamada recupera todos os tokens cadastrado para seu subdomínio.

27

Página

No postman:
A URL para listar os tokens a ser chamada é:

Ambiente URL
HML/UAT https://api-homolog.credpay.com.br/Tokenizacao/Listar
PROD https://api.credpay.com.br/Tokenizacao/Listar
Método Tipo GET. Não tem parâmetros de entrada
Resposta, uma lista JSON dos objetos. Este não retorna como ValidationResult.
{
"tokenizacaoId": 0,
"subDominioId": 0,
"bandeira": null,
"bin": null,
"tokenId": null,
"cpfCnpj": null,
"valor": null,
"dataInclusao": "0001-01-01T00:00:00",
"ativo": false
}
Retorno:
28

Página


cpfCnpj Cpf ou CNPJ do cliente
4.3 – Obter Um Token
Esta chamada recupera um único token cadastrado para seu subdomínio. Tem o parâmetro do
Token ou Id do Token, por isso são duas chamadas distintas.

No postman:
A URL para obter o token a ser chamada é:
Por ID (número, Id interno, tokenizacaoId que é retornado nas consultas)

Ambiente URL
29
HML/UAT https://api-homolog.credpay.com.br/Tokenizacao/Obter/{id}
PROD https://api.credpay.com.br/Tokenizacao/Obter/{id}
Página
Método Tipo GET.

Por TokenId (GUID do token gerado pelo sistema)
Ambiente URL
HML/UAT https://api-homolog.credpay.com.br/ObterDadosToken/{tokenId}
PROD https://api.credpay.com.br/ObterDadosToken/{tokenId}
Método Tipo GET.
Resposta, um JSON. Se for por id número, este não retorna como ValidationResult. O que
recupera pelo TokenId (GUID) vem acoplado dentro de um ValidationResult no formato JSON.
O caminho a ser seguido nesta pesquisa fica a critério do desenvolvedor.

{
"tokenizacaoId": 0,
"subDominioId": 0,
"bandeira": null,
"bin": null,
"tokenId": null,
"cpfCnpj": null,
"valor": null,
"dataInclusao": "0001-01-01T00:00:00",
"ativo": false
}
Retorno:
tokenId Token. Id do token a ser guardado e para pagar
operações. Com isto recuperamos os dados do cartão
do cliente e pagamos.
30
Página

4.4 – Excluir Token
Efetua a remoção do token.

No postman:

Ambiente URL
HML/UAT https://api-homolog.credpay.com.br/Tokenizacao/Excluir/{tokenId}
PROD https://api.credpay.com.br/Tokenizacao/Excluir/{tokenId}
Método Tipo POST.
Não tem parâmetros de entrada.
O retorno é um ValidationResult, porém o campo retorno virá vazio. Se o validator vier sem erros
(Valid = true), significa que foi excluído com sucesso.
4.5 – Pagar
Esta chamada é para o pagamento usando token.

31

Página

No postman:

Ambiente URL
HML/UAT https://api-homolog.credpay.com.br/Tokenizacao/Pagar
PROD https://api.credpay.com.br/Tokenizacao/Pagar
Método Tipo POST.
Os parâmetros de verificação para a API (UAT/hml):
Dados de Entrada
{
"nomeDoCliente": "Joao da Silva",
"documento": "12489877852",
"email": "joao.silva@credpay.com.br",
"telefone": "11-0000-0000",
"celular": "11-00000-0000",
"lojaId": 1,
"servicoId": 1,
"contrato": "147852",
"contato": "José Pereira",
"credor": "Empresa XPTO",
"descricaoServico": "Compra de Tickets para Show",
"softDescriptor": "XPTO*PAGAMENTO",
"token": "string",
"cvv": "235",
}
Os campos são TODOS obrigatórios, com exceção da loja ID, que pode vir por padrão 1 ou não ser
32
enviado, e o campo telefone e ou celular que podem ser replicados, ou seja valores iguais para
Página
ambos. E o campo de credor, pode ser omitido.

Sendo cobrança recorrente, informe quantidadeVezesRecorrencia e a dataCobrancaRecorrente. E
neste caso a parcela é única (1X) na quantidade de parcelas.
Campo Descrição
nomeDoCliente Nome do Cliente na operação
documento Documento do cliente
email Email do cliente
telefone Telefone do cliente
celular Celular do cliente
lojaId Loja Id – para separar por filial, loja ou seção do estabelecimento
servicoId Id do serviço, para a aplicação o e obtenção das taxas
codigoDeBarras Caso a operação seja pagar um boleto com o cartão, preencher com o
código de barras
contrato Id do contrato com o cliente
contato Contato com o cliente – quem fez a operação por exemplo
credor Nome do credor, para caso de empresa de cobranças
descricaoServico Descrição do serviço prestado ou da operação
quantidadeDeParcelas Quantidade de parcelas da operação. Ao usar recorrência, preencher com
o valor de 1 para este campo
custoConveniencia Custo da tarifa do estabelecimento
valorInicial Valor (inicial) da operação. Valor líquido.
softDescriptor Nome que aparecerá na fatura do cartão
numeroInterno Seu id interno da operação.
token Token do cartão
quantidadeVezesRecorrencia Se for Recorrência, usar a quantidade de vezes a cobrar
dataCobrancaRecorrente Se for Recorrência, a data que será cobrada.
Retorno do pagamento

campo/propriedade “Retorno”, o qual apenas este será listado.
{
"TransacaoId": "010000005105241324070000066790990000000000",
"Cliente": null,
"Documento": null,
"Token": null,
"DataTransacao": "0001-01-01T00:00:00",
"Status": 5,
"DescricaoStatus": "Transação Autorizada;",
"ReferenceId": "CP-KHORORTKWF",
"URLRedirect": "",
33
"AuthenticationURL": "",
"SubDominioId": 28,
Página
"URLRedirectFinal": "",
"URLReturn": null,

"CodeAuthorization": "006087",
"AuthenticationEci": "",
"ProviderReference": "Sucesso",
"ProviderMessage": "Sucesso",
"ProviderCode": "0",
"Acquirer": null,
"AcquirerTransactionId": 0,
"Nsu": null,
"Sucesso": true
}
É importante armazenar dois valores:

• ReferenceId
• TransactionId
Estes valores vão servir para as chamadas de consulta, cancelamento e captura.
Pontos importantes:
inconsistências.
4.6 – Obter Tokens do Cliente.
Existem dois tipos de end points para a chamada.
Obter token pelo documento do cliente (CPF) e obter o Token por e-mail.

Por CPF, usar o endpoint abaixo, tipo GET

Ambiente URL
HML/UAT https://api-
34
homolog.credpay.com.br/Tokenizacao/Obter/Tokens/Documento/{documento}
PROD https://api.credpay.com.br/Tokenizacao/Tokenizacao/Obter/Tokens/Documento/{docu
Página
mento}

Por e-mail, usar o endpoint abaixo, tipo GET
Ambiente URL
HML/UAT https://api-homolog.credpay.com.br/Tokenizacao/Obter/Tokens/email /{ email }
PROD https://api.credpay.com.br/Tokenizacao/Tokenizacao/Obter/Tokens/email/{ email }
O retorno em ambos os casos será o mesmo, um array de tokens.

[
{
"tokenizacaoId": 0,
"token": "string",
"bandeira": "string",
"bin": "string",
"email": "string",
"dataInclusao": "2023-07-27T15:18:09.708Z",
"ativo": true
}
]
5 – RECORRÊNCIA
5.1 - Conceito de Recorrência
A recorrência é formada por uma quantidade de pagamentos a serem debitados na fatura de um

cliente sem que seja tomado o seu limite.
Por exemplo citamos, uma compra de R$ 1.000,00 parcelada em 10 vezes, onde, mensalmente
debitamos o valor de R$ 100,00 na fatura do titular do cartão. Desta forma, o cliente continua com o
limite de crédito em seu cartão para ser utilizados em outras compras e serviços.
Para a criação e consulta de uma recorrência observar o capítulo 4 (Tokenização).
Para o processo de ajuste, alteração, cancelamento ou renovação da recorrência serão utilizados os

seguintes endpoints:
• Criar Recorrência/Token
• Alterar Toda Recorrência
• Alterar Dados de Pagamento da Recorrência
• Renovar a Recorrência (Renovar) – Alterar dados da recorrência
• Alterar a Recorrência (Renovar) – Alterando valor e quantidade da Recorrência
• Alterar a Recorrência – Alterar data de pagamento
• Alterar a Recorrência – Alterar valor da recorrência
35
• Alterar a Recorrência – Altera Quantidade de Parcelas

• Cancelar a Recorrência
Página

5.2 – Criar Recorrência/Token
A criação da recorrência é semelhante a criação do token, conforme descrito no item 4 deste

manual, envolve em guardar os dados do cartão do cliente no cofre.

No postman:
A URL para efetuar a criação do Token a ser chamada é:

Ambiente URL
HML/UAT https://api-homolog.credpay.com.br/Tokenizacao/CriarToken
PROD https://api.credpay.com.br/Tokenizacao/CriarToken
Método tipo: POST

nomeDoCliente string Nome do Cliente
email string E-mail do Cliente
documento string Documento do Cliente
telefone string Telefone do Cliente
celular string Celular do Cliente
typeCard string Tipo de cartão => 1 – crédito/ 2 - débito
number string Número do cartão
expirationMonth string Mês de Expiração
expirationYear string Ano de Expiração
cvv string Código de Segurança
brand string Bandeira do Cartão
holderName string Nome do portador do cartão exatamente como está no cartão
holderNameDocumento string Documento do portador do cartão
36
quantidadeVezesRecorrencia número Para caso de recorrência, inserir a quantidade de vezes

dataCobrancaRecorrente date Para cobrança recorrente, a data da cobrança
Página
valorInicial número Valor da venda

custoConveniencia número Custo / comissão a ser adicionado ao valor da venda

Todos os parâmetros são obrigatórios.
No caso do telefone celular/fixo eles podem ser replicados e ou iguais sem problemas.
Para a recorrência, é obrigatório a quantidade de vezes da recorrência, valor inicial, e custo enviado
como 0,00 caso não haja e ou o valor a cobrar e a data. Não sendo para uma cobrança recorrente,
pode omitir estes campos.
JSON de entrada
{
"nomeDoCliente": "string",
"email": "string",
"telefone": "string",
"celular": "string",
"typeCard": "string",
"number": "string",
"expirationMonth": "string",
"expirationYear": "string",
"cvv": "string",
"brand": "string",
"valorInicial": 0,
"holderName": "string",
"holderNameDocumento": "string
}
Resposta (simplificada, apenas o campo retorno e campos a considerar)

{
"tokenizacaoId": 0,
"subDominioId": 0,
"bandeira": null,
"bin": null,
"tokenId": null,
"cpfCnpj": null,
"valor": null,
"dataInclusao": "0001-01-01T00:00:00",
"ativo": false
}
Retorno:
37

Página


5.3 – Alterar Toda Recorrência
Para que seja efetuado uma alteração total da recorrência, existem dois caminhos:
1) Excluir um token e depois criar um token novo, com dados do cartão novo, data de
pagamento, quantidade de parcelas, etc.
2) Chamar o endpoint do tipo POST.
Ambiente URL
HML/UAT https://api-homolog.credpay.com.br/Recorrencia/Alterar/Tudo
PROD https://api.credpay.com.br/Tokenizacao/Recorrencia/Alterar/Tudo
Dados de entrada:
Excetuando o subdomínio que se não for preenchido será recuperado da sua autenticação, todos os
campos abaixo são obrigatórios.
Tipo Nome Descrição
int SubDominioId Id de subdomínio – não obrigatório
string Token Token do cartão
string Number Número do novo cartão
string ExpirationMonth Mês de Expiração
string ExpirationYear Ano de Expiração
string Cvv Número de Segurança do cartão
string HolderName Nome que aparece no cartão
string HolderNameDocumento Documento do proprietário do Cartão
string Bandeira Bandeira do cartão
int QuantidadeVezesRecorrencia Quantidade de vezes da recorrência – deve ser diferente de 0
DateTime DataCobrancaRecorrente Data da cobrança da recorrência, mesmo que não mude, nesse
caso deve ser preenchido
decimal Valor Valor da recorrência, mesmo que não mude, nesse caso deve ser
preenchido
Retorno da chamada
38

Página

No caso de sucesso teremos uma mensagem de ok:
{
Sucesso = true,
Mensagem = "Alterado com sucesso."
}
No caso erro e insucesso teremos uma mensagem de ok:

{
Sucesso = false,
Mensagem = "Ocorreram erros verifique as mensagens de erro."
}
Pontos importantes:
• valid / invalid: indicam validação. Pode usar o retorno de valid como true para entender que
o procedimento foi ok. Caso contrário a propriedade ERROS mostrará as inconsistências.
5.4 – Alterar Dados de Pagamento da Recorrência
Semelhante ao item anterior, este endpoint altera os dados do cartão, porém, mantendo o Token.
Este procedimento serve para alterar os dados do cartão de pagamento mantendo data, valor e
vezes da recorrência.
O endpoint é do tipo POST.

Ambiente URL
HML/UAT https://api-homolog.credpay.com.br/Recorrencia/Alterar/Pagamento
PROD https://api.credpay.com.br/Recorrencia/Alterar/Pagamento
Dados de entrada:
string Number Número do novo cartão
string ExpirationMonth Mês de Expiração
string ExpirationYear Ano de Expiração
string Cvv Número de Segurança do cartão
string HolderName Nome que aparece no cartão
string HolderNameDocumento Documento do proprietário do Cartão
string Bandeira Bandeira do cartão
Retorno da chamada
39
É retornado um objeto que chamamos de ValidationResult, onde se faz importante ler o

Página

{
Sucesso = true,
}

{
Sucesso = false,
}
Pontos importantes:
o procedimento foi ok. Caso contrário a propriedade ERROS mostrará as inconsistências.
5.5 – Renovar Dados da Recorrência
Este endpoint renova a recorrência, alterando a data, valor e quantidade sem alterar o cartão.
O endpoint é do tipo POST.

Ambiente URL
HML/UAT https://api-homolog.credpay.com.br/Recorrencia/Renovar
PROD https://api.credpay.com.br/Recorrencia/Renovar
Dados de entrada:
int QuantidadeVezesRecorrencia Quantidade de vezes da recorrência – deve ser diferente de 0
DateTime DataCobrancaRecorrente Data da cobrança da recorrência, mesmo que não mude, nesse
caso deve ser preenchido
decimal Valor Valor da recorrência, mesmo que não mude, nesse caso deve ser
preenchido
Retorno da chamada
É retornado um objeto que chamamos de ValidationResult, com o campo/propriedade “Retorno”.

40
{
Sucesso = true,
Página

}

{
Sucesso = false,
}
Pontos importantes:
o procedimento foi ok. Caso contrário a propriedade ERROS mostra as inconsistências.
5.6 – Alterar Valor e Quantidade da Recorrência (Renovar)
Este endpoint renovação da recorrência executa a alteração do valor e quantidade de vezes sem
mexer no meio de pagamento, mas mantendo o cartão. Não será alterada a data de pagamento
nesta chamada, apenas valor e quantidade de parcelas.
O endpoint que abordamos aqui, que é do tipo POST.

Ambiente URL
HML/UAT https://api-homolog.credpay.com.br/Recorrencia/Renovar /{token}/{quantidade}/{valor}
PROD https://api.credpay.com.br/Recorrencia/Renovar /{token}/{quantidade}/{valor}
Dados de entrada:
Todos os campos abaixo são obrigatórios. O SubDominioId será recuperado pela sua autenticação
int Quantidade Quantidade de vezes da recorrência – deve ser diferente de 0
decimal Valor Valor da recorrência, mesmo que não mude, nesse caso deve ser preenchido
Retorno da chamada
É retornado um objeto que chamamos de ValidationResult, com o campo/propriedade “Retorno”.

{
Sucesso = true,
}

41
{
Página
Sucesso = false,
}

Pontos importantes:
5.7 – Alterar a Data de Pagamento na Recorrência
Este endpoint executa a alteração da data de pagamento da recorrência, sem mexer no meio de
pagamento, porém, mantendo o cartão. Não será alterada a quantidade de parcelas ou valor do
pagamento nesta chamada.

Ambiente URL
HML/UAT https://api-homolog.credpay.com.br/Recorrencia/Alterar/Data/{token}/{data}
PROD https://api.credpay.com.br/Recorrencia/Alterar/Data/{token}/{data}
Dados de entrada:
string Data Data da Recorrência. É um valor String e deve estar no formato yyyymmdd,
por exemplo:
Dia 10 de março de 2023 => 20230310
Dia 23 de maio de 2023 => 20230523
O valor do campo deve estar na URL
Retorno da chamada


{
Sucesso = true,
}

{
Sucesso = false,
}
42
Página
Pontos importantes:

5.8 – Alterar o Valor da Recorrência
Este endpoint executa a alteração do valor da recorrência, sem mexer no meio de pagamento,
porém, mantendo o cartão. Não será alterada a quantidade de parcelas ou data do pagamento nesta
chamada.

Ambiente URL
HML/UAT https://api-homolog.credpay.com.br/Recorrencia/Alterar/Data/{token}/{valor}
PROD https://api.credpay.com.br/Tokenizacao/Recorrencia/Alterar/Data/{token}/{valor}
Dados de entrada:
decimal valor Valor da Recorrência.
Retorno da chamada
É retornado um objeto chamado de ValidationResult com o campo/propriedade “Retorno”.

{
Sucesso = true,
}

{
Sucesso = false,
}
Pontos importantes:
43
Página

5.9 – Alterar a Quantidade de Parceladas da Recorrência
Este endpoint executa a alteração da quantidade de vezes da recorrência, sem mexer no meio de
pagamento, mantendo o cartão. Não será alterada o valor de parcelas ou data do pagamento nesta
chamada.

Ambiente URL
HML/UAT https://api-homolog.credpay.com.br/Recorrencia/Alterar/Data/{token}/{quantidade}
PROD https://api.credpay.com.br/Tokenizacao/Recorrencia/Alterar/Data/{token}/{quantidade}
Dados de entrada:
decimal quantidade Quantidade da Recorrência.
Retorno da chamada


{
Sucesso = true,
}

{
Sucesso = false,
}
Pontos importantes:
5.10 – Cancelar a Recorrência

44
Este endpoint efetua o cancelamento da recorrência.

Página

Neste endpoint não é excluído o token, que se mantém ativo na base de dados. O cancelamento da
recorrência mantém o token ativo sem data de pagamento, sem quantidade de parcelas e sem valor.

Ambiente URL
HML/UAT https://api-homolog.credpay.com.br/Recorrencia/Cancelar/{token}
PROD https://api.credpay.com.br/Tokenizacao/Recorrencia/Cancelar/{token}
Dados de entrada:
Todos os campos abaixo são obrigatórios e o SubDominioId será recuperado pela sua autenticação
string token Token a ser cancelado.
Retorno da chamada


{
Sucesso = true,
}

{
Sucesso = false,
}
Pontos importantes:
6 – CONSULTAS
Existem várias chamadas específicas para consultas das operações, cujos métodos de consulta
permitem verificar uma ou várias operações dependendo do tipo de consulta.
45
Tipos de consultas:
• Obter operação por referenceId (retorna uma operação única).
Página
• Obter operação por TransactionId (retorna uma operação única).

• Obter operação por subdomínio com faixa de datas (retorna lista de uma ou mais operações).
• Obter operação por subdomínio por mês/ano (retorna lista de uma ou mais operações).
• Obter operação por contrato (retorna lista de operações – uma ou mais operações).
• Obter operação por número interno (retorna lista de operações – uma ou mais operações).
• Obter operação por subdomínio + loja id (retorna lista de uma ou mais operações).
• Obter as operações pela chave da operação.
JSON Retornado. O exemplo abaixo é para uma operação.

{
"referenceId": "CP-P42gZNCn",
"nomeDoCliente": "teste",
"documento": "48326190802",
"email": "teste@email.com.br",
"celular": "",
"telefone": "",
"situacao": "3",
"chave": "51a7583f-3c5f-4272-a97a-488c9eafd62b",
"servicoId": "1",
"subDominioId": "28",
"usuarioId": "1695",
"quantidadeParcelas": "1",
"valorParcela": "21.16000",
"contrato": "teste",
"lojaId": "28",
"operacaoGatewayId": "410918",
"valorOriginal": "21.1600",
"cardBin": "400000******1091",
"valor": "21.1600",
"valorCancelado": "0.0000",
"statusPagamento": "7",
"nsu": "211761305461114032",
"codigoAutorizacao": null,
"providerCode": "-1",
"providerMessage": "CARTAO NAO AUTENTICAVEL",
"data": "11/14/2022 11:46:58",
"dataRepasse": "11/16/2022 11:46:58",
"transactionId": "BD22D0B4-9D2E-4B3A-B89D-E28B02C530AB"
}
Se for uma lista, ele retornará um array do objeto retornado acima.
6.1 – Obter Operação por ReferenceId
Obter os dados da operação pelo valor do campo referenceId.

46
Página
Na chamada deve adicionar o token de autenticação no HEADER da requisição da

seguinte forma:

documento). É importante adicionar o token, ou a API devolverá erro 401, não
autorizado.
No postman:
A URL para obter os dados da operação a ser chamada é:

Ambiente URL
HML/UAT https://api-homolog.credpay.com.br/Consulta/ReferenceId/{referenceId}
PROD https://api.credpay.com.br/Consulta/ReferenceId/{referenceId}
Método Tipo GET.
6.2 – Obter Operação por TransactionId
Obter os dados da operação pelo valor do campo TransactionId.

No postman:
47
Página

Ambiente URL
HML/UAT https://api-homolog.credpay.com.br/Consulta/TransactionId/{transactionId}
PROD https://api.credpay.com.br/Consulta/TransactionId/{transactionId}
Método Tipo GET.
6.3 – Obter Operação por Subdomínio com Faixa de Datas
Obter os dados da operação pelo seu subdomínio e a faixa de datas. O subdomínioId é

recuperado do seu acesso via token bearer, que é adicionado nas chamadas.

No postman:

48
Ambiente URL
HML/UAT https://api-
Página
homolog.credpay.com.br/Consulta/Subdominio/Datas/{dataInicial}/{dataFinal}

PROD https://api.credpay.com.br/Consulta/Subdominio/Datas/{dataInicial}/{dataFinal}
Método Tipo GET.
As datas devem ser enviadas no formato ansi, por exemplo 15/02/2022 (15 de fevereiro)
enviamos 20220215.
6.4 – Obter Operação por Subdomínio por mês/ano
Obter os dados da operação pelo seu subdomínio e a o mês e ano citados. O subdomínioId é

No postman:

Ambiente URL
HML/UAT https://api-homolog.credpay.com.br/Consulta/Subdominio/Mes/Ano/{mes}/{ano}
PROD https://api.credpay.com.br/Consulta/Subdominio/Mes/Ano/{mes}/{ano}
Método Tipo GET.
Os campos de mês e ano são números. Não se faz necessário dois dígitos para meses que só tem
um digito. Exemplo Fevereiro, enviar 2 e não 02.
6.5 – Obter Operação por Contrato

49
Obter os dados da operação pelo valor do campo de Contrato. Geralmente este campo é o seu ID
Página
do contrato ou algum tipo de referência em seu sistema. Na criação das operações ele não é
obrigatório, porém auxilia em seu controle caso deseje usar. Pesquisamos pelo seu número de

contrato registrado na operação com seu subdomínio acoplado na referência dos dados. O
subdomínioId é recuperado do seu acesso via token bearer, que é adicionado nas chamadas.

No postman:

Ambiente URL
Método Tipo GET.
6.6 – Obter Operação por Número Interno
Obter os dados da operação pelo valor do campo Número interno.
Geralmente este campo é o seu id interno em seu sistema. Na criação das operações ele não é
obrigatório, porém auxilia em seu controle caso deseje usá-lo. Pesquisamos pelo seu número
interno registrado na operação com seu subdomínio acoplado na referência dos dados. O
subdomínioId é recuperado do seu acesso via token bearer, que é adicionado nas chamadas.

No postman:
50
Página

Ambiente URL
Método Tipo GET.
6.7 – Obter Operação por Subdomínio + Loja ID
Obter os dados da operação pelo valor do campo LojaId.
Geralmente este campo é o seu controle de loja/filial. Na criação das operações ele não é
obrigatório, porém auxilia em seu controle caso deseje usar. Pesquisamos pelo seu LojaId (filial)
registrado na operação com seu subdomínio acoplado na referência dos dados. O subdomínioId é
Na inexistência de uso de filiais, esta consulta não se torna útil.

No postman:
51
Página

Ambiente URL
HML/UAT https://api-homolog.credpay.com.br/Consulta/Subdominio/lojaid/{lojaId}
PROD https://api.credpay.com.br/Consulta/Subdominio/lojaid/{lojaid}
Método Tipo GET.
6.8 – Obter as Operações pela Chave da Operação
Esta consulta é simples para que se entenda se houve ou não o pagamento. Muitas vezes criamos
o link e não temos mais informações para verificar se a operação está ou não “ok”. E pode ser que
não tenhamos outro parâmetro a não ser a própria chave que serve para o pagamento da
operação.

No postman:
52
Página

Ambiente URL
HML/UAT https://api-homolog.credpay.com.br/Consulta/chave/{chave}
PROD https://api.credpay.com.br/Consulta/chave/{chave}
Método Tipo GET.
7 – SPLIT DE PAGAMENTOS
O split de pagamentos é o redirecionamento do repasse para múltiplos beneficiários, ou seja, você

tem um pagamento a repassar e precisa direcionar o valor particionado para uma ou mais pessoas,
empresas ou prestadores.
Antes de direcionar o pagamento por split é preciso ter um pagamento (transação) previamente
aprovado. É um requisito mandatário ter um pagamento aprovado, tanto que a informação precisa
que valide se a transação é a (TransactionId), para que seja feita a amarração/relacionamento da
transação ao split.
Por dentro da requisição deve conter os dados do pagamento, e as suas participações respectivas.


Ambiente URL
HML/UAT https://api-homolog.credpay.com.br/Operacao/Servico/Cadastrar
PROD https://api.credpay.com.br/Operacao/Servico/Cadastrar
Método Tipo POST.
JSON Enviado. O exemplo abaixo é para uma operação.

{
"transacaoId": "string",
"consolidacaoReferenceId": " string ",
"referenceId": " string ",
"subDominioId": 0,
"numeroInterno": "string",
"valorBruto": 0,
"participacao": 0,
"valorParticipacao": 0,
53
"statusOperacaoServicoId": 0,
"dataInclusao": "2023-07-19T15:51:14.525Z",
Página
"dataPagamento": "2023-07-19T15:51:14.525Z",
"dataVencimento": "2023-07-19T15:51:14.525Z",

"consistente": true,
"tef": true,
"servicosPrestados": [
{
"descricaoDoServicoPrestado": "string",
"percentualRepasse": 0,
"valorRepasse": 0,
"nomeFavorecido": "string",
"documentoIdentificacao": "string",
"numeroDoBanco": "string",
"agencia": "string",
"agenciaDigito": "string",
"conta": "string",
"contaDigito": "string"
}
]
}
Observação importante, a soma de valores e/ou o percentual de repasse na lista de serviços

prestados devem estar iguais ao valor da transação de origem.
Ou seja, seu serviço custou R$ 500,00 e hipoteticamente há encargos de 10% a serem acrescidos ao
cliente, o que totaliza o valor de R$ 550,00. Desta forma, os valores de split deve ser igual ao valor de
bruto que neste exemplo é de R$ 550,00.
Se o cadastro estiver OK, você receberá um validation results com uma mensagem de sucesso no
campo de retorno.
Descrição detalhada dos campos

1. Os campos transação e referenceId, são campos que representa a operação quando
autoriza e captura eles são devolvidos, e, para o split devem ser repassadas para
identificarmos a operação.
2. Consolidacaoreferenceid e número interno são valores que o cliente define, códigos
internos para eles serem identificados por vossos clientes.
3. Valor Bruto e participação podem vir zerados.
4. Data de pagamento é a data da transação, e a de vencimento é a limite para a
transferência do repasse splitado.
5. Campo consistente, ignorar.
6. Campo TEF, colocar false. Pois a operação é gateway
7. Dentro do node serviços prestados vão o array de campos que demonstra o split.
8. Descrição do serviço, é uma descrição que você coloca relacionado ao split. Por exemplo
o salão de cabeleireiro o cliente fez cabelo e unhas, então você descreve o que vai no
split (por exemplo para a parte da manicure uma descrição que faça esta referência)
54
9. Percentual de repasse ou valor. Não precisa vir os dois. Preenchendo um ignora o outro.
Atentar-se que a soma dos percentuais deve ser 100% e ou dos valores ser igual ao valor
Página
bruto.

10.Nome do favorecido, é do favorecido do repasse.
11.Documento de identificação, prefira CPF/CNPJ. Facilita a transferência e é dado do
favorecido.
12.Dados bancários dos favorecidos.
FIM
55
Página

CREDHELP API Nov23

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

CREDHELP API Nov23

Enviado por

Direitos autorais:

Formatos disponíveis

[Capture a atenção do leitor com uma ótima citação do documento ou use este espaço para enfatizar um

Facilita Sua Vida!

MÉTODOS CHECK OUT

Data Versão Alteração Autor

16/01/2023 1.0 Criação Humberto Almeida

CRED-HELP (pt-br): 0002/2023

5.3 – Alterar Toda Recorrência ............................................................................................. 38

CRED-HELP (pt-br): 0002/2023

CRED-HELP (pt-br): 0002/2023

Os parâmetros de acesso para autenticar na API (UAT/hml):

CRED-HELP (pt-br): 0002/2023

A pré-operação é basicamente uma operação criada com uma finalidade de pagamento.

CRED-HELP (pt-br): 0002/2023

O fluxo de pagamento via API funciona da seguinte forma:

Checkout via API:

A interface do estabelecimento deverá chamar a simulação e apresentar ao cliente as opções de

2.1.1 – Método de Simulação

Tipo do Método: POST

importante adicionar o token, ou a API devolverá erro 401, não autorizado.

CRED-HELP (pt-br): 0002/2023

Campo Obrigatório Descrição

CRED-HELP (pt-br): 0002/2023

2.2 – Criação da Pré-operação

Para criar uma pré-operação faz-se uma chamada a um endpoint

Tipo do Método: POST

CRED-HELP (pt-br): 0002/2023

O JSON de entrada será como o exemplo a seguir:

Campo Obrigatório Descrição

email Sim E-mail do cliente

celular Sim Número de Telefone Celular do cliente

CRED-HELP (pt-br): 0002/2023

O campo “codigoDeBarras” é obrigatório quando a operação envolver um pagamento de boleto e o código

• Campo retorno: é o objeto de retorno da solicitação

CRED-HELP (pt-br): 0002/2023

A pré-operação é definida pelo ciente informando o prazo de expiração do link e o cancelamento

CRED-HELP (pt-br): 0002/2023

3.1 – Soft Descriptor

3.1.1 – Regras de uso

• Possuir no máximo 22 caracteres. Caracteres além deste limite serão desprezados.

CRED-HELP (pt-br): 0002/2023

O Método de autorização é o primeiro passo do pagamento de uma transação. É relativamente o

3.2.1 – O que é 3DS

3.2.2 – Bandeiras, Emissores e Adquirentes

transações na etapa de autorização da transação.

CRED-HELP (pt-br): 0002/2023

O diagrama acima ilustra como é o fluxo interno do 3DS.

Para uso de funcionalidade 3DS a resposta JSON é:

CRED-HELP (pt-br): 0002/2023

3.3 – Checkout Transparente

É quando não se usa 3DS e se faz necessário captura o pagamento.

O status de retorno são estes:

No caso do cartão inválido pode ser evitado pela verificação do cartão.

Na chamada deve adicionar o token de autenticação no HEADER da requisição da seguinte

CRED-HELP (pt-br): 0002/2023

Os parâmetros de verificação para a API(UAT/hml):

documento Documento do cliente

email Email do cliente

CRED-HELP (pt-br): 0002/2023

É retornado um objeto que chamamos de ValidationResult, onde é importante ler o

Abaixo apenas o retorno será listado:

CRED-HELP (pt-br): 0002/2023

Estes valores servirão para as chamadas de consulta, cancelamento e captura.

3.4 – Autorização – Utilizando o 3DS 2.0