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.

Two ways to receive

Money reaches you one of two ways. Pick the one that fits, then use the table below to find the exact account.

• A standing virtual account. A bank account (an NGN NUBAN, an international VIBAN, or a CAD Interac address) that you hand out once. Anything paid into it is yours because the account number identifies you. Use it when you want a fixed account to share and receive on an ongoing basis. See Virtual accounts.
• A collection link. A per-payment checkout link (checkout_url) for a specific amount, which your payer completes inside their own bank. Use it for a one-off or specific payment, on an invoice or behind a button. Available in GBP and EUR. See Collections.

Whatever you choose, the money lands in your merchant wallet and a wallet_funded webhook fires. The rest of this page is about the standing-account rails.

Rails by currency

ISO 4217 currency codes are used everywhere: amountMinor is always paired with a currency (e.g. GBP, USD, EUR, CAD, NGN).

Which flow am I in?

Answer two questions: what currency, and whose money is it.

Receiving for one of your end-users, in a foreign currency? Issue a customer international account. The inflow carries a customer attribution block so you can credit the right user. See International accounts.

Receiving for a business you onboard, in NGN? Issue a sub-merchant account (a NUBAN). The inflow carries a customer block keyed on the reference you set, so you can attribute it to the right sub-merchant. All inflows pool into your one NGN wallet. See Sub-merchant collections.

Receiving into your own treasury? Use your own account for that currency: your NGN funding account, your treasury VIBAN (GBP / USD / EUR), or your CAD Interac address. These are merchant-pool credits with no customer block. See Virtual accounts and CAD & Interac.

Taking a one-off payment in GBP or EUR? Open a collection instead of handing out a standing account. You get a checkout_url for that specific amount.

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.

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_funded webhook → amountMinor is the gross, feeMinor is the fee, netMinor is what you kept
• GET /v1/customers/{id}/transactions → amount_minor, fee_minor, net_minor on each collection
• GET /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 →: per-customer and merchant international accounts
• CAD & Interac →: receiving CAD by Interac e-Transfer
• Attribution & balances →: credit the right user, pull history + balances
• Webhooks →: the wallet_funded payload + field reference

What’s next