PSPs de pagamento transfronteiriço evoluem na era multi-trilha

Artigo escrito por A Wang, Web3 Little Lawyer

Os pagamentos digitais já entraram no mainstream, mas o liquidação ainda não.

Essa é a avaliação de Dan Mottice, ex-executivo da Visa e fundador da Beam. As transações da Visa são autorizadas em qualquer estabelecimento comercial do mundo, mas o liquidação por trás delas ainda ocorre pelo SWIFT — agregando transações em lotes, transferindo fundos por remessas internacionais, passando por regulamentações locais, feriados e múltiplos bancos intermediários, enquanto o comerciante aguarda o recebimento. Não é um problema da Visa, mas sim um déficit estrutural de toda a indústria. E os PSPs são o ponto onde essa dívida se concentra mais intensamente.

Este artigo foca nos prestadores de serviços de pagamento (PSP), que evoluíram de simples ferramentas de recebimento para se tornarem a camada de infraestrutura central que gerencia o fluxo de fundos, liquidação e contabilidade. Eles foram originalmente projetados para uma era mais simples — sistema de uma única via, fluxo de transações linear e infraestrutura altamente integrada.

Em um ambiente de pagamento moderno, um "pagamento" não é mais uma única transação, mas sim uma série de mudanças de estado que envolvem múltiplos participantes e rotas de pagamento. Hoje, um pagamento pode envolver: aplicativos de consumo, PSPs, provedores de fraudes/verificação de identidade, bancos custodiantes, uma ou mais rotas de pagamento e sistemas contábeis internos da empresa.

As empresas devem suportar simultaneamente cartões de débito, ACH, transferências bancárias, RTP, FedNow e, cada vez mais, liquidações baseadas em stablecoins. Cada canal possui diferentes prazos de liquidação, modos de falha, formatos de dados e requisitos operacionais.

Este artigo compila o guia da Modern Treasury, que explorará como os PSPs evoluíram, como sua arquitetura subjacente precisa se adaptar aos sistemas de pagamento modernos e quais estratégias as equipes que desenvolvem produtos de pagamento devem adotar ao escolher o próximo PSP.

Julgamento principal

01｜O pagamento digital entrou no mainstream, mas o liquidação ainda não. A Visa permite que você autorize pagamentos em qualquer comerciante global, mas a liquidação por trás ainda roda sobre o SWIFT. A interface foi resolvida, a camada subjacente não.

02｜O PSP realiza o pagamento, mas não explica o fluxo de fundos. O Stripe te diz o que aconteceu na sua parte, mas não pode te dizer qual é o estado real desse dinheiro agora. A camada de execução e a camada de registro são duas coisas diferentes.

03｜Cada via de pagamento é um sistema operacional independente, não uma variação do mesmo modelo. ACH pode ser revertido, RTP não pode; redes de cartões podem ser contestadas, stablecoins têm confirmação final na cadeia. A camada de abstração do PSP oculta essas diferenças, mas apenas até o surgimento de um problema.

04｜O pagamento em tempo real eliminou os buffers; o controle deve ser antecipado. Os lógicas de risco, aprovação e conciliação dos PSPs tradicionais assumem que "há tempo para corrigir erros". RTP e FedNow tornam essa suposição inválida. As decisões devem ser tomadas antes da movimentação dos fundos, não depois.

05 | As stablecoins são uma via de liquidação, não um novo método de pagamento. Elas não resolvem problemas da interface de pagamento, mas sim o atraso entre a "finalização da contabilidade" e o "crédito real na conta". O caminho mais prático de implementação é a estrutura de sanduíche: entrada em moeda fiduciária, circulação na cadeia, saída em moeda fiduciária — os usuários nas duas extremidades não precisam entender stablecoins.

06｜ Os fundos em trânsito podem gerar rendimentos, algo quase inexistente no sistema tradicional. Em pagamentos transfronteiriços, os fundos permanecem retidos por 24 a 72 horas antes da liquidação, sem gerar rendimentos e ocupando capital de giro. As stablecoins pela primeira vez permitem que "fundos em movimento" também gerem valor.

07｜ O maior fracasso da operação de pagamentos é não conseguir responder a uma pergunta simples: para onde foi esse dinheiro? Conciliação, tratamento de anomalias e gestão de liquidez — esses problemas não surgem no momento do pagamento, mas sim após. Sem uma camada de coordenação unificada, cada provedor só pode contar sua própria parte da história.

08｜ O verdadeiro risco estratégico não é se você usa ou não stablecoins. É o fato de que seus concorrentes reestruturaram seus custos de liquidação e eficiência de capital com stablecoins, enquanto você ainda espera por um momento perfeito para entrar.

I. A evolução histórica do PSP

Nos últimos vinte anos, o papel do PSP sofreu uma mudança fundamental.

No início do comércio eletrônico, as PSPs operavam principalmente como gateways de pagamento. Suas responsabilidades eram simples e claras: conectar os comerciantes às redes de cartões e aos bancos adquirentes, permitindo a autorização e liquidação das transações.

Esses sistemas PSP foram projetados para um mundo muito específico. Os pagamentos são baseados em cartões, fluem por uma única conta de comerciante e seguem um ciclo de vida linear, da autorização ao liquidação. Os PSPs foram otimizados para processar transações de forma eficiente dentro desse modelo.

Na década de 2010, marketplace, plataformas SaaS e produtos de fintech começaram a integrar diretamente pagamentos em seus produtos. As plataformas precisavam concluir o onboarding de usuários, dividir pagamentos entre múltiplas partes e gerenciar pagamentos. Os PSPs expandiram-se, introduzindo onboarding de comerciantes, infraestrutura de pagamentos e ferramentas de prevenção de fraude.

No entanto, apesar da capacidade contínua de expansão do PSP, sua arquitetura subjacente ainda se baseia em um modelo projetado para fluxos de pagamento lineares — otimizados principalmente para processamento de transações, e não para coordenação de movimentações de fundos complexas e em múltiplos passos entre provedores e trilhas diferentes.

No início da década de 2020, as empresas passaram a operar em múltiplas trilhas, regiões e cenários. Os PSPs tradicionais continuaram a agrupar diversos componentes, permitindo que as empresas interagissem com uma única plataforma. No entanto, à medida que os processos de pagamento se tornaram mais complexos, um único processo de pagamento pode abranger várias etapas: verificação de identidade, análise de risco, decisão de financiamento, execução da trilha e rastreamento interno.

Essa transição transformou o papel do PSP de "conector" para "coordenador" (from connectors to coordinators), mas sua arquitetura não evoluiu na mesma velocidade.

The result is: PSPs still handle fund transfers, but operate within a more complex, full transaction payment lifecycle.

II. Pilha de tecnologia de pagamento PSP moderna

Para entender os limites do PSP, é necessário primeiro compreender o ambiente de pagamento mais amplo em que ele está inserido.

2.1 Pilha de tecnologia PSP

O ambiente de pagamentos moderno não é uma única plataforma ou prestadora de serviços, mas sim um conjunto de componentes de infraestrutura em camadas que juntos suportam a movimentação, liquidação e contabilização de fundos.

Camada de aplicação: plataformas de comércio eletrônico que iniciam pagamentos, Marketplace, aplicativos de tecnologia financeira e produtos SaaS com pagamento integrado.

Camada PSP: responsável por executar instruções de pagamento, como encaminhar transações para redes de cartões, iniciar transferências bancárias e conectar-se a canais de pagamento. Na maioria dos casos, essa complexidade subjacente é abstraída atrás da interface da PSP, permitindo que o usuário interaja com um único sistema, em vez de lidar diretamente com vários provedores envolvidos.

Camada de conformidade: Os processos de pagamento modernos também dependem de provedores de verificação de identidade, ferramentas de detecção de fraude e infraestrutura de conformidade, que determinam se o pagamento deve ser autorizado a prosseguir.

Camada bancária: os bancos custodiantes detêm fundos, fornecem contas regulamentadas e oferecem acesso a redes de pagamento como ACH, transferência bancária, RTP e FedNow.

Camada de conciliação interna: sistema utilizado por empresas para rastrear saldos, indicar o status das transações e manter registros consistentes das atividades financeiras.

Cada um dos níveis acima desempenha um papel na movimentação de fundos, mas nenhum deles fornece uma imagem completa do que realmente acontece após o início do pagamento. É por isso que o nível de conciliação interna torna-se indispensável.

2.2 Síncrono e assíncrono

Os PSPs tradicionais têm um defeito de design fundamental: eles apenas se preocupam em enviar o dinheiro, mas não monitoram o que acontece após o envio.

O problema está em que "após o envio" é exatamente a parte mais complexa do pagamento.

A lógica da API do PSP é síncrona — você envia um comando e recebe um resultado. Mas o fluxo real de fundos é assíncrono: os assentamentos são concluídos posteriormente, falhas surgem com atraso, e reembolsos e estornos podem ser devolvidos a qualquer momento. Esse descompasso cria um buraco negro de informações contínuo.

A manifestação concreta do buraco negro é a fragmentação do estado:

Nenhum nó pode te dizer qual é o estado real desse dinheiro neste momento.

Por exemplo, ao retirar fundos como vendedor na plataforma de mercado, todo o processo é uma cadeia longa: verificação de elegibilidade → conformidade e gestão de risco → confirmação dos fundos → emissão de instrução → execução do canal → retorno de confirmação → liquidação pós-operacional → atualização do livro-razão. O PSP cobre apenas alguns dos estágios intermediários; as decisões anteriores e a reconciliação posterior não estão dentro de suas responsabilidades. Caso esse pagamento falhe ou seja devolvido, nenhum sistema consegue fornecer uma resposta completa.

Essa é a razão de ser da camada de conciliação interna: ela não substitui o PSP na execução de pagamentos, mas estabelece uma camada unificada de observação acima de toda a cadeia — traduzindo continuamente eventos assíncronos provenientes de diferentes provedores, em diferentes momentos e formatos, em um único estado confiável dentro da empresa. Independentemente de quantos intermediários o dinheiro atravessar, sempre haverá um local capaz de responder à pergunta mais básica: onde está esse dinheiro, agora?

III. Limitações de pagamento dos PSPs tradicionais

A camada de abstração dos PSPs tradicionais é construída em torno do pagamento com cartão bancário—autorização, captura, liquidação, com um ciclo de vida previsível. Embora existam exceções (como disputas e estornos), a estrutura geral é previsível e bem compreendida. Esse modelo moldou a forma como os PSPs foram projetados.

Com a chegada de novas formas de pagamento, o PSP expandiu seu suporte para mais canais, mas esses canais se comportam de forma diferente dos cartões de banco e não atendem às mesmas suposições:

• Transferência ACH: Foi introduzido um atraso, bem como a possibilidade de estorno ainda ocorrer vários dias após o início do pagamento.
• Wire transfer: Faster settlement, but typically requires manual processes and higher costs.
• Redes de pagamento em tempo real, como RTP e FedNow: permitem a movimentação imediata de fundos, mas as transações geralmente não são reversíveis após a conclusão.
• Transferências de stablecoins: operam sobre infraestrutura completamente diferente, com mecanismos de garantia e considerações operacionais distintos.

Por exemplo, com um pagamento de uma empresa americana a um fornecedor filipino:

• Via ACH, liquidação em T+2, mas os bancos das Filipinas não recebem ACH diretamente; é necessário um intermediário na rede local, portanto, o crédito real pode ocorrer em T+4, e a qualquer momento durante esse período o pagamento pode ser rejeitado por inconsistência nas informações da conta.
• Use transferência bancária para algo mais rápido, mas envie antes do horário de encerramento das transferências às 15:00; em feriados, o prazo é adiado. A taxa SWIFT varia de US$ 25 a US$ 45, e o banco receptor pode cobrar uma taxa adicional de banco intermediário, resultando em um valor recebido diferente do valor enviado.
• Use o sanduíche de stablecoin: o USDC é enviado da conta nos EUA, confirmado em segundos na blockchain; após recebimento pelo parceiro nas Filipinas, é convertido em pesos e depositado na conta local, tudo em menos de uma hora, com custo inferior a 1% do valor transferido.

Três caminhos, o mesmo dinheiro, tempos de liquidação diferem em 96 horas, custos variam em dezenas de dólares e a rastreabilidade é completamente diferente. Isso não é uma diferença na experiência do produto, mas uma diferença entre três sistemas operacionais distintos. A camada de abstração do PSP não consegue ocultar essas diferenças; apenas as transfere para os desenvolvedores e equipes de operações lidarem.

Estes não são variantes do mesmo modelo de pagamento, mas sim modelos operacionais fundamentalmente diferentes.

A abordagem dos PSPs tradicionais é expor APIs e definições de estado diferentes para cada trilha — sem realmente unificar as diferenças, apenas empurrando essas diferenças para cima, para os desenvolvedores. As equipes de engenharia começaram a escrever lógicas especiais para cada trilha, as equipes de operações começaram a lidar manualmente com diferentes modos de falha, e as equipes financeiras começaram a reconciliar transações do mesmo tipo que seguiram caminhos completamente diferentes.

Essa é a fuga de abstração: a complexidade da trilha, que deveria estar oculta, começa a vazar para a camada de aplicação.

À medida que mais trilhas são adicionadas, o ambiente de pagamento se torna uma série de integrações soltas, em vez de uma camada abstrata unificada. Nas trilhas mais lentas, a latência fornece uma janela de tempo para detectar problemas. Na trilha em tempo real, essa janela desaparece — os pagamentos são liquidados em segundos, os erros não podem ser facilmente revertidos e as decisões devem ser tomadas antes da movimentação dos fundos, e não depois.

Quatro: O pagamento em tempo real obriga os PSPs a anteciparem o controle

A transição para redes de pagamento em tempo real não apenas acelerou a velocidade do fluxo de fundos — ela alterou fundamentalmente os requisitos de design da infraestrutura de pagamento.

Na era do ACH e das transferências bancárias, o tempo é um buffer.

ACH pode levar vários dias para liquidação, transações com cartão de banco podem ser contestadas após autorização, e transferências bancárias frequentemente envolvem etapas de revisão manual. Esses atrasos, embora causem perda de eficiência, oferecem oportunidades para detectar erros, intervir em atividades suspeitas e realizar conciliações antes da liquidação final.

O modelo tradicional de PSP foi construído em torno desse buffer.

No entanto, redes de pagamento em tempo real como RTP e FedNow quebraram completamente esse pressuposto. Os fundos fluem diretamente entre contas em segundos, e os pagamentos, uma vez concluídos, geralmente são irrevogáveis.

• A detecção de fraude deve ser concluída mais cedo
• A triagem de conformidade deve ser realizada em tempo real
• As decisões de financiamento devem ser concluídas com precisão no momento da liberação do pagamento.
• A oportunidade de corrigir erros após o fato não existe mais

Plataformas que oferecem pagamentos imediatos não podem depender de fluxos de trabalho projetados para liquidação diferida. Sistemas internos de empresas que gerenciam fundos de pagamento em várias contas não conseguem determinar a liquidez instantaneamente durante a execução. A equipe de atendimento ao cliente não pode garantir a revogabilidade quando a infraestrutura subjacente não permite isso.

O resultado é a transferência de responsabilidade: os PSPs devem evoluir para suportar os sistemas internos que decidem quando o pagamento deve ser executado. Em outras palavras, o controle deve ser deslocado para frente.

A infraestrutura de pagamento deve ser projetada para que aprovação, lógica de fundos, verificação de risco e validação de estado sejam concluídas antes do fluxo de fundos, e não depois. Isso exige uma visão mais coordenada dos saldos, status de transações e condições entre provedores de serviço, além do que as arquiteturas tradicionais de PSP podem oferecer.

A trilha em tempo real não é um estado final, apenas um ponto de virada. Após a entrada das stablecoins, o problema será elevado a um novo nível.

V. Stablecoins: uma nova trilha, não um novo método de pagamento

A maior mal-entendido sobre as stablecoins é considerá-las um novo produto de pagamento. Elas não são. São uma nova via de liquidação, resolvendo o atraso entre o momento em que a contabilização é concluída e o momento em que os fundos são efetivamente recebidos.

Ao contrário de cartões, ACH e transferências bancárias, as transações em stablecoins operam na rede blockchain:

• Settlement is ongoing, not batched
• Confirmação final quase instantânea (depende da rede)
• Funcionando 24/7, sem restrições de horário de encerramento bancário ou feriados
• Não depende de sistemas de pagamento nacionais específicos
• Os primitivos para rastrear saldo, propriedade e histórico de transações são completamente diferentes

A arquitetura tradicional de PSP foi construída em torno da integração com bancos e redes de pagamento, enquanto as stablecoins introduzem redes que não dependem desses intermediários. A origem, o liquidação e a contabilidade ocorrem fora do design original. Uma empresa pode precisar coordenar simultaneamente canais bancários, redes em tempo real e liquidação na cadeia, cada tipo assumindo diferentes características em relação à finalidade, temporização e controle — diferenças que não podem ser unificadas por uma única API, tornando cada vez mais difícil manter o PSP como uma camada de abstração única.

Assim como sistemas de pagamento em tempo real desafiam as suposições sobre sequência e revogabilidade, as stablecoins desafiam as suposições sobre onde e como os pagamentos ocorrem.

Neste processo, elas introduziram uma nova camada de complexidade.

O sanduíche de stablecoins é o caminho mais prático atualmente: fiat para dentro → circulação na cadeia → fiat para fora.

Clientes e fornecedores em ambos os lados da transação não precisam entender stablecoins; as stablecoins são apenas um canal intermediário, especificamente projetado para resolver a parte lenta, cara e instável do processo de liquidação transfronteiriça tradicional. As aplicações mais valiosas estão concentradas nos "canais difíceis", ou seja, cenários transfronteiriços onde os métodos tradicionais são lentos, caros ou simplesmente inacessíveis.

As empresas não devem e não devem fazer All-in em stablecoins; o caminho real é escolher um ou dois casos de uso específicos para substituição local, construir conscientização e depois expandir.

As stablecoins também trazem uma dimensão adicional: rendimento sobre fundos em trânsito, algo quase inexistente no sistema tradicional. Nos processos de pagamento tradicionais, os fundos permanecem bloqueados entre 24 e 72 horas entre o envio e o recebimento, gerando nenhum rendimento e ocupando capital de giro. As stablecoins na blockchain podem gerar rendimento enquanto estão em movimento — não se trata de uma pequena otimização dos custos de pagamento, mas de uma reestruturação completa da lógica de eficiência de capital.

Seis: O ecossistema atual: dez camadas de divisão de tarefas e a camada ausente

À medida que a infraestrutura de pagamento se expande para mais trilhos, mais provedores e mais tipos de infraestrutura, a definição do papel do PSP torna-se cada vez mais difícil.

As responsabilidades de movimentação de fundos, anteriormente agrupadas em um único PSP, agora se tornaram uma série de responsabilidades distribuídas em vários níveis da pilha tecnológica.

O papel do PSP já não é apenas mover fundos, mas explicar o fluxo de fundos.

Essa transição reflete mudanças mais profundas: a execução em si já não é mais suficiente. Os PSPs agora devem suportar os sistemas internos das empresas, permitindo que eles representem, contabilizem e reconciliem como os fundos fluem entre diferentes ambientes.

① Plataforma de camada de produto: integrar pagamentos ao software

Plataformas de software verticais como Shopify, Square, Toast, Mindbody, ServiceTitan e Housecall Pro incorporam pagamentos diretamente em seus produtos.

Nesses cenários, o pagamento é integrado à experiência do aplicativo, em vez de ser tratado como um sistema de pagamento independente. Essas plataformas geralmente dependem de PSPs subjacentes, parceiros bancários e provedores de infraestrutura, adicionando outra camada de abstração entre o aplicativo e o fluxo de fundos.

② Camada de execução: transferência de fundos entre órbitas

O núcleo da pilha tecnológica é o provedor de serviços responsável por executar pagamentos. Inclui PSPs tradicionais como Stripe, Adyen, Checkout.com, Worldpay, PayPal, Nuvei e dLocal, cujo papel é conectar empresas às redes de pagamento e facilitar a movimentação de fundos.

They remain key components of the payment technology stack, but operate primarily at the execution layer—initiating payments, reporting status, exposing APIs—but do not themselves provide a complete model of how funds flow across service providers and internal systems.

Você pergunta ao Stripe "Onde exatamente está esse dinheiro agora?", e ele só pode informar o que aconteceu em sua própria etapa. O Stripe é apenas um dos nós; essa transação pode incluir ainda PSPs, bancos, rotas e quatro ou cinco etapas internas de contabilidade, mas o que ele vê é sempre parcial, não global.

③ Camada de orquestração e roteamento: conexão com provedores de execução

Com a adoção de múltiplos PSPs e métodos de pagamento pelas empresas, surgiram plataformas de orquestração responsáveis por gerenciar o roteamento entre provedores. Empresas como Primer, Gr4vy, Spreedly, Paydock e CellPoint Digital permitem que as empresas direcionem transações com base em região, custo ou desempenho. Esses sistemas aumentam a flexibilidade na camada de execução, mas não oferecem um modelo unificado para o comportamento após o início do pagamento.

④ Camada de risco e conformidade: decide se os fundos devem ser movidos

Um conjunto de provedores independentes é responsável por determinar se o pagamento deve ser autorizado a prosseguir. Sistemas de verificação de identidade, detecção de fraude e conformidade de fornecedores como Persona, Sardine, Alloy, Unit21, Sift e Sumsub avaliam usuários e transações antes da execução. Em ambiente em tempo real, essas decisões devem ser concluídas antes da movimentação dos fundos, por isso a lógica de controle crítica foi movida para fora do PSP.

⑤ Camada de infraestrutura bancária: detém fundos e suporta o acesso

Bancos custodiários como Cross River Bank, Lead Bank, Column e Sutton Bank fornecem contas regulamentadas e acesso às redes de pagamento. Eles detêm os fundos dos clientes, gerenciam a liquidez e atuam como portais de acesso a sistemas como ACH, transferências eletrônicas, RTP e FedNow. Essa camada é essencial para o acesso ao sistema financeiro, mas opera independentemente da lógica da aplicação e das APIs PSP.

⑥ Camada de emissão de cartões: expansão das funcionalidades de pagamento

Plataformas de emissão de cartões como Marqeta, Lithic e Rain permitem que empresas emitem cartões de débito e crédito como parte de seus produtos, suportando cenários de uso como gerenciamento de despesas, cartões corporativos e consumo em mercados. As plataformas de emissão conectam bancos e redes de cartões, mas operam como uma camada independente na pilha tecnológica, introduzindo fluxos de trabalho, mecanismos de controle e estados adicionais que precisam ser coordenados com as outras partes da pilha de pagamentos.

⑦ Camada de pagamento: rede de execução subjacente

As vias de pagamento são redes que movem fundos entre instituições financeiras. Vias tradicionais incluem ACH, transferências eletrônicas e redes de cartões, enquanto novas redes, como RTP e FedNow, permitem liquidação em tempo real. Cada via possui suposições distintas em termos de cronologia, finalidade e reversibilidade, criando inconsistências que os PSPs devem expor ou contornar (e não totalmente abstrair).

⑧ Camada de rede de stablecoins: expansão além da infraestrutura bancária

Redes de stablecoins como Ethereum, Solana, Polygon e Base introduziram uma nova forma de infraestrutura de pagamento que opera fora do sistema bancário tradicional. Essas redes permitem a transferência de dólares digitais em uma infraestrutura global, utilizando diferentes modelos de liquidação e mecanismos de garantia. Elas expandem o alcance do sistema de pagamentos além das vias baseadas em bancos, adicionando uma camada adicional de complexidade que precisa ser integrada aos fluxos de trabalho existentes.

⑨ Camada de Banco como Serviço: Conectando aplicativos a bancos

Plataformas de Banking as a Service (BaaS), como Unit, Galileo e Treasury Prime, fornecem a infraestrutura para conectar aplicações fintech a bancos regulamentados. Elas permitem que empresas ofereçam funcionalidades de contas, cartões e pagamentos sem precisar se tornar bancos. Essa camada simplifica o acesso à infraestrutura bancária, mas adiciona outro intermediário entre a aplicação, o PSP e o fluxo de fundos subjacente.

⑩ A camada ausente: um PSP unificado que cobre todo o ciclo de vida dos fluxos de fundos

Ao analisar as nove camadas acima, a regra é consistente: cada provedor é responsável por uma função específica, e nenhum deles consegue fornecer uma visão completa do fluxo de fundos — incluindo sua compreensão, controle e conciliação.

A execução é tratada por um provedor, as decisões de risco são geridas por outro, e os fundos são mantidos em banco; o processo de pagamento pode se estender por redes de cartões, trilhas em tempo real e sistemas on-chain. Cada sistema expõe dados, cronogramas e definições de estado diferentes.

Em um ambiente fragmentado, esse problema não se manifesta na fase de início — ele surge posteriormente: quando o sistema apresenta divergências, os fundos são atrasados ou devolvidos, e a equipe precisa de respostas. É aí que o sistema de pagamento começa a falhar.

Sete: Onde a operação de pagamento falhou

Às 14:55 de sexta-feira, a equipe financeira enviou um transferência bancária de $50.000 para um fornecedor. Às 15:00, o horário limite de wire do banco. O sistema exibe "enviado", mas o e-mail de confirmação não chegou.

Às 16:00, o fornecedor enviou uma mensagem perguntando sobre o status do pagamento. A equipe financeira verificou o painel do PSP, que exibia "Em processamento". Ao verificar a conta bancária, exibia "Aguardando liquidação". Dois sistemas, o mesmo pagamento, dois status diferentes — nenhum deles informa em qual nó o dinheiro se encontra atualmente.

Às 17h de sexta-feira, o atendimento ao cliente do banco encerra. Os fornecedores estão aguardando o pagamento para organizar o transporte de fim de semana. A equipe financeira não sabe o que dizer aos fornecedores nem se o dinheiro será creditado automaticamente na segunda-feira ou se já foi devolvido e precisa ser reenviado.

Este não é um cenário extremo, mas sim uma situação que a equipe de operações de pagamento enfrenta semanalmente. Ela não aparece no manual do produto do PSP, mas está presente nos registros de trabalho de toda equipe de pagamento transfronteiriço.

Os problemas mais difíceis nos pagamentos geralmente não ocorrem na fase de emissão, mas sim após o fato — quando a equipe precisa explicar exatamente o que aconteceu.

O mapa de mercado do capítulo anterior revelou a amplitude do ecossistema de pagamentos. Um pagamento aparentemente único muitas vezes passa por vários provedores na pilha tecnológica antes que o liquidação ocorra. Cada parte pode ter uma representação diferente do mesmo movimento de fundos, com sequências temporais distintas, estados diferentes e documentos que chegam em cronogramas variados; anomalias são relatadas por canais diferentes.

É exatamente aí que as operações de pagamento se tornam difíceis.

Reconciliação: várias versões do mesmo evento

A equipe financeira precisa fazer a conciliação entre o livro interno, os extratos bancários, os relatórios de liquidação e os dados dos processadores. Se um prestador de serviço indicar que o pagamento foi concluído, enquanto outro indica que ainda está em processamento, a empresa precisa de um modelo para resolver essas discrepâncias. Se um estorno chegar após o saldo interno já ter sido atualizado, o livro deve ser devidamente revertido ou ajustado.

Tratamento de exceções: falhas sem atribuição clara

Uma retirada pode falhar devido a uma conta de destino inválida, uso de uma conta de fundos incorreta, suspensão da transação por revisão de conformidade ou perda do prazo de operação. Esses falhas não são iguais e não ocorrem ao mesmo tempo. No entanto, os usuários ainda esperam respostas consistentes, e a equipe interna ainda precisa lidar com o processo.

Liquidez e fundos: o dinheiro está no lugar errado

Empresas que operam em múltiplos provedores e contas devem garantir que os fundos corretos estejam nas contas corretas no momento correto. Mesmo que o saldo total seja suficiente, se os fundos permanecerem em contas erradas, a execução do pagamento ainda pode falhar — criando uma lacuna entre a lógica do produto e a realidade operacional.

Auditabilidade e controle: Restaurar o que aconteceu

As operações de aprovação, suspensão, liberação e conciliação ocorrem entre equipes e sistemas; as empresas precisam de registros confiáveis de quem fez o quê, quando e por quê. Isso não é apenas um requisito de conformidade, mas também a base para rastrear o histórico de transações em caso de problemas.

Essas questões são tanto operacionais quanto de arquitetura.

O maior fracasso na operação de pagamentos ocorre frequentemente quando a equipe não consegue responder a uma pergunta simples: para onde foi esse dinheiro?

O que falta não é outro prestador de serviços que execute pagamentos, roteie transações ou detenha fundos dentro dos modelos existentes, mas sim um PSP evoluído capaz de coordenar todas essas funções, rastrear estados entre prestadores de serviços, gerenciar fluxos de fundos e manter registros financeiros confiáveis ao longo do tempo.

Oito: A próxima evolução do PSP

O desafio não está em acessar a infraestrutura de pagamento, mas sim em manter uma compreensão consistente e confiável sobre como os fundos fluem dentro dela.

A divisão de funções no ecossistema atual: PSPs realizam pagamentos, bancos detêm os fundos, sistemas de conformidade avaliam riscos e ferramentas de orquestração roteiam transações. No entanto, nenhum único provedor é responsável por fornecer uma visão completa e consistente do fluxo de fundos ao longo de todo o ciclo de vida do pagamento.

A próxima evolução do PSP é fornecer visibilidade consistente em toda a pilha tecnológica — permitir que cada pagamento, desde o início até o encerramento final, seja compreendido, contabilizado e confiável.

Este nível deve ser capaz de:

• Execute pagamentos entre bancos, redes tradicionais e redes de stablecoins
• Manter um sistema de registro consistente por meio do livro interno
• Fluxo de trabalho para aprovação de gestão, fundos e tratamento de anomalias
• Reconciliar atividades externas com o estado financeiro interno
• À medida que escala, integra conformidade, infraestrutura de contas e conexões para crescimento contínuo.

Conclusão: Por onde começar

A infraestrutura de pagamentos moderna não é mais definida por um único processador ou uma única via. É um ambiente composto por múltiplos prestadores de serviços, cada um responsável por diferentes etapas do fluxo de fundos, aprovação, liquidação e contabilidade.

Ao longo deste guia, vimos a evolução desse ambiente:

Os provedores de pagamento foram além do processamento de transações, com cada vez mais trilhas de pagamento, sistemas em tempo real eliminando a rede de segurança de liquidação diferida e novas formas de infraestrutura, como stablecoins, ampliando ainda mais todo o sistema.

Para equipes que constroem produtos financeiros ou integram pagamentos em software, o caminho de entrada é mais importante do que discussões estratégicas.

Não comece com a questão de “se deve adotar completamente stablecoins”; em vez disso, identifique uma dor específica: uma rota transfronteiriça com liquidação muito lenta, um processo de pagamento a fornecedores com muitas etapas manuais, ou fundos ociosos que não geram rendimento durante o trânsito. Escolha um caso de uso, abra uma conta e realize um pagamento real. Inicie com um teste interno, começando pelo cenário de gestão de tesouraria (treasury), e não pela modificação direta dos processos do cliente. Isso permite controlar o risco e ao mesmo tempo construir conscientização.

Do ponto de vista regulatório, regras como KYC, AML e verificação de sanções ainda se aplicam integralmente; as stablecoins representam apenas uma mudança na infraestrutura subjacente. O quadro regulatório tornou-se muito mais claro desde a Lei GENIUS, e não deve servir como justificativa para impedir o teste piloto.

O verdadeiro risco estratégico não é se você usa ou não stablecoins, mas sim se seus concorrentes reestruturaram seus custos de liquidação e eficiência de capital com stablecoins, enquanto você ainda espera pelo momento perfeito para entrar.

Sem uma camada de coordenação unificada, a complexidade aumenta com o crescimento da escala. Com ela, as empresas podem operar fluxos de caixa com clareza, controle e confiança.

Parte do conteúdo proveniente de: Modern Treasury — Um Guia Prático para PSPs em 2026