BNPL Isn't a Feature — It's a Different Animal

BNPL Isn't a Feature — It's a Different Animal

The first time a bank asked us to "add BNPL" to their existing credit card stack, my instinct was to nod. By the third such conversation I had stopped nodding. BNPL isn't a feature flag on a credit card. It's a different product, with different unit economics, a different risk surface, and — most importantly — a different customer.

The product looks the same. The economics don't.

Consumer credit cards make money on interchange and revolving balances. BNPL makes money on merchant discount rates, and only sometimes on consumer fees. The risk model on a card is built for a 30-day cycle and a credit bureau footprint; the risk model on a BNPL transaction has to clear in milliseconds, often without a bureau pull.

If you try to fit BNPL onto a card platform without rethinking these primitives, you end up with a product that *technically* works and *commercially* doesn't. The bank wonders why approval rates are low; the merchant wonders why the consumer keeps dropping at checkout.

The right primitives, surfaced once

What worked for us was treating BNPL not as a feature on the card platform but as a sibling construct — a separate product type that shared the same ledger, dispute system, and reporting surface but had its own decisioning, repayment, and merchant-onboarding flow.

This sounds obvious in retrospect. It isn't. The pull, when you're sitting on a working card platform, is to extend it one more inch. The discipline is to recognise when an inch becomes a mile.

Three things I now check before scoping any BNPL build

- Who pays? Merchant-funded, consumer-funded, or hybrid? This single question rewrites the entire economics model. - What's the underwriting clock? If approval has to clear in under 500ms, your decisioning architecture is fundamentally different from a card application. - What does default look like? BNPL defaults are smaller, more frequent, and reach the bureau differently. Your collections workflow has to follow.

The boring conclusion

The most useful thing I can tell you about BNPL is that it punishes laziness. The customer-facing experience is deceptively simple — three taps and the consumer has split a payment. Behind that simplicity is a stack that has to clear faster, decision smaller amounts, and recover differently than a card has ever had to.

If your roadmap calls BNPL a feature, push back. Call it what it is: a product. Then build it like one.