Challenge
A shop wants to take payments, not to study thirty-five protocols. Every payment system has its own request format, its own confirmation, its own refund logic, and its own set of moments when the money has moved and the callback has not. The platform exists so that all of it stays on our side and the merchant sees one way in.
Solution
The platform works as a dynamic gateway. The path a payment takes is the same for every system, and the differences live in the description of a particular gateway, so a new system arrives as configuration and an adapter instead of a rewrite of the core.
Money moves like this: the shop starts a payment over the API, the buyer pays on the checkout page, the payment system sends a callback, the amount less fees lands on the merchant balance, and a scheduled payout takes it out. Fees are calculated in two stages, gateway and platform separately, with discounts and conversion to the base currency. That formula lives in exactly one place, because a second copy of a money calculation always drifts from the first.
Architecture and implementation
The platform ships an integration API and a hosted checkout page, plus adapters that add a payment system without touching the core. Callbacks are verified on arrival, the merchant balance carries a full operation history, and accounts for incoming money are chosen by strategy under daily, weekly and monthly limits.
Plugins for common shop engines and an SDK cover merchants who would rather not write the integration themselves. Stack: Laravel and PHP, MySQL.
Result
More than thirty-five different payment systems behind one integration. The number counts distinct systems rather than pieces of work: each one has its own protocol and its own edge cases.
The same figure sits on our home page as a measure of reach, and this is the project it came from.
