Remittance apps
Use 0Gate carefully as a hosted ramp leg inside approved remittance-style products without overclaiming corridor or payout coverage.
Remittance-style apps are sensitive because product, legal, regional, payout, support, and compliance wording all matter. 0Gate can provide a hosted ramp, sell, or swap leg where approved, but the public docs should not claim that 0Gate makes every remittance route live or that it replaces your regulated program responsibilities.
Where 0Gate fits
0Gate is the hosted product leg, not the entire remittance product. Keep recipient logic, transfer records, compliance-specific messaging, refund policy, support model, and jurisdictional claims inside your reviewed product docs.
Documentation rules
| Topic | Safe public wording |
|---|---|
| Availability | "Availability depends on account configuration, supported markets, capability data, and required approval." |
| Status | "Your app should show pending until backend events confirm state." |
| Fees and FX | "Use approved API responses or partner agreement terms for any customer-facing economics." |
| Payout | "Use hosted or approved payout flows where enabled; do not document private rail internals." |
| Compliance | "Use product-approved KYC/KYB, privacy, and regional wording." |
Implementation shape
- Resolve the remittance product task outside 0Gate.
- Decide whether the hosted 0Gate leg is buy, sell, or swap.
- Check market and capability support before presenting the route.
- Create the 0Gate session with
user_referencepointing to your transfer attempt. - Use return pages for UX and signed webhooks for backend state.
- Keep support escalation able to reference both the transfer id and 0Gate session id.