Inflow lifecycle

An inflow is one NIP transfer from another bank to one of your virtual account numbers. This page follows it from the payer’s app to your ledger, and names the states you will see in the portal and in webhooks. Internal transfers from another account at the same bank to your number follow a shorter version of the same path, noted where it differs.

The moments

1. The payer enters the number. Their bank sends a NIBSS name enquiry. BankCore finds the band the number sits in and, on a LOCAL band, the record you created. It answers with the account name if the number is ACTIVE; 07 (not found) if there is no record; 06 (declined) if the number is USED or EXPIRED. On a REMOTE band it asks your validation endpoint instead. Nothing is recorded on a LOCAL band at this step.

2. The credit arrives. NIBSS delivers the transfer with a session id. BankCore re-runs the rules before acknowledging: the number is live as of arrival, the amount matches an exact-amount rule, the band’s fixed or minimum amount holds, and the settlement account can take credits. A failure is acknowledged to NIBSS as 06, 07, 13 (amount) or 61 (limit), the payer’s bank shows its customer a failure, and no money moves. A pass is acknowledged 00.

3. NIBSS confirms, the bank posts. The credit is confirmed against NIBSS and booked. The fee for the band, if any, is withheld; the settlement account is credited with the net; a NIP_INWARD transaction is written carrying the session id, the sender’s name, account and bank, the narration, the virtual account number and name, your external_ref, and the gross, fee and net amounts. A single-use number flips to USED. On a REMOTE band the settlement account is the band’s linked account or the one you nominated at name enquiry.

4. You are notified. On a LOCAL band, a transaction.completed webhook is queued for every subscription of yours that the event reaches, with the transaction metadata merged into the payload and the net amount in amount. On a REMOTE band, a job that runs every 30 seconds POSTs the payment notification to your notification endpoint. Either way the money is already in your account; the notification only tells you so.

5. NIBSS settles. On the next business day NIBSS’s settlement file reaches the bank and each session is matched. This is the bank’s position with NIBSS, not yours: your account was credited at step 3 and is not adjusted by settlement.

An internal transfer to your number skips steps 1, 2 and 5. The same rules run at posting, the transaction type is VA_CREDIT_IN, and the notification is the same webhook or callback.

Statuses you will see

Where	Values	Meaning
Virtual account (LOCAL)	ACTIVE, USED, EXPIRED	Whether the number still takes payment.
Inflow (portal Inflows)	CONFIRMED, REVERSED	CONFIRMED is a credit that was posted to your settlement account. REVERSED means the sending bank later recalled it and the net was taken back out of the account it landed in.
Notification (portal Inflows)	PENDING, DELIVERED, RETRYING, FAILED, SKIPPED, NOT_APPLICABLE	See below.

Notification statuses:

• PENDING: owed, and the sending job has not reached it yet.
• DELIVERED: your endpoint answered 2xx (callback) or the webhook was delivered.
• RETRYING: the last attempt failed and attempts remain.
• FAILED: attempts exhausted. Nothing will retry it automatically; you or the bank can resend.
• SKIPPED: a callback was owed but the band has no notifyUrl. Nothing was sent.
• NOT_APPLICABLE: neither pipeline owed anything for this credit, for example a band with no webhook subscription and no notifyUrl.

A credit with a FAILED or SKIPPED notification is still money in your account. The portal’s Inflows summary counts these as “not notified” so you can find them.

Timing

• Name enquiry to credit is governed by the payer’s bank; typically seconds, sometimes minutes.
• Credit acknowledgement to posting: seconds when the bank can confirm with NIBSS promptly. During a NIBSS outage credits wait in a confirmation queue; a number that expires while a credit waits does not cause that credit to be refused.
• Posting to webhook: the delivery poller runs every 10 seconds. Posting to callback: the callback job runs every 30 seconds.
• Reversal by the sending bank can arrive hours or days after the credit. Design for it: see Reconciling a day.

Reversals

A sending bank can ask for a confirmed credit to be reversed. BankCore debits the net amount from the account that received it, reverses the fee leg, and marks the inflow REVERSED. A LOCAL band’s webhook subscription receives transaction.reversed.

No callback on reversal for REMOTE bands

The callback job sends only for confirmed credits. A reversal on a REMOTE band produces no POST to your notifyUrl. Watch the inflow status in the portal, or hold a webhook subscription for transaction.reversed alongside your callback endpoint.

What the portal shows

Virtual accounts is the list of numbers with effective status. Inflows is the per-band list of credits, each with received time, amount, sender name, account and bank, narration, transfer reference, session id, and the notification outcome with its HTTP status and error text when the endpoint is yours. Settlement with NIBSS is not shown there; it is not a fact about your money.