Receiving money
Money lands in your merchant wallet through a funding rail, and Swappr fires a wallet_funded webhook for every credit — with the sender’s details and, when the credited account belongs to a customer, a customer attribution block. Whatever the rail, the pattern is the same: subscribe to wallet_funded, verify the signature, and reconcile against your own records.
Rails by currency
| Currency | Rail | How it receives |
|---|---|---|
| NGN | Merchant virtual accounts | Senders transfer to a NUBAN virtual account on your wallet (the existing funding flow). |
| GBP / USD / EUR | International-account VIBANs | A virtual IBAN / account number — issued either per customer or for your own treasury account. Senders pay it via local/SWIFT rails. |
| CAD | Interac e-Transfer | Senders e-Transfer to a registered Interac address; no VIBAN. |
ISO 4217 currency codes are used everywhere — amountMinor is always paired with a currency (e.g. GBP, USD, EUR, CAD, NGN).
Which collection flow am I in?
- Receiving for one of your end-users? → issue a customer international account. The inflow carries a
customerblock so you can credit the right user. See International accounts. - Receiving into your own business treasury? → a merchant international account. The inflow is a merchant-pool credit with no
customerblock. See International accounts. - Receiving CAD? → use CAD & Interac — funds route by your registered Interac address, not a VIBAN.
Attribution in one line
Your merchant wallet is always credited. When the credited account belongs to a customer, the wallet_funded payload carries a customer block — branch on event.customer?.id. See Attribution & balances for crediting end-users and pulling history.
Sandbox limitation: only NGN settles in the development environment. GBP / USD / EUR VIBANs provision in sandbox but don’t receive funds, and CAD/Interac inflows aren’t simulated. Use sandbox to test the create + provision + webhook-handling flow; switch to live for actual inflow testing.
Funding fees
Inbound funding may carry a fee. Where it does, your wallet is credited the gross and the fee is taken as a separate debit — we never quietly reduce the credit. That means two entries per inflow, matching bank-statement convention and keeping refunds clean, but it also means the credit you see is not the amount you kept.
Read the difference off whichever surface you already use:
wallet_fundedwebhook →amountMinoris the gross,feeMinoris the fee,netMinoris what you keptGET /v1/customers/{id}/transactions→amount_minor,fee_minor,net_minoron eachcollectionGET /v1/wallets/{id}/funding-events→ the same three fields per event- The fee debit itself is a normal ledger row:
GET /v1/wallets/{id}/transactions?source=virtual_account_credit_fee
fee_minor / feeMinor is "0" when no fee applies, and combines fee and tax into one number. If you credit an end user off an inflow, credit them the net.
Next
- International accounts (GBP/USD/EUR) → — customer vs business VIBANs
- CAD & Interac → — receiving CAD by Interac e-Transfer
- Attribution & balances → — credit the right user, pull history + balances
- Webhooks → — the
wallet_fundedpayload + field reference