Skip to main content
Chipper moves money over three kinds of rail. They differ in who initiates, how long they take, and what “done” means, and every endpoint in this API is a thin layer over one of them.

Mobile money

The dominant way money moves in Ghana, Kenya, Uganda, and Rwanda, our core mobile-money markets, with further corridors (Tanzania, Zambia) listed in capabilities where live. A wallet tied to a phone number, run by a telecom operator (MTN, M-Pesa, Airtel, Telecel…).
  • Paying out: near-instant. You send to a phone number; the wallet is credited in seconds. This is the rail behind most gh_*, ke_*, ug_*, tz_*, rw_*, zm_* method codes.
  • Collecting: the payer must approve. A collection sends a prompt (STK push / USSD) to their phone; they enter their PIN; the money lands. Sessions time out in minutes if they don’t. This is why collections are pending first and why “the customer never approved” is a normal failure, not an error.
  • Validation: most operators resolve the account holder’s name from the number, so use it before you pay.
  • Nigeria is the exception: mobile money exists (OPay, MTN MoMo, SmartCash) but bank transfer dominates.

Bank transfer via virtual accounts

Bank rails are batch-oriented and slow to initiate from your side, so Chipper turns collection around: you don’t pull from the payer’s bank, the payer pushes to you.
  • A virtual account is a real bank account number (at a partner bank) that belongs to your organization and, optionally, to one customer. Money sent to it credits your balance and fires account.credited / collection webhooks.
  • The hosted checkout provisions one per payment session from a pool, so the exact amount can be matched to the exact payer.
  • Ghana (GHS) accounts are opened at UMB against your organization representative, one per customer. They are never pooled, since a recycled real account would credit a late transfer to the wrong payer, so hosted checkout collects GHS by mobile money instead.
  • Detection is automatic via the bank’s notification, typically within minutes, sometimes longer. There’s no “I’ve sent it” button because the bank tells us.
  • Paying out to a bank account is the reverse: near-instant in Nigeria (NIP), minutes elsewhere. Method codes look like ng_gtbank, gh_gcb.

Stablecoins

USDC and USDT on Ethereum, Polygon, Solana, Base, Tron, and BNB Chain: the rail for cross-border settlement and for customers who hold crypto.
  • Collecting: you get a deposit address per asset + chain (plus a memo/tag on Stellar and Ripple). The payer sends from any wallet; we watch the chain, wait for confirmations, then credit your balance. Chipper quotes the crypto amount from a locked FX rate into your fiat balance.
  • Paying out: send to any address on a supported chain; the destination amount is in the asset, and cross-currency is priced at the live rate.
  • Send the exact amount, on the exact chain. Tokens sent as a different asset or on a different network can be unrecoverable, which is why the hosted checkout says so in red.
  • Confirmation times vary by chain: seconds on Solana and Base, a few minutes on Ethereum.

Choosing a rail

The catalog of what’s live per country, with each method’s fields, limits, and expected settlement time, is GET /v1/capabilities, and it differs between sandbox and production, so read it at runtime rather than hardcoding it.