Why BNPL has a different attack surface than traditional lending

A traditional digital lender disburses to a bank account. The money goes to the borrower, and repayment is tracked by bank reference. A BNPL platform disburses to a merchant on behalf of a customer. This triangular relationship between customer, merchant, and platform creates attack surfaces that do not exist in direct lending: the merchant integration point, the checkout flow authorization, and the credit-to-merchant settlement timing all introduce new exploit paths.

BNPL also tends to have lighter KYC than a full lending product, by design. Lower friction KYC enables faster checkout. But lower friction KYC also enables synthetic identity fraud at scale, because the identity verification threshold is lower and the window between approval and disbursement to the merchant is shorter than the time it takes most fraud detection systems to flag a synthetic account.

1. Instalment amount and repayment schedule manipulation

The BNPL checkout flow typically presents the customer with a purchase amount split into instalments (e.g., four monthly payments of five thousand naira each for a twenty thousand naira item). We intercept the checkout confirmation request and test whether the instalment amount, total purchase amount, and payment schedule are accepted as client-submitted parameters or enforced entirely server-side.

If any of these values can be modified in transit, an attacker can purchase a twenty thousand naira item and commit to repaying only five hundred naira per month — receiving the full merchant payment from the BNPL platform while the platform's cash flow model collapses because collections are a fraction of disbursements.

2. Credit limit bypass through multiple concurrent applications

Most BNPL platforms enforce a per-customer credit limit. We test whether this limit is enforced with a server-side lock at the application stage or whether it is only checked at the point of approval for a single application. If a user can submit multiple applications simultaneously before any single application is processed and the credit limit checked, they can receive approval for multiples of their intended credit limit in parallel.

This is a direct analogue of the wallet race condition, but applied to credit underwriting. The fix is a SELECT FOR UPDATE lock on the customer's credit record at the application stage, preventing concurrent applications from bypassing the limit check.

3. Merchant webhook manipulation and early settlement

BNPL platforms notify merchants of successful BNPL approvals through a webhook or callback. The merchant's system listens for this notification before releasing the order. We test whether the merchant-facing webhook can be replayed to trigger a second order release for the same BNPL approval reference, whether the webhook signature validation is implemented correctly (the same pattern we test on payment gateway webhooks), and whether the order release is idempotent — processing the same approval reference twice should release the order exactly once.

4. Synthetic identity and KYC threshold exploitation

We document the exact KYC data points required for BNPL approval on the platform and test the verification logic. The specific things we look for: NIN-only verification without liveness check (a real NIN can be used with a different face), BVN verification that validates the number but does not cross-check the name against the device's registered owner, and address verification that accepts self-reported addresses without cross-referencing against utility bill data or NIMC records.

5. Repayment evasion via account deactivation timing

We test what happens to outstanding BNPL balances when a user requests account deletion or deactivation. A platform that allows account deletion without first settling outstanding BNPL balances, or that stops sending repayment reminders when an account is marked for deletion, has a mechanism by which a customer can evade collection by triggering a deletion request immediately after receiving the goods from the merchant.

Real finding from a BNPL engagement

Concurrent application submission bypassing per-customer credit limit

During a penetration test of a Nigerian BNPL platform, we submitted 12 simultaneous loan applications from the same authenticated user session using a parallel request tool. The credit limit check ran for each application independently before any application had been approved and the limit reduced. All 12 applications received preliminary approval responses. When we completed the checkout flow on four of them, the platform disbursed to the merchant for all four, leaving the customer with four times their intended credit limit outstanding. Fix priority: critical. Remediated by adding a database row lock on the customer credit record at the application intake stage, allowing only one application to be evaluated at a time per customer.

Operating a BNPL platform in Nigeria? Book a security assessment that covers both the API vulnerabilities and the fraud patterns specific to buy now pay later.

Book a BNPL Pentest

Frequently asked questions

What is the biggest fraud vector unique to BNPL platforms in Nigeria?

Synthetic identity fraud combined with merchant collusion. An attacker creates a KYC-passing identity using a real NIN with modified supporting documents, uses the BNPL credit to purchase high-value electronics from a colluding merchant, and the merchant immediately refunds the cash while keeping the BNPL platform holding the credit risk. The attacker never makes a repayment.

How does instalment amount manipulation work?

If the BNPL checkout flow sends the purchase amount and instalment schedule to the backend as client-submitted parameters, an attacker can modify the per-instalment amount downward while keeping the total order value the same. The merchant receives full payment from the BNPL platform, but the platform collects less from the customer per month than the credit actually costs.

Do BNPL platforms need a CBN licence?

Yes. CBN's regulatory framework for BNPL in Nigeria requires operators to hold either a Finance Company licence or a Money Lender licence depending on their model. CBN has also issued consumer protection guidelines for BNPL that include data security obligations and dispute resolution requirements.

Related reading

Blog: Loan disbursement API logic flaws · Business logic flaws in Nigerian platforms · KYC and BVN data security

Services: Penetration testing · API security