Reaching the cross-bank ledger Zap builds on top of NIBSS

Paystack pushed Zap into the Play Store and the App Store in March 2025 — its first direct-to-consumer product after nine years of building the merchant rail, per Paystack's own launch post. The integration question on this app is unusual. It is not "how do we replace a bank?" — Zap explicitly is not a bank, and deposits sit with a CBN-licensed banking partner. It is "how do we reach the rolled-up view Zap builds across whatever Nigerian banks a customer has linked through NIBSS, plus the auto-categorisation laid on top of that merged feed?" Neither the individual bank's portal nor Paystack's merchant API exposes the same thing.

What sits behind a Zap account

A Zap account is a thin consumer shell over a set of NIBSS-linked bank accounts, plus a Paystack-issued wallet for funding from sources the user has not linked as a bank (Apple Pay for visitors-to-Nigeria, for example). The integrable surfaces are mostly the rolled-up reads — the underlying bank ledgers still live with each bank and reach the buyer through that bank's own consent, not through Zap.

How we reach it

Three routes apply here. They are not interchangeable; each one is suited to a different question the buyer actually has.

1. CBN Open Banking consent, layered per linked bank

Nigeria has a real open-banking framework. The CBN released its Operational Guidelines on 7 March 2023, classifying participants as API Providers, API Consumers and Customers, and requiring explicit, revocable consumer consent plus a Service Level Agreement between provider and consumer. Where the buyer is already a registered API Consumer, or partners with one, this is the durable, regulator-blessed path to each linked bank's own ledger. It does not reach Zap's category overlay or its cross-bank rollup — those are Zap's own data, not the bank's. Effort: meaningful onboarding (registry, SLA, NDPC alignment). Durability: high.

2. Authorised interface integration with Zap itself

The practical route to Zap's value-adds — the cross-bank view, the spend categories, the saved beneficiaries and the Paystack-checkout reference. We capture and document Zap's mobile sign-in (OTP-driven, with a device-fingerprint tied to the consenting account), the session-token refresh, and the JSON shapes the app actually uses for accounts, transfers, categories and merchant references. Effort: 1–2 week build. Durability: medium; we re-validate after each major Zap release.

3. NIBSS Direct Debit (iGree consent) for recurring pulls

Where the use case is initiating recurring debits from a linked bank rather than reading state, the NIBSS mandate flow — backed by the iGree consent platform — is the right path. Effort: NIBSS sponsor, mandate paperwork, BVN-linked account verification. Durability: high.

For buyers who need the cross-bank ledger and the category overlay — which is the distinctive Zap data — Route 2 carries the build, with Route 1 layered in on a per-bank basis where the same account also has to satisfy regulated open-banking obligations. Route 3 sits alongside, only when there is a recurring-pull requirement.

A worked example

The snippet below is a sketch of the surface, not a verbatim contract. Exact host, paths and field names are confirmed during the build against a consenting test account.

# Authenticated session against the user's Zap account.
# Sign-in is OTP-driven with a device-fingerprint tied to that account;
# session tokens are short-lived bearer values that rotate on refresh.

GET https://<zap-mobile-api-host>/v1/accounts
Authorization: Bearer <consented_session_token>
X-Device-Fingerprint: <captured_at_pairing>

# Representative response shape:
# {
#   "linked_accounts": [
#     { "bank_code": "058", "bank_label": "GTBank",
#       "masked_number": "******8821",
#       "balance_minor": 4530700, "currency": "NGN",
#       "nibss_mandate": "active" }
#   ],
#   "default_funding": "058:masked_8821",
#   "tier": 2,
#   "kyc": { "bvn": "verified", "nin": "verified", "address": "pending" }
# }

GET https://<zap-mobile-api-host>/v1/transfers?from=2026-04-01&to=2026-04-30
# Each row:
#   peer.name, peer.bank_code, peer.account_masked,
#   amount_minor, fee_minor, currency,
#   category_tag,              # auto-classified
#   paystack_merchant_ref,     # present only on Paystack-checkout payments
#   status, completed_at

Two notes on the shape. Amounts are in NGN minor units (kobo), so a balance of 4,530,700 is ₦45,307.00 — every client we ship surfaces both the minor-unit field and a human-readable display. And the paystack_merchant_ref is only present on Zap-to-Paystack-merchant payments; on plain peer-to-peer transfers the field is absent rather than null, and downstream code has to treat the two paths as distinct.

What you get from us

• An OpenAPI 3.1 specification covering accounts, transfers (paged by date), saved beneficiaries, the category overlay and the Paystack-checkout reference — field-level, with the NIBSS bank-code reference table and the NGN minor-unit conventions documented.
• A protocol and auth-flow report: OTP sign-in, device-fingerprint pairing, session-token refresh, the cookie and header chain we observed against the consenting test account.
• Runnable clients in Python and Node.js for the endpoints above, with retries that respect Zap's rate posture and back off cleanly on the OTP-step responses.
• An automated test suite that runs against a consenting test account, including Tier-1 and Tier-2 fixtures so the eligibility logic gets exercised before production.
• A compliance pack: NDPA-aligned consent-record templates, the SLA outline a buyer needs if filing as an API Consumer with the CBN Open Banking Registry, and data-retention notes that match the NDPC's audit framing.
• A short retainer for re-validation after each major Zap mobile release.

Things this build has to handle

Four engineering details are worth pulling out, because they are specific to Zap and the studio designs the build around them:

1. Per-tier eligibility is a precondition, not a footnote. Zap publishes three KYC tiers — BVN-only at ₦50,000/day, NIN with selfie and address at ₦200,000/day, full verification at ₦5,000,000/day, per the Zap support article. The integration reads the tier first and gates any large-value action on it; without that check a buyer's downstream flow will silently fail on a Tier-1 account holder.
2. Cross-bank reconciliation against the NIBSS code table. Each linked bank arrives with a NIBSS bank code, a masked number and its own balance. We normalise to a canonical institution registry and surface both the Zap-side label and the NIBSS code, so downstream code never has to guess which "Access" the user meant. Apple Pay funding for non-residents is treated as a separate funding source — no NIBSS code, kept out of bank-aggregate reports.
3. The Paystack-checkout flow is its own surface. When a Zap user pays a Paystack-powered merchant from inside Zap, the row carries a Paystack merchant reference that a plain peer-to-peer transfer does not. We wire that field through end-to-end rather than folding it into the generic transfer feed, so merchant reconciliation stays clean.
4. A scheduled recheck after each major Zap release. Zap shipped in March 2025 and is still iterating; mobile-app surfaces drift. The retainer pulls a fresh capture against the test account, diffs the JSON shapes against last quarter's, and patches the client before the buyer notices.

Access — a consenting test account, an NIBSS sponsor sandbox where Route 3 is in play, an NDA where one is needed — is arranged with the buyer during onboarding. It is something the engagement sets up, not a wall the buyer has to clear before we begin.

CBN open banking, NIBSS, and the NDPA

Nigeria sits unusually well for this kind of work, and the page is honest about that. The CBN Operational Guidelines for Open Banking, dated 7 March 2023, define the API Provider, API Consumer and Customer roles, mandate explicit revocable consumer consent for any data sharing, and require an SLA between provider and consumer with named processes for incident management, performance monitoring and quarterly failover. Where the buyer is registered with the CBN Open Banking Registry, or partners with someone who is, the regulated route to per-bank data is in place — that is Route 1 above.

For work that sits on Zap's own surfaces, the dependable basis is the user's consent under the Nigeria Data Protection Act 2023. We capture it against an NDPA-aligned consent record at the start of the engagement — scope, retention, revocation channel, NDPC-style technical and organisational measures — and the consent record is logged for the life of the integration. Where the NIBSS Direct Debit mandate is the route, iGree captures the customer's consent on the bank's own channel, and we record the mandate reference rather than the underlying credentials. Nothing on this page proposes a non-authorised path.

Working with us on this

For Zap, a normal build is the sign-in handshake against a consenting test account, then pulls for linked-bank balances, transfer history paged by date, saved beneficiaries, the category overlay and the Paystack-checkout reference where present — delivered as runnable Python and Node.js clients with tests, an OpenAPI spec and the protocol report. Source-code delivery starts at $300, billed only after you have reviewed what we hand over and confirmed it works against your account. If you would rather call endpoints we host, we run the same integration and bill per call, no upfront fee. Either path runs in 1–2 weeks. The shortest way to start is the form at /contact.html — the app name and a sentence on what you want from its data is enough; access and compliance get arranged with you from there.

Adjacent Nigerian apps with related data

These are the same-category neighbours an integrator usually looks at alongside Zap. Each holds its own server-side records and is reachable on the same kind of authorised, consent-anchored path.

• Opay — large Nigerian wallet operating its own ledger; relevant when a buyer wants wallet-side balances and transaction history alongside Zap's bank-linked view.
• PalmPay — wallet plus agent network; per-user transaction history and bill-payment records sit behind the account.
• Kuda — CBN-licensed digital microfinance bank; balances, transfer history and budget envelopes inside a single bank ledger.
• Moniepoint — consumer and business apps over the Monnify rail; account, POS and transfer records are server-side.
• Cowrywise — SEC-licensed savings and mutual-fund app; positions, contribution schedules and goal progress are the integrable surfaces.
• Quickteller by Interswitch — long-running bill-payment app; transaction history, beneficiaries, Verve card linkage.
• ALAT by Wema — bank-issued digital app with full per-customer bank surfaces.
• Send by Flutterwave — cross-border remittance app with per-user transfer history and FX records.
• Carbon — digital bank plus credit; balances, repayment schedules, credit-score data per user.

Questions integrators ask

Does Zap give you anything the user's individual banks don't already?

Yes — three things. The rolled-up balance view across whatever banks the user has linked through NIBSS, the auto-categorisation laid over the merged transaction feed, and the Paystack-checkout merchant reference when the user paid a Paystack-powered business. None of those live inside any one bank's portal. Pull the per-bank ledger from each bank for completeness; pull Zap for the consolidated and tagged view.

What is the consent model when the data sits behind linked banks?

Two layers. For the user's own Zap data we capture an NDPA-aligned consent record at the start of the engagement, scoped to what the buyer actually needs, with revocation honoured against the same record. For each underlying bank, the durable route is the CBN Open Banking framework: explicit, revocable consumer consent under the March 2023 Operational Guidelines, with a Service Level Agreement between the API Provider and the API Consumer. The paperwork is handled on our side either way.

Do you need a Tier-3 Zap account to build against?

No. A consenting account at any of the three KYC tiers exposes the same surfaces; the tier only changes transaction caps — ₦50,000, ₦200,000 and ₦5,000,000 daily per Zap's own support docs. For test coverage we usually run a Tier-1 and a Tier-2 fixture so the eligibility logic in the integration is exercised before the buyer ever hits production volume.

Is the Paystack merchant API part of this build?

Only the consumer side that is reachable through Zap itself. The merchant Paystack API — charges, customers, dashboards — is a separate integration on Paystack's documented developer surface and a different engagement. Where a buyer needs both at once, for example reconciling a Paystack-powered merchant against Zap-originated payments, we scope them together.

What we checked

This brief was put together against Paystack's own launch announcement for Zap, the Zap support article on account tiers and limits, the CBN Operational Guidelines for Open Banking, and NIBSS's Direct Debit page — cross-checked against the in-app description and the Play Store listing. Where a specific endpoint or field is mentioned above it is described as illustrative of the surface, not verbatim — actual paths and field names are confirmed during the build against a consenting test account.

• Paystack — Introducing Zap by Paystack (launch post)
• Zap support — Account Types and Tiers Explained
• CBN — Operational Guidelines for Open Banking in Nigeria (2023)
• NIBSS — Direct Debit (NDD)