Attach an unattached credit to an invoice
For a transfer that landed in one of your accounts without an invoice number in the narration. The money
is already in your account, so no money moves and your balances don’t change; this only records the
credit against the invoice (unattached → matched), updating the invoice’s amount_paid and status
and firing invoice.paid when it is now paid in full. Allowed only for unattached credits and invoices in
sent, partially_paid or overdue. The credit can be attached to one invoice, once.
Error codes: invalid_api_key, parameter_invalid, parameter_missing, resource_not_found, scope_missing, csrf_token_invalid, idempotency_key_reused, currency_mismatch, rate_limited.
Authorizations
Server API key, scoped. pk_test_ keys hit the sandbox tenant.
Headers
Optional on non-money POSTs; honoured when sent.
1 - 255Optional client correlation id, up to 128 characters. It is not echoed: the response's X-Request-Id is always
our own req_… id. We log your value with the request as client_request_id, so support can find a request by
either id. A longer value is refused with 400 parameter_invalid.
128Path Parameters
Inbound credit id (icr_…).
^icr_[0-9A-HJKMNP-TV-Z]{26}$Body
Invoice to record the credit against (ivc_…).
Response
The credit, now matched.
Money received (icr_…), recorded once it has been credited to your account. A money-movement object, so it
carries ResponseOutcome (CONVENTIONS §7a), which is always 00: matched and unattached are both credited
to your account (unattached only lacks an invoice, link or virtual account).
Two-character ISO 8583 response code, using the NIBSS NIP meanings (CONVENTIONS §7a). 00 is success.
Carried on every error (mapped from error.code, see errors.yaml x-codes) and on every money-movement
object (the bank's final code, or our own while it is in flight). Clients must tolerate codes added later.
00, 01, 03, 05, 06, 07, 08, 09, 12, 13, 14, 15, 16, 17, 21, 25, 26, 30, 34, 35, 51, 57, 58, 61, 63, 65, 68, 91, 92, 94, 96, 97 ^[0-9A-Z]{2}$Standard meaning of the code (the x-codes text), not customer copy. Customer-safe wording is in status_reason / error.message.
"Approved or completed successfully"
icr_…
Always inbound_credit.
"inbound_credit"RFC 3339, UTC.
"2026-10-27T08:41:00Z"
An amount in minor units (kobo, cents) with its currency. Never a decimal.
Every inbound credit a business sees is already credited to one of its accounts.
matched: credited to your account and recorded against an invoice, payment link or static virtual account.unattached: credited to your account, but not tied to any invoice, link or virtual account (e.g. a transfer to Naira · Main without an invoice number). Attach it withmatchInboundCredit.
matched, unattached RFC 3339, UTC.
"2026-10-27T08:41:00Z"
The account number the payer sent to.
RFC 3339, UTC.
"2026-10-27T08:41:00Z"
Collection fee charged on this credit, if the business's plan has one. Posted separately.
The sending account, from the bank. account_name is the name the bank reported.
Details the payer typed on a pay page checkout, when there was one.
Narration sent with the transfer.
NIP session id.
^\d{30}$What the credit was matched to. For unattached credits type is account.
One of the business's own PanoFlow accounts (owned by the Accounts service).
Transaction (txn_…) in the account view, once credited.
Pay page checkout (cko_…) this credit paid, when there was one.
RFC 3339, UTC.
"2026-10-27T08:41:00Z"