Multi-Acquirer Payment Orchestration & KYC

Context

MillionBridges is a regulated cross-border remittance service that lets people send money into Lebanon and, through a charitable model, channel the platform's margin to partner charities. It operates under real regulatory oversight, registered with the Bank of Spain, authorized by Banque du Liban, and operating within the European Banking Authority framework, which raises the bar on KYC, traceability, and payment reliability.

The platform integrates with a new account-management and ledger system, which does not itself provide identity verification or card acquiring. That left two capabilities to design and own: a KYC layer and a card-payment layer, each provided by external specialists, each needing to plug cleanly into MillionBridges as the orchestration engine sitting between them.

The money-out side mattered just as much as the money-in side. Funds arrive with a beneficiary in Lebanon who, after passing local identity checks, chooses how to receive them: as cash (USD bills) or as a top-up to their existing e-wallet, handled through a regulated payout network. A distinctive "BridgeAccount" model also lets senders hold funds safely in Europe and withdraw in parts, rather than every transfer being all-or-nothing.

The challenge

• Accept card payments in many currencies when no single acquirer covers them all, without exposing that complexity to the sender.
• Keep payments flowing even when a payment provider has an outage, rather than failing the transaction outright.
• Integrate regulated identity verification (KYC) in a way that isn't locked to a single vendor and satisfies audit requirements.
• Present transparent, accurate pricing to the sender even though fees and exchange rates differ depending on which provider handles the payment.
• Give the receiver a real choice at cash-out, cash or wallet, while enforcing local identity checks and payout limits.
• Work within a hard regulatory constraint: every third party in the chain had to be acceptable to the Spanish regulator, so delivery had to be sequenced around external approvals the project didn't control.

My role

As Product Manager and Product Owner on this work, the product definition for these features was owned here, working with the client's business owner, the payment and identity providers, and the development team. Responsibilities ran across discovery, authoring the functional specification documents (FSDs) with exhaustive acceptance criteria, prioritizing and sequencing the backlog across sprints, and running acceptance testing. As the single point of contact, the role was to translate regulatory constraints, provider API behavior, and commercial rules into requirements the team could build against, while commercial and vendor decisions stayed with the business owner.

Approach

• Orchestration, not a single integration. The specification framed MillionBridges as an orchestration layer sitting between two card acquirers, a specialist KYC provider, a wallet provider, and the account and ledger system, using a modular integration model so additional providers could be onboarded later without re-architecting.
• Currency-based acquirer routing. The design defined automatic routing that detects the transaction currency and sends each payment to the acquirer assigned to it, applying that acquirer's fees and exchange rates dynamically, all transparent to the sender. (The specific routing rules are held back here as they're commercially sensitive.)
• Failover with health checks. The spec introduced a pre-transaction health check so that if the primary acquirer is unavailable, eligible payments reroute automatically to a backup, and where no backup exists, the sender gets a clear, honest "please try again later" rather than a silent failure. Routing reverts automatically once the provider recovers.
• Provider-independent KYC. The identity-verification layer was specified so the data model stayed independent of any single KYC vendor: a multi-step verification flow with video capture, asynchronous status updates via webhooks, storage of verification media for rejected-case review, admin-configurable country blocking, and full audit fields.
• Transparent pricing. The spec defined how the app shows a clear breakdown of what the sender pays, what the beneficiary receives, and, in this platform's charitable model, what reaches the partner charity, computed correctly regardless of which acquirer processed the payment.
• Card handling and recurring payments. The spec covered secure card tokenization scoped per acquirer, 3-D Secure applied where regulation requires it, and recurring-payment mandates, so returning senders get a faster, compliant experience.
• Beneficiary cash-out: cash or wallet. The payout side was specified so the receiver, after local KYC, chooses between collecting cash (USD bills) or topping up their e-wallet, integrated with a regulated payout network, with balance controls that authorize each cash-out or top-up and support partial withdrawals.
• Transparent, itemized pricing. The design defined a full cost breakdown the sender can open on any transaction: the exchange rate applied, the card-scheme cost, the bank's cut, the payout provider's cut, what the platform keeps, and, in the charitable model, the amount delivered to charity, with an admin able to configure these parameters.
• Traceability of donations. A follow-up flow was specified to send the sender proof their contribution reached the partner charity, closing the loop on the platform's transparency promise.

Outcomes

Decisions & learnings

• Designing for a vendor change no one could predict. Provider selection sat with the client, as it should, it's a commercial and regulatory decision, not a product one. The product job was to make the architecture resilient to it. Specifying the KYC layer to be provider-independent turned out to be the decision that mattered most: when the KYC provider was replaced during the project, the team could switch without rebuilding the integration or the data model.
• Parallelizing against the approval gate. Because each provider had to clear regulatory approval before going live, the integration groundwork ran in parallel with the approval process rather than waiting for it, so a provider could go live quickly once approved, while making sure nothing went into production ahead of sign-off. It's an example of managing a roadmap around constraints you don't control instead of letting them stall the project.

Alongside this payments and KYC work, the platform also went through a full rebrand, app redesign, and a new mobile biometric security framework, covered in the next case study.