PSP integration looks straightforward in a sandbox. You connect to an API, payments flow, webhooks fire, and your test transactions reconcile cleanly. In production, with real money, real reconciliation requirements across multiple currencies, real chargebacks, and real regulators watching your reporting, it's an entirely different challenge.
At a previous role, I owned the finance platform roadmap that integrated Adyen, PayPal, and Klarna: three PSPs with different API designs, different settlement cycles, different dispute processes, and different data models for reporting. Here's what I learned.
Lesson 1: Reconciliation Is the Product, Not an Afterthought
The payment collection part of PSP integration gets all the attention. The reconciliation part is where the real engineering and product work lives. Every PSP has a settlement report that arrives on a different cadence. Adyen settles daily. PayPal runs in batches. With Klarna's Buy Now Pay Later model, the timing of when revenue is recognised versus when cash arrives can span weeks.
Your finance system needs to reconcile every one of these settlement reports against your internal transaction records, automatically, before finance closes the books. If this process is manual, which it is at most companies that haven't built a proper reconciliation layer, it costs significant time and introduces errors. Build the reconciliation engine first, not last.
Lesson 2: Chargeback Workflows Are a Product Feature
Every PSP has chargebacks. The question is whether your system handles them systematically or manually. A chargeback that isn't processed correctly creates a liability on your balance sheet and a potential compliance issue. At scale, with thousands of transactions per day, manual chargeback processing is not sustainable.
Design your chargeback workflow before you go live. Map the states (received, under review, accepted, rejected, escalated), the transitions, the notification logic, and the GL impact of each outcome. This is product design work, not just integration work. And it's much cheaper to do before you have thousands of real disputes in flight.
Lesson 3: Multi-PSP Routing Requires a Control Layer
Operating multiple PSPs creates routing complexity. When should a transaction go to Adyen versus PayPal? What happens when your primary PSP has a degraded incident? How do you ensure that the routing logic doesn't create regulatory exposure, for example by routing transactions from certain jurisdictions to a PSP that isn't licensed to operate there?
The answer is a PSP control layer: a product component that owns routing logic, monitors PSP health, and enforces regulatory constraints. This layer needs to be owned by the product team, not delegated to engineering as a configuration problem. The business rules it enforces are product decisions with material financial and regulatory consequences.
The Vendor Relationship Matters
The quality of your PSP relationship is a product asset. Adyen in particular offers significant value beyond basic payment processing: advanced fraud tooling, account-level data, and direct bank integration capabilities that can replace more expensive intermediaries. Getting the most out of a PSP relationship requires treating it as a partnership, not a commodity purchase.