Three years ago, we started building Hyperswitch, an open-source payments platform.

When we launched, the pitch was simple: one platform, any processor, no lock-in. We had no idea what we'd signed up for.

70+ processors later (Stripe, Adyen, Razorpay, PayPal, Checkout.com, Worldpay, Mollie, plus a long tail across Europe and North America), five lessons:

1. "Declined" means something different to every processor Numeric codes. String codes. Both, contradicting each other. 200 OK with failure buried in the body. Normalising this took us nearly a year. Still the most thankless work we do.

2. Sandboxes lie Test environments accept edge cases production silently rejects: wrong currency combos, certain BIN ranges, specific 3DS flows. We harden every connector against real production traffic before calling it stable.

3. API inconsistency is intentional We used to assume different schemas were just different teams making different choices. They're not. Switching costs are a feature, not a bug. The abstraction problem exists because it's profitable.

4. Statelessness is non-negotiable The instinct is to cache credentials, transaction state, configs. Feels like optimisation. It's a liability. Stored PII compounds risk nonlinearly. We rebuilt the connector layer so nothing persists beyond a single request. Painful. Worth it.

5. Regional processors are a different game Stripe and Adyen have decent docs. The long tail doesn't. One processor sent API specs as a Word document. Another had no sandbox. You tested in production with real money. Western-only integrators severely underestimate this.

Still learning. If you're building payment infra, evaluating processors, or adding redundancy, happy to compare notes.

And we are Launching Hyperswitch Prism soon: https://hyperswitch.io/prism