// Case study · Fintech / payments
Provider connector framework
A unified flow-action model that let a payment-orchestration platform onboard new acquirers and aggregators the same way every time — turning bespoke integrations into a repeatable contract.
The problem
Every acquirer and aggregator speaks its own dialect — different flows, fields, statuses and quirks. Integrating each one bespoke meant slow onboarding and fragile, copy-pasted code that broke in subtle ways — with real money on the line.
The approach
A single flow-action model: each provider maps its own request and response into a common set of flow actions (authorize, charge, payout, refund, 3-D Secure step…) through a payload builder per action, and its raw statuses map back into one normalized payment state machine.
The decision & trade-off
We invested up front in the abstraction — a common contract plus a directory of providers synced into the platform — accepting more boilerplate per provider in exchange for uniform behavior, testability, and onboarding that scaled from bespoke to repeatable.
Architecture
Providers plug in as connectors behind the contract; a payload builder per flow-action + command shapes each outbound call, and a mapping layer turns provider statements into normalized flow-action results the orchestrator can route, retry and reconcile on.
Outcome
New providers became a bounded, well-understood task instead of a research project — the same integration shape, tested the same way, across a large and growing provider base.
What I'd do differently
Push even more provider-specific quirks into declarative config rather than code, so onboarding a provider trends toward data, not development.
Architecture diagram
Stack
- PHP
- Symfony
- PostgreSQL
- RoadRunner
Have a similar problem?
Tell me about it — I reply within a day.