Histórico de mensagens sobre dados em cartões

Conforme informado acima, a analise vai além de limite de saldo, ela se estende a verificação de dados, histórico do cartão, índice de Chargeback, entre outros.

Como não passa por uma nova analise e como ficar batendo cabeça sempre no mesmo lugar sem olhar para mudanças validas dos dados.

a Falha esta bem aqui na resposta da @jhainaraefi deveria refazer a analise com o novo endereço que o cliente realmente mudou.

Resumindo, se o cliente nosso mudar de endereço e atualizar os dados em nossa plataforma e utilizar o cartao do endereço antigo, nao vai conseguir passar por que a Efí acha que os dados do endereço esta errado, mas na verdade o consumidor mudou de endereço

A forma adotada por empresas do segmento de intermediação de pagamentos, que é o segmento da Efí, é utilizar serviços terceirizados de instituições que são referência nacional em prevenção à fraude, possuindo metodologias próprias e dados estatísticos específicos para classificar uma transação/cartão.

A Efí confia a essas instituições a realização das análises estatísticas, e recebemos das mesmas as devidas classificações da compra e a orientação para cancelar uma transação caso ela não apresente os padrões de segurança desejados, que foi o que ocorreu com essa transação. Ao ser cancelada a compra, a comunicação inversa é realizada, o cancelamento é enviado de volta para a adquirente que comunicará a bandeira do cartão a informação

Diante do exposto, sugerimos que emita uma nova cobrança ao seu cliente para uma nova avaliação. Por se tratar de uma analise interna, não é possível precisar se a próxima transação será aprovada ou não. Se necessário, o oriente à utilizar outro cartão ou disponibilize outra forma de pagamento.

Ela realmente mudou o endereço e mudou recentemente os dados de endereço do cartao dela

Olá @thalesmatoso bom dia 🧡.
Compreendi as informações acima, referente a cobrança informada.
Sugiro que emita uma nova cobrança ao seu cliente para uma nova avaliação. Se necessário, oriente à utilizar outro cartão ou disponibilize outra forma de pagamento. Uma transação uma vez recusada, não passa por uma nova análise.

Neste caso, a análise vai além de limite e saldo, ela se estende a verificação de dados, histórico do cartão, índice de Chargeback, entre outros. Não interferimos na análise, porém após verificação, temos um score (soma de todas análises estatísticas do cartão) e o resultado, aprovação ou não. Consideramos as análises como assertivas e após registramos o retorno em sua conta. Este é um procedimento normal de empresas onlines e as empresas supracitadas atuam com diversos segmentos de mercado online, por isso, realmente confiamos nas verificações.

Olá pessoal estou tendo o seguinte problema ao bater no endpoint para gerar o payment token:

feign.FeignException$InternalServerError: [500 Internal Server Error] during [POST] to [https://tokenizer.gerencianet.com.br/card" class="link-msg">https://tokenizer.gerencianet.com.br/card] [PaymentTokenizerInterface#getPaymentTokens(String,String)]: [{"code":3500011,"error":"invalid_data","error_description":"Não foi possível recuperar os dados enviados."}]
No endpoint: "https://tokenizer.gerencianet.com.br/"
Alguem poderia informar o que pode causar isso?

Sendo que se eu criar o carnê via api, eu consigo pegar os dados através do id

Boa tarde, pessoal!
Quais eram os dados de pagamento com cartão de testes mesmo? Tipo, os dados de cartão que no ambiente sandbox a gente simula pagamento realizado, pagamento não efetuado, etc. Lembro que vi em algum lugar mas não encontrei mais.

{
"code": 3500030,
"error": "charge_already_paid",
"error_description": "Esta transação já possui uma forma de pagamento definida."
}

Estou tendo este retorno com frequencia em ambiente de sandbox pois tenho uma equipe de 3 desenvolvedores e o ID da transação é vinculado ao ID do pedido que é o sequencial do banco de dados, Logo suponho que por haver conflito de chegar mais de 1 transação com o mesmo ID interno nosso vocês identifiquem como uma duplicidade.

Em ambiente de produção, OK, mas em sandbox tem como desabilitar essa verificação enviando algum parâmetro adicional? qual a sugestão para mitigar este problema?

E da isso data: {
code: 3500011,
error: 'invalid_data',
error_description: 'Não foi possível recuperar os dados enviados.'
}

Olá a todos!
Estou com um problema de obtenção do payment_token pelo backend. Só retorna:
{"code":3500011,"error":"invalid_data","error_description":"Não foi possível recuperar os dados enviados."}

Já revisei tudo de acordo com a documentação e não funciona. Podem me auxiliar? Obrigado!

E colocar o código do exemplo de back-end no front-end ? Pq o que você precisa é só aquilo mesmo de RSA em cima dos dados de cartão...

Boa tarde. Alguém pode me ajudar com um problema ? Estou no ambiente de homologação da API de pagamento com cartão. Não estou conseguindo obter o payment_token nem o card_mask. De acordo com a documentação, para obter esses dados antes é necessário gerar: SALT, chave RSA, objeto JSON contendo os dados do cartão junto com o SALT gerado, e por fim, criptografar esses dados e manda-los através de uma requisição POST para a rota "https://sandbox.gerencianet.com.br/v1/card". Até aqui tá tudo perfeito. O identificador da conta é enviado no Header da requisição com o atributo account-code. Só que a API retorna um erro informando que o identificador de conta fornecido é inválido. Mas isso não faz sentido, já que para obter o SALT e a chave RSA eu envio o mesmo identificador e funciona perfeitamente.

Bom dia @godiel tudo certo?
Em homologação não há tentativa de cobrança no cartão de fato.

Para simulação de cobranças de cartão em ambiente de Homologação, basta seguir os parâmetros:
Faz todas as validações que acontecem em uma criação de pagamento normal, com exceção das politicas de bloqueio:

Cartão com final 1 retornamos que os dados de cartão estão inválidos

Cartão com final 2 retornamos que por motivo de segurança não foi autorizado

Cartão com final 3 retornamos que a transação não foi autorizada

Demais finais a transação é aprovada

Bom dia @ranulfosouza ! Ocorreu a recusa da cobrança, pois você gerou uma cobrança informando os mesmos dados do perfil da conta emissora. Insere dados diferentes, e tente emitir novamente. Se a falha persistir, nos informe, por favor.

Boa tarde, Pessoal. Estou com um problema ao gerar o Payment Token no Back-end (uso PHP). Na documentação é dito que para gerar o Payment Token, antes, é necessário gerar o Salt e a chave pública RSA. As funções para gerarem esses dados estão funcionando perfeitamente. Mas, na parte final, quando mando esses dados para gerar o Payment Token, um erro é retornado dizendo que o identificador de conta fornecido é inválido. Mas isso não faz sentido já que eu consigo obter o salt e a chave RSA e ambos precisam do identificador da conta, e eu uso o mesmo para gerar o payment token mas não funciona de forma alguma. Alguém já passou por esse problema e sabe como resolve-lo ?

Bom dia Pessoal!

Estou tentando gerar o payment token via backend, estou com esse erro:
{'code': 3500011, 'error': 'invalid_data', 'error_description': 'Não foi possível recuperar os dados enviados'}

Fiz todo o processo, estou gerando o salt (incluindo ele no json dos dados), gero o RSA e faço a criptografia dos dados com essa chave publica.

Olá, bom dia. Estou recebendo o erro "Não foi possível recuperar os dados enviados." ao tentar cadastrar um cartão na rota "/card". Em homologação acabei de testar e tudo funciona lindo. Em produção, já revisei todas as credenciais e certificados, aparentemente está tudo certo.

Olá, alguem pode falar se tem algo rolando para nao pedir tantos dados na hora de fazer uma cobrança via cartao de credito?