Scaling a Lease-Focused BNPL Platform from 15 Integrations to 300+ Retailers, and Extending It In-Store

That model worked at five to seven retailers and broke as the network grew. Retailers ran different combinations of Shopify, Magento, BigCommerce and custom platforms, different checkouts, different payment processors, and different sandbox and release procedures, so every integration became its own permanent implementation and support lifecycle. Any retailer platform upgrade or checkout change could force the client to rebuild the integration, redo regression testing and schedule a fresh joint release. After roughly six months the program supported around 15 retailers with 60 to 70 people, and the plan was 200+ retailers the following year: a linear extension implied hundreds, potentially close to a thousand, people. The real problem was not development capacity. The architecture made every new retailer a new external dependency, so the client needed a model where retailer growth no longer required proportional growth in engineering and support.

The constraints were concrete. Eliminate retailer-side implementation dependency: no retailer should have to add a payment method, provide sandbox access, change its checkout, expose custom APIs, assign developers or run joint QA. Support product-level eligibility, since a retailer could sell both leasable and non-leasable items, so the system classified individual cart items rather than whole retailers, and handled mixed carts by financing only the eligible portion. Work across different retailer technologies and manage DOM changes, because the extension still read retailer pages and page updates could shift HTML structure, selectors, product cards, prices and checkout fields. Maintain acceptable classification accuracy, generally 85 to 90 percent with a target above 90 and improving toward 95. Protect customer information (name, address, mobile number, SSN and OTP) with encryption, tokenization, access controls and audit logging. And later, support physical retail without integrating into each store's point-of-sale system.

Online, the Chrome extension identified the retailer, told the customer financing was available, read the cart and total, sent product details to the backend, classified each item as leasable or non-leasable, excluded ineligible items, checked the eligible amount against the customer's limit, supported registration and verification, presented the agreement, generated a single-use or limited-use virtual card, and autofilled it into the retailer's standard checkout. Enabling a new retailer became an internally managed process rather than a six-month bilateral integration: collect the retailer's public catalog data, label products leasable or non-leasable per the client's policy, train or update the classifier on thousands of records, validate accuracy against known labels, configure DOM extraction for product name, price, quantity, category and cart total, test the end-to-end flow, then activate the retailer, no sandbox, checkout change or gateway deploy required.

In store, we extended the same capability into the mobile app. The app detected the customer was inside a store's geofence; at the billing counter the customer photographed the itemized bill; OCR extracted product names, quantities and prices; the line items were normalized and passed to the same eligibility model; the app split eligible from ineligible items so non-leasable products could be paid separately; the eligible total was checked against the limit; the customer accepted the agreement; a virtual card was generated for the eligible amount and used through the store's normal card-acceptance process. If the customer left the geofence before using the card, it expired automatically. Geofencing did not process the transaction, it acted as a trigger for the backend to change the card's lifecycle status.

The architecture changed the unit of expansion. Where each retailer previously required a commercial agreement, retailer technical resources, sandbox access, payment integration, joint QA, a coordinated release and ongoing platform support, a new online retailer now primarily requires product-data preparation, labeling, model training or validation, DOM configuration, checkout testing and extension activation. A new physical retailer primarily requires store-location configuration, product-data coverage, receipt-format validation, OCR testing, eligibility testing and card-acceptance validation. Security spans encryption, tokenization, restricted access, audit logging, OTP verification, real-time SSN validation, controlled agreement execution, single-use or limited-use cards, location-triggered expiration and the PCI DSS-compliant provider. Reliability is monitored per surface: DOM breakage online (missing products, invalid selectors, autofill failures), OCR variability in store (poor lighting, blur, folds, abbreviations, tax and discount lines), geofence limits (denied permissions, indoor accuracy, GPS drift, delayed exit events, OS background limits), and virtual-card outcomes (issuance failures, provider timeouts, activation, expiration, authorization). The trade-offs are explicit: retailer independence still depends on the retailer's DOM; POS independence depends on receipt quality; one shared model spans two very different input types; location control is bounded by location accuracy; and the external card provider lowers infrastructure burden while adding vendor dependency.