Accepting payments seems simple until you need a second provider. Then comes the third, and each one brings its own SDK, webhook format, signature scheme, and way of calling the same thing by a different name. Multiply that by Stripe, Mercado Pago, PayPal, Apple Pay, and the clean checkout you started with becomes a tangle of fragile integrations. Ycatu, DW-Corp’s payment platform, was created to solve exactly this problem. We’re still building it—the launch is just a few weeks away—but we can already tell you what you’ll find when you subscribe.
The problem: many providers, no standard
Every payment provider is a world of its own. One calls it a charge, another a payment_intent, and a third a preference. One sends webhooks in one format, another uses a different one, and each signs events in its own way. While you have only one provider, this is tolerable. With the second, you start duplicating logic. By the third, your codebase already carries three different dialects for describing the same thing: someone paid.
Then there are webhooks, the most quietly fragile part of the whole system. This is how a provider tells you that a payment was confirmed, refunded, or disputed. If signature verification is wrong, you accept forged events. If the endpoint goes down, you miss the confirmation. Every provider you add multiplies this risk surface.
One integration, many providers
Ycatu’s central idea is simple: you integrate once, with us. Under the hood, we orchestrate Stripe, Mercado Pago, AbacatePay, PayPal, Google Pay, and Apple Pay behind a single canonical model, the PaymentOrder.
In practice, this means your system always speaks the same language, regardless of where the money is going. A payment is a PaymentOrder—with the same format, the same states, and the same vocabulary—whether it goes through Stripe or Pix via AbacatePay. Switching providers, or running more than one in parallel, stops being a refactoring project and becomes configuration.
A webhook proxy that verifies signatures for you
This is where Ycatu takes the greatest burden off your shoulders. Instead of each provider sending requests directly to your application, webhooks pass through a proxy that performs three actions before any event reaches you.
First, it verifies the signature from each provider using that provider’s specific scheme, so you never receive forged events. Second, it normalizes everything into a single canonical event stream: a payment.confirmed is a payment.confirmed, no matter where it came from. Third, it archives the raw payload exactly as received, so you never lose the original. You stop maintaining six webhook integrations and start consuming a single, already-verified stream.
Tenant credentials, under control
Anyone operating with multiple customers or brands knows the pain of managing scattered credentials. In Ycatu, each tenant manages its own API keys and webhook secrets through a secrets manager, with a dashboard for viewing and rotating whatever is needed.
Credentials are isolated by tenant and stored where they belong—in a secrets vault, not in loose environment variables or pasted into a configuration file. Each customer can see and control what belongs to them, and nothing else.
An audit trail that cannot be erased
In payments, the question of exactly what happened to a transaction cannot have an approximate answer. That’s why Ycatu maintains an append-only, immutable audit trail: each transaction generates records that can only be added, never edited or deleted.
The result is a reliable history for reconciliation, disputes, and compliance—a record you can depend on when you need to reconstruct the entire life of a payment, from the first click to the refund.
Cloud-native, provisioned with Terraform
Ycatu is cloud-native on Google Cloud, and every component was chosen for this workload. It runs in your own dedicated GCP project, provisioned through Terraform—reproducible, versioned infrastructure as code, with no manual clicks in the console.
Events travel through Pub/Sub, providing decoupling and absorbing spikes without bringing anything down. The audit sink goes to BigQuery and GCS, where data remains queryable and durably archived. That’s the difference between something that works in a demo and something that can handle production.
Coming soon. Ycatu is still under development and will arrive in the next few weeks. If your team is currently spending energy stitching gateways together and tracking down broken webhooks, that is exactly the energy we want to give back to you. One integration, one canonical model, one verified event stream—and you can get back to what matters: your product.
