Você lança com um provedor de pagamento. A primeira compra funciona, o webhook libera acesso e a equipe volta a construir o produto.
Meses depois, aparece uma oportunidade em outro mercado. Falta um método local. A tarefa entra no planejamento como “adicionar mais uma integração”.
Ao abrir o código, você encontra o primeiro provedor no pedido, na assinatura, no cadastro do cliente e no suporte. Até o significado de “pagamento concluído” depende de um estado que só existe naquela API.
A integração cresceu junto com o negócio. Sem uma decisão explícita, virou parte da arquitetura.
O acoplamento nem sempre está no cliente HTTP
Trocar uma URL é fácil. Reescrever o significado de uma compra é outra conversa.
Considere um produto que usa o identificador do cliente no provedor como identificador principal em todas as tabelas. O segundo provedor também exige um cadastro. Agora o sistema precisa decidir qual dos dois representa o cliente.
Ou uma aplicação que libera acesso diretamente dentro do handler de um evento específico. O novo provedor envia outro evento, em outro momento, com outro formato. Copiar o handler pode duplicar uma decisão de negócio que deveria acontecer uma vez.
O problema não é que os provedores sejam diferentes. Eles têm contratos, capacidades e modelos próprios. O problema é obrigar o restante da aplicação a acompanhar todas essas diferenças.
O que precisa continuar pertencendo ao produto
Seu cliente continua sendo seu cliente quando o pagamento muda de caminho.
O mesmo vale para o pedido, a fatura e o direito que a compra concede. Esses objetos precisam de identidade própria, com referências às execuções externas que ajudam a realizá-los.
Uma compra pode ter várias tentativas. Cada tentativa tem um provedor e um resultado. O produto não deve precisar fingir que cada tentativa é uma compra nova para conseguir registrá-la.
Essa separação também ajuda o suporte: primeiro identificar a compra; depois investigar como o pagamento foi executado. Começar pelo dashboard de cada provedor inverte a ordem do problema.
Onde a Infi entra
A Infi coloca uma interface entre a aplicação e a infraestrutura de pagamento suportada. A aplicação integra com o modelo da Infi; o roteamento considera os provedores conectados e compatíveis com a cobrança. Infi Routing.
Isso não transforma todos os provedores em cópias uns dos outros. Um método pode existir em um e não em outro. Uma conta pode ter restrições. Um cartão salvo pode continuar vinculado ao provedor original.
A abstração útil preserva um contrato comum sem esconder limitações relevantes.
Stripe pode continuar fazendo parte da operação. Colocar a Infi à frente dele não exige tratar uma infraestrutura que funciona como algo a ser abandonado.
Comece por uma fronteira pequena
Para avaliar a mudança, escolha um fluxo real: uma compra avulsa, um link de pagamento ou uma nova forma de cobrança.
Mapeie a identidade da compra, o estado esperado, o evento que confirma o pagamento e o efeito que libera acesso. Em seguida, verifique o que muda se a execução usar outro provedor compatível.
Se a troca exige alterar catálogo, autenticação, histórico financeiro e permissões do produto, a fronteira ainda está espalhada.
Migração de cartões salvos, assinaturas existentes e processos específicos merece um plano próprio. Uma API unificada não transfere automaticamente contratos antigos.
O resultado que importa é o próximo pedido do negócio caber numa mudança de infraestrutura delimitada.
Adicionar um provedor continuará exigindo configuração e validação. Não deveria exigir ensinar novamente à sua aplicação o que é uma compra.