Practical writing for people who pay and get paid on a phone: mobile money, QR payments, cards, remittance costs, agents and how your money is protected.
Most of an integration is the same every time: authentication, idempotency, signature verification, retries. SDKs and a shop plugin do that part, and they are built from the same table that serves the requests.
Waiting for a scheme to publish its profile before writing any code wastes a year. Writing against an internal contract, with a simulator for the ugly cases, means the connection becomes a codec rather than a rebuild.
A payment can usually travel several ways, and they are not equally good at two in the morning. Routing on measured success, cost and latency — with a breaker on failing rails — is the difference between resilience and a bad night.
Every successful platform reaches the day it starts collecting on behalf of its customers. Pool it and you are holding other people's money without a licence. Here is the third option: they are the merchant of record, and they can remove you whenever they like.
A webhook is worth what your ability to verify it and survive missing one. Two independent signatures, a published retry schedule across 24 hours, event ids for deduplication, and an inbox for before your server exists.
The documentation is generated from the same table that serves the requests, so it cannot describe an endpoint that does not exist. Idempotency that refuses rather than duplicates, errors you can branch on, and a sandbox that fails properly.
Send with a QR code, add money by card or mobile money, issue a virtual card. Sandbox balances let you explore before any real money moves.