Ycatu, orquestração de pagamentos

Ycatu orquestração de pagamentos unifica Stripe, Mercado Pago, PayPal e webhooks em um modelo PaymentOrder com auditoria append-only e credenciais por tenant.

Avatar de Heitor Ricardo
Heitor Ricardo
Ycatu, orquestração de pagamentos

Aceitar pagamentos parece simples até você precisar do segundo provedor. Aí vem o terceiro, e cada um traz seu próprio SDK, seu formato de webhook, seu esquema de assinatura e seu jeito de chamar a mesma coisa por nomes diferentes. Multiplique isso por Stripe, Mercado Pago, PayPal, Apple Pay e o que era um checkout limpo vira um emaranhado de integrações frágeis. O Ycatu, a plataforma de pagamentos da DW-Corp, nasce para resolver exatamente isso. Ainda estamos construindo — o lançamento está a poucas semanas —, mas já dá para contar o que você vai encontrar quando assinar.

Imagem de abertura que traduza visualmente a ideia central do Ycatu — muitos provedores de pagamento convergindo para uma única camada de orquestração canônica.
Imagem de abertura que traduza visualmente a ideia central do Ycatu — muitos provedores de pagamento convergindo para uma única camada de orquestração canônica.

O problema: muitos provedores, nenhum padrão

Cada provedor de pagamento é um mundo à parte. Um chama de charge, o outro de payment_intent, um terceiro de preference. Um manda webhook num formato, outro em outro, e cada um assina os eventos do seu jeito. Enquanto você tem um só provedor, isso é tolerável. No segundo, você começa a duplicar lógica. No terceiro, sua base de código já carrega três dialetos diferentes para descrever a mesma coisa: alguém pagou.

E tem os webhooks, a parte mais silenciosamente frágil de tudo. É por ali que o provedor avisa que um pagamento foi confirmado, estornado ou contestado. Se a verificação de assinatura estiver errada, você aceita eventos falsos. Se o endpoint cair, você perde a confirmação. Cada provedor que entra multiplica essa superfície de risco.

Uma integração, muitos provedores

A ideia central do Ycatu é simples: você integra uma vez, com a gente. Por baixo, orquestramos Stripe, Mercado Pago, AbacatePay, PayPal, Google Pay e Apple Pay atrás de um único modelo canônico, o PaymentOrder.

Na prática, isso quer dizer que seu sistema fala sempre a mesma língua, independentemente de para onde o dinheiro está indo. Um pagamento é um PaymentOrder — com o mesmo formato, os mesmos estados, o mesmo vocabulário — esteja ele passando pelo Stripe ou pelo Pix via AbacatePay. Trocar de provedor, ou rodar mais de um em paralelo, deixa de ser um projeto de refatoração e vira configuração.

Um proxy de webhooks que confere as assinaturas por você

É aqui que o Ycatu tira o maior peso das suas costas. Em vez de cada provedor bater direto na sua aplicação, os webhooks passam por um proxy que faz três coisas antes de qualquer evento chegar a você.

Primeiro, ele verifica a assinatura de cada provedor, com o esquema específico de cada um — então você não recebe evento forjado. Segundo, ele normaliza tudo num único fluxo canônico de eventos: um payment.confirmed é um payment.confirmed, venha de onde vier. Terceiro, ele arquiva o payload cru exatamente como chegou, para você nunca perder o original. Você deixa de manter seis integrações de webhook e passa a consumir um stream só, já verificado.

Credenciais por tenant, sob controle

Quem opera com múltiplos clientes ou múltiplas marcas conhece a dor de gerenciar credenciais espalhadas. No Ycatu, cada tenant administra suas próprias chaves de API e segredos de webhook por meio de um secrets manager, com um dashboard para visualizar e girar o que for preciso.

As credenciais ficam isoladas por tenant e guardadas onde devem ficar — num cofre de segredos, não em variáveis de ambiente soltas nem coladas num arquivo de configuração. Cada cliente enxerga e controla o que é dele, e nada mais.

Uma trilha de auditoria que não se apaga

Em pagamentos, a pergunta "o que exatamente aconteceu com essa transação?" não pode ter resposta aproximada. Por isso o Ycatu mantém uma trilha de auditoria append-only e imutável: cada transação gera registros que só podem ser acrescentados, nunca editados ou apagados.

O resultado é um histórico confiável para conciliação, disputa e conformidade — um relato do qual você pode depender quando precisar reconstruir a vida inteira de um pagamento, do primeiro clique ao estorno.

Nativo na nuvem, provisionado com Terraform

O Ycatu é cloud-native no Google Cloud, e cada peça foi escolhida para essa carga. Ele roda no seu próprio projeto GCP dedicado, provisionado via Terraform — infraestrutura como código, reproduzível e versionada, sem cliques manuais no console.

Os eventos trafegam pelo Pub/Sub, o que dá desacoplamento e absorve picos sem derrubar nada. E o sink de auditoria vai para BigQuery e GCS, onde os dados ficam consultáveis e arquivados de forma durável. É a diferença entre "funciona na demo" e "aguenta produção".

Em breve. O Ycatu ainda está em desenvolvimento e chega nas próximas semanas. Se hoje sua equipe gasta energia costurando gateways e caçando webhooks quebrados, é exatamente essa energia que a gente quer te devolver. Uma integração, um modelo canônico, um stream de eventos verificado — e você de volta ao que importa: o seu produto.

Gostou do artigo?

Compartilhe com seus amigos e ajude a espalhar conhecimento!