Why every module is swappable by contract
Pay-in, payout, KYC, messaging — each sits behind a stable internal contract. Here is why that design matters for operators who run on MEXAR.
Money-services businesses do not all need the same providers. A remittance operator in one corridor wants a different payout partner than one in another; an operator’s preferred KYC vendor may change as regulation evolves. So MEXAR was built on a simple rule: no provider is hard-wired into the platform.
A contract per module
Each capability — pay-in, payout, KYC/AML, messaging — sits behind a stable internal contract. The core platform talks to the contract, never to a specific vendor. Concrete providers are adapters behind it:
- Pay-in — iPayMu, Bayarind, Xendit
- Payout — Transfez, EasyLink, BankAPI (by contract)
- KYC — Onfido, RegTank, Glair.AI
- Messaging — Twilio, MessageCentr, SendGrid
What it buys operators
Because the contract is the boundary, you can run one provider, several in parallel, or add a new one — without rebuilding the platform. Switching a payout partner for a corridor is a configuration and integration task, not a re-architecture. New providers are onboarded by contract as part of a customization engagement.
The same idea, end to end
This is the same principle that runs through MEXAR: microservices with defined contracts, connected by a queue-driven pipeline. Domains stay independent, so the platform extends and scales without the whole system moving in lockstep — which is exactly what an operator needs to grow a regulated money business.