It depends on where your consumers are. New York’s Banking Law Article 14-B and Illinois’s SB 3561 both require licensing for BNPL lenders as of 2026, with Illinois giving providers until January 1, 2028 to comply. Other states currently have no BNPL-specific licensing requirement, though several are drafting one, so your platform needs a jurisdiction-configuration layer rather than a single hardcoded ruleset.

The CFPB’s 2024 attempt to regulate BNPL like a credit card under Regulation Z was rescinded in 2025 because BNPL is structured as closed-end installment credit, not revolving credit. States are now writing bespoke rules instead — New York’s, for example, caps interest at 16% and mandates specific data-privacy protections that don’t map directly onto existing credit card law.

Pay-in-four is typically interest-free and settled within six weeks, which is why it avoided being treated as a “credit card” federally. Longer installment plans (three, six, or twelve months) usually carry interest and fall under different, often stricter, state lending statutes — your platform needs separate compliance logic for each product type.

Yes, if the underwriting logic, disclosure copy, and fee caps are built as configurable modules rather than hardcoded values. This is the architectural decision that determines whether expanding to a new state takes two weeks or a rebuild.

Some products do, some don’t, and that choice has to be disclosed clearly New York’s proposed rule specifically requires lenders to state whether a loan will be reported. Reporting affects both consumer trust and your own default-tracking data quality.

Your platform needs a dispute workflow modeled on Regulation Z’s billing-error categories even where not strictly mandated — that can pause collections, investigate with the merchant, and resolve within a defined window. Merchants increasingly expect this before they’ll integrate.

Primarily through merchant discount fees (a percentage the merchant pays per transaction, similar to a card processing fee) and, secondarily, through late fees on interest-free products or interest on longer installment plans — we break this down transaction by transaction in how money lending apps make money.

Underestimating the ledger complexity. A lending product needs a double-entry, auditable ledger tracking merchant payables, consumer receivables, and fee accruals separately — bolting this onto a generic payments database after the fact causes reconciliation errors that are painful to unwind.

Both, typically. Bureau data alone excludes thin-file consumers who may be perfectly creditworthy; alternative data (bank transaction history, for instance) helps assess repayment capacity for consumers without deep credit histories, but adds cost and integration complexity.

A licensed-market-ready MVP - underwriting engine, checkout SDK, ledger, and one jurisdiction’s disclosure set — typically takes longer than a standard fintech MVP because the compliance validation step can’t be skipped or shortened. Expect the underwriting and ledger design phase alone to take as long as the entire consumer-facing build; for a fuller line-item breakdown, see our guide on the cost to develop a BNPL app (the timeline and cost drivers track closely with what we see on a cost to develop a loan lending app engagement).

Yes, most platforms are built with checkout SDKs or plugins for major e-commerce platforms alongside a hosted checkout option for merchants without in-house engineering resources.

A merchant feature is embedded checkout financing where you carry the credit risk directly. A standalone platform can license the underwriting engine to other merchants while a bank partner holds the loans this changes your capital requirements and licensing obligations significantly.

Through device fingerprinting, identity verification against multiple data sources, and internal repayment-history checks that flag applicants who’ve defaulted on a previous loan under a different but related identity — first-party default, not stolen-identity fraud, is the dominant loss pattern in pay-in-four books.

Only if you plan to operate in the UK. The FCA is bringing BNPL fully under its consumer credit regime in 2026, requiring affordability checks and clearer disclosures — a useful preview of where US federal or multi-state regulation may eventually land.

Two recurring workstreams dominate: updating disclosure language as state rules finalize or change, and retraining the underwriting model as real repayment data accumulates, since a model calibrated on thin pre-launch data will drift within a few quarters.

For a small merchant testing demand, a third-party BNPL provider’s plugin (Klarna, Affirm, etc.) is often the faster starting point. Custom development makes sense once you want to own the underwriting data, avoid per-transaction fees to a third-party lender, or serve a niche vertical those providers don’t prioritize.

The platform, not the merchant, typically absorbs the credit loss the merchant is paid in full upfront (minus the discount fee), and the receivable risk sits with whoever holds the loan, which is why the ledger has to cleanly separate merchant payables from consumer receivables from day one.