Termos mais procurados:
São duas coisas distintas. A autorização do banco emissor não inclui análise anti-fraude, apenas que o cartão existe, o CVV2 bate e o cliente tem limite disponível. Com a transação autorizada pelo banco emissor, o (sub)adquirente faz análise e anti-fraude e decide continuar ou não com a transação.
Boa tarde, fiz a integração de um sistema com o Cartão de Credito via API da Efi e ao realizar um pagamento o banco está confirmando que está tudo ok, mas a Efi está recusando o pagamento, ai eu recebo um SMS e quando eu confirmo que estou realizando a operação eu recebo uma mensagem para refazer, ai acontece novamente o banco confirma que esta ok (recebo push da Nubank avisando) e o pagamento é recusado ai recebo outro SMS....: Mensagem: Falha no pagamento - No momento, a transação não foi autorizada. - Esta conta é nova, alguem poderia me ajudar??
Mas notar que não usamos na Efí a API de emissões, a que tem cartão e boleto... então essas deixo pra outros relatarem. E que com cartão não tem como não ter não ter surpresa desagradável, independente do (sub) adquirente. Cartão não presente é o arranjo de pagamento que nos dá mais enrosco de todos, então se seu mercado consumidor tolerar você não oferecer cartão, não ofereça. Ou no mínimo coloque preço maior no cartão.
Obrigado pelo relato Rubens, estou terminando meu Saas e andei por várias empresas mas aqui é a mais simples de trabalhar. Não quero ter nenhuma surpresa desagradável quando colocar meu Saas no mercado. Muito obrigado.
Para referência de volume, nos dias mais movimentados recebemos 5 mil transações Pix por dia. Típico de 3 mil transações por dia, dias mais parados como feriados 1 mil transações por dia. Pix já é nosso meio de pagamento com maior participação, conseguiu desbancar o boleto (que ainda é o 2o.) ao roubar muita transação de cartão (o que foi uma surpresa).
A Efí não tem dupla custódia (requerer dupla autorização para pagamentos e transferências saindo da conta), mas colocou a nosso pedido uma política de segurança na conta aonde só se pode fazer transferências para contas de nossa titularidade. Então endereçamos questão de segurança por aí... isso inclusive precisou ser customizado para que pudéssemos fazer devolução de Pix (que vai para outra titularidade) mas não desse para fazer Pix ou TED para outra titularidade, mesmo tendo senha/autenticador/token.
A gente consegue conciliar os pagamentos recebidos com os valores na conta usando o endpoint de extrato e o de saldo, e qualquer divergência já temos alerta no dia seguinte. É inclusive o que usamos para detectar que um MED (devolução do Pix, em parte comparável ao chargeback do cartão) não foi registrado como deveria (pois ele é sinalizado por e-mail e não pela API).
Bom, então vou comentar da nossa experiência com a API Pix. A gente tem tido disponibilidade quase total nesses anos de operação, só engasgando quando a AWS US-EAST-1 engasga... a API é a mais aderente que encontramos ao padrão do Banco Central, e quando um recurso importante não é adotado pelo Banco Central, eles implementaram como extensão. Por exemplo, para nós era muito importante que transferências por chave e dados bancários e QR-Code estático fossem rejeitadas... isso não tem no padrão, mas tem na Efí.
Basicamente seria a experiência de um Saas com a API de pagamentos cartão, pix ou boleto. Postei em cartões pra não ter postar em cada canal da api.
Nós temos um SaaS mas usamos a API Pix... como você postou em <#💳cartões> , só para confirmar sua dúvida seria sobre pagamento em cartão, né ?
