Ask a growth team where their funnel leaks and they will show you onboarding charts. Ask the support inbox and you get the truer answer: the deposit failed. For brokers expanding into emerging markets, payments are not a back-office detail — they are the difference between a marketing budget that compounds and one that evaporates at the checkout screen.
The uncomfortable geometry: the geos where user acquisition is cheap are the geos where global payment rails work worst.
The deposit screen is your real landing page
A trader who saw your ad, installed the app and passed KYC has cost you real money. If their first deposit fails, almost none of them try a second method — they just leave, and your analytics files it under "activation drop-off" instead of "payments problem".
Every failed first deposit is a marketing spend refund you issued to nobody.
In markets like Brazil, Indonesia or much of Southeast Asia, the local instant systems — PIX, QRIS, domestic bank transfers — are not alternative methods. They are the method. Cards exist, but decline rates on cross-border merchant codes and punitive FX margins make them a poor primary rail. A broker that launches with cards-only in these geos has effectively launched closed.
Four layers, one integration
The stack that works in practice is boring and layered. What matters is that it sits behind one integration and one status contract — a deposit is created, pending, confirmed or failed the same way regardless of rail, so support, reconciliation and the trading backend see one lifecycle.
| Layer | What it does | The pain it removes |
|---|---|---|
| Local methods | Cards, PIX, QRIS, local fiat accounts per geo | Deposits failing exactly where growth is |
| Fiat on/off-ramp | Routing that respects each jurisdiction's KYC; webhooks, idempotency, reconciliation | Every new geo becoming a compliance project |
| Crypto gateway | Addresses and QR across four network families, statuses and history | Node ops, address risk and reconciliation done in-house |
| Non-custodial wallet | MPC wallet — six assets, four networks, no single party controls funds | Becoming an accidental custodian |
We run this stack in production on our own brokerage, which is why the table reads like an operations checklist rather than a brochure: webhooks that retry, idempotency on every mutation, statement-level reconciliation. The parts nobody demos are the parts that decide whether month-end takes an hour or a week.
Withdrawals are where trust is won
Deposits get the attention; withdrawals set the reviews. Three rules we hold:
Same rails out as in where the jurisdiction allows — a user who deposited via a local method should not be forced into an unfamiliar one to exit.
KYC at the right moment. Per-jurisdiction rules decide when enhanced checks trigger. Blanket friction loses users; missing checks loses licenses. The routing layer has to know the difference per geo, not per company policy.
Statuses over promises. A withdrawal that honestly says "processing, next update in N hours" generates a fraction of the tickets that a silent spinner does. The status contract is a support tool as much as an API design.
The custody question, answered on purpose
Crypto deposits tempt platforms into holding funds "temporarily", and temporarily has a way of becoming an operating model. Holding client funds makes you a custodian — with licensing, audit and insurance burdens attached.
An MPC wallet inverts the default: no single party, including the platform, can move funds alone. Whether you want the custody boundary at the gateway, at the wallet or at a partner is a genuine business decision — the point is to make it explicitly, with counsel, rather than inherit it from whatever your first payments vendor shipped.
One question for your payments shortlist
When you evaluate providers — including us — ask one operational question:
"Show me the status lifecycle of a failed PIX deposit and who gets notified at each step."
Vendors with a real answer show you a state machine within a minute. Vendors without one show you a logo wall. In payments, the state machine is the product; the logos are decoration.