Wallet funding
Use hosted 0Gate sessions to let users fund supported wallet balances without exposing private ramp internals.
Wallet funding is the most common 0Gate pattern: the user clicks a fund, buy, or deposit button; your backend creates a hosted session; the user completes the 0Gate flow; and your backend credits the wallet only after a verified event.
Funding flow
Design decisions
| Decision | Recommendation |
|---|---|
| Open or locked flow | Use flow: "on_ramp" when the user clicked a buy/fund action. Use open widget only when the page intentionally lets the user choose. |
| Destination | Prefill wallet_address only after your app validates the destination and network. |
| Asset | Use target_token and target_network only when capability data supports the pair. |
| Status | Show pending until your backend verifies the webhook. |
| Ledger | Credit your wallet ledger from backend state, not from browser callbacks. |
Example session intent
await gate.sessions.create({
amount: '75.00',
currency: 'EUR',
flow: 'on_ramp',
target_token: 'USDC',
wallet_address: userWalletAddress,
user_reference: 'wallet_funding_456',
return_url: 'https://wallet.example/funding/456/return',
});Operational guardrails
- Keep wallet addresses, user ids, and order ids support-safe and access controlled.
- Do not publish unsupported asset/network availability.
- Do not describe internal liquidity, reserve, or custody operations.
- Keep failed, expired, or abandoned sessions separate from completed ledger credits.