Prerequisites
Before creating a wallet:- create an
individualcustomer and retain the returned UUID; - authenticate with the production API key belonging to that customer’s merchant; and
- generate a stable
walletReferencein your system.
Create a customer wallet
An HTTP
201 response returns the wallet ID and assigned account details:
One wallet per customer
Only one NGN wallet can be created for a customer. A second creation attempt is rejected. Wallet creation does not provide idempotency semantics. If the response is lost or times out, retrieve the customer wallet or reconcile with support before trying again. Repeated creation attempts can leave an upstream account that requires operational reconciliation.Receive NGN
1
Display the assigned account
Show the bank name, account name, and account number returned by FossaPay.
2
Receive a bank transfer
The sender transfers NGN into the persistent account. Do not treat an uploaded receipt as confirmation.
3
Verify the event
Validate the webhook signature and acknowledge
deposit.completed quickly.4
Post once
Deduplicate by
eventId and update your ledger in the same database transaction as recording the processed event.5
Reconcile
Use the wallet transaction endpoints when delivery is delayed or the outcome is disputed.
Retrieve wallets and balances
Retrieve a wallet by its FossaPay UUID or assigned account number. Responses include:availableBalance: funds currently available for a new operation;ledgerBalance: the provider ledger balance;walletName; and- the bank account details.
GET /api/v1/wallets/fiat/master. That wallet holds business funds and is the source for Master Wallet Payouts.
Wallet-to-wallet transfers
POST /api/v1/wallets/fiat/transfers/wallet-to-wallet moves NGN between wallets owned by the authenticated merchant. Both account numbers must exist and belong to that merchant.
- The amount must be positive and cannot exceed the source available balance.
- Transfers are free.
narrationis required and limited to 255 characters.referenceidentifies the logical transfer and must not be reused for a new operation.- A successful replay of the same source/reference returns the existing successful transaction instead of moving funds twice.
- Pending or previously failed references must be reconciled rather than blindly replaced.
Transaction history
Wallet transaction lists are newest-first and support:
The response can include beneficiary details for external withdrawals, originator details for external deposits, or the destination account for internal transfers.
Errors and recovery
API reference
Production checklist
- Persist the customer UUID before wallet creation.
- Generate and store
walletReferencebefore calling FossaPay. - Store the assigned wallet and bank details from the response.
- Never confirm deposits from receipts alone.
- Verify webhook signatures and deduplicate by
eventId. - Reconcile ambiguous writes and delayed events through transaction history.
- Keep customer funds separate from merchant master-wallet funds.

