Imagine you are standing at the checkout page of an online marketplace. You have three items in your cart worth twelve thousand rupees. You do not want to pay the full amount today. You want to pay it in four parts over the next six weeks, and you want an answer about whether you are allowed to do this within two or three seconds, without leaving the checkout page, without filling a ten-page loan form and without waiting a day for approval.

That single moment — the instant between clicking “Pay Later” and seeing “Approved” — is one of the hardest problems in modern e-commerce engineering. It looks simple from the outside. Underneath, it involves identity verification, credit risk scoring, fraud detection, regulatory compliance, ledger accounting and payment orchestration, all of which must complete in well under three seconds, at a scale of thousands of requests per second during a flash sale, without ever losing a single rupee of money or approving a loan the business cannot afford to give.

This tutorial is a complete system design walkthrough of a Buy Now, Pay Later (BNPL) platform that plugs into a marketplace’s checkout flow. We will build the system piece by piece, starting from the business problem, moving through architecture, internal working of the credit engine, data flow, scaling strategy, security and finishing with real production examples from companies that have actually built this.

1.1 A short history of “buy now, pay later”

Instalment buying is not a new idea. Long before the internet existed, furniture stores and department stores let customers take goods home and pay in monthly instalments, tracked on paper ledgers by a shop clerk. The idea was always the same: let the customer enjoy the product now and collect the money later, in parts, usually with the retailer absorbing the risk of non-payment or partnering with a finance company that did.

What changed with the rise of e-commerce in the 2010s was not the concept but the speed. In a physical store, a clerk could take fifteen minutes to fill in a paper credit application and call a finance office for approval. Online, a customer will not wait fifteen minutes, or even fifteen seconds. If a checkout page does not respond in a couple of seconds, a large share of customers abandon the cart entirely. This forced fintech companies such as Klarna (founded 2005 in Sweden), Afterpay (founded 2014 in Australia), Affirm (founded 2012 in the United States) and later many Indian players, to reinvent instalment lending as a real-time, API-driven, software problem rather than a paperwork problem.

The core engineering innovation was not the loan product itself — it was building a credit decisioning system fast enough to sit inside a checkout flow without the customer noticing it is even there. That is exactly what we are going to design in this tutorial.

Before drawing any boxes and arrows, we need to be precise about what problem we are solving. A vague requirement like “build BNPL” leads to a vague, wrong architecture. Let us break the requirement into the actual engineering problems hiding inside it.

2.1 The functional requirements

• Real-time eligibility check. At checkout, the customer sees a “Pay in 4” or “Pay in 3 months” option only if they are pre-qualified or can be qualified instantly.
• Instant credit decision. When the customer picks BNPL and confirms, the system must return approve, decline or “needs more info” within roughly 1 to 3 seconds.
• Dynamic credit limit and plan generation. The system decides how much this customer can borrow right now, and what repayment plan (for example, four instalments every two weeks, or three monthly instalments) fits both the order value and the customer’s risk profile.
• Fraud and identity checks. The system must detect stolen identities, synthetic identities and account takeover attempts, all inside the same time budget.
• Order and payment orchestration. Once approved, the marketplace order must be confirmed, the merchant must be paid immediately (BNPL providers usually pay the merchant in full upfront and take on the collection risk themselves) and an instalment schedule must be created for the customer.
• Servicing over time. After checkout, the system must charge instalments automatically, send reminders, handle failed payments, apply late fees where allowed by regulation and handle customer support and disputes.
• Regulatory compliance. Depending on jurisdiction, this may require credit bureau reporting, mandatory disclosures, interest rate caps and data protection compliance (in India, this includes the Digital Personal Data Protection Act, 2023 and RBI’s digital lending guidelines).

2.2 The non-functional requirements — where the real difficulty lives

2.3 The integration constraint: BNPL is a guest inside someone else’s house

One requirement is easy to overlook and deserves its own callout: the BNPL platform is not building its own storefront. It is embedding itself inside a marketplace’s existing checkout flow, which the marketplace owns, controls and has already optimised heavily for conversion. This shapes the architecture in several concrete ways. First, the public API surface exposed to the marketplace must be extremely stable and backward-compatible, because the marketplace’s engineering team will integrate it once and may not revisit that integration code for a long time — a breaking API change can silently degrade checkout for every one of that marketplace’s customers. Second, the BNPL platform must assume very little about how the marketplace’s checkout page is built; it cannot dictate the marketplace’s technology stack, so the integration typically happens through a well-documented REST API plus a lightweight, embeddable UI widget rather than requiring deep code changes on the marketplace’s side. Third, and perhaps most importantly, the BNPL platform must degrade gracefully from the marketplace’s point of view: if the BNPL service is slow or down, the marketplace’s checkout page must still let customers complete their purchase using other payment methods, meaning the checkout page’s own code needs a sensible timeout and fallback around the BNPL widget, and the BNPL platform’s public API needs to fail fast and predictably rather than hanging.

2.4 Who are the actors in this system?

• The customer — wants a fast yes / no and a repayment plan they understand.
• The marketplace — wants BNPL to increase conversion and average order value, and wants zero engineering burden of running a lending business itself.
• The BNPL provider (our system) — wants to lend profitably: approve good borrowers, decline risky ones and collect repayments reliably.
• The credit bureau — an external agency (like CIBIL, Experian or Equifax in India) holding the customer’s credit history.
• The regulator — cares that lending is fair, disclosed properly and that customer data is protected.
• The merchant’s bank / payment rails — moves the actual money for merchant payouts and instalment collections.

Before the architecture, let us define every term precisely. If any of these are new to you, read this section slowly — the rest of the tutorial builds directly on top of these definitions.

3.1 What is Buy Now, Pay Later (BNPL)?

BNPL is a short-term financing product that lets a customer receive a product or service immediately while paying its cost in a small number of scheduled instalments, usually over weeks or a few months, often at zero or low interest if paid on time. Structurally, it is a short-term, point-of-sale consumer loan, but it is marketed and experienced as a checkout payment method rather than as a loan application.

3.2 Credit decisioning

Credit decisioning is the process of deciding whether to extend credit (lend money) to a specific person for a specific amount, and if so, on what terms. It answers three questions: should we lend at all, how much should we lend and what repayment terms should we offer. In a traditional bank, this might take days and involve a human underwriter. In BNPL, it must happen in seconds, so most of the decision is made by automated rules and machine learning models, with only a small fraction of edge cases routed to a human review queue.

3.3 Soft pull vs hard pull (credit bureau inquiry)

A hard pull is a full credit bureau inquiry that can slightly lower a customer’s credit score and is visible to other lenders. A soft pull retrieves similar bureau data but does not affect the customer’s score and is not visible to other lenders. BNPL systems almost always use soft pulls at the point of checkout, because a hard pull would both hurt the customer’s score for a small purchase and would be too slow, since some hard-pull processes involve manual steps.

3.4 Risk score and credit limit

A risk score is a numeric estimate (for example, 0 to 999) of how likely a borrower is to repay on time. A credit limit is the maximum amount the system is willing to lend this specific customer at this point in time, which can change order to order based on the customer’s evolving risk profile, repayment history with this provider and current exposure (how much they already owe).

3.5 Underwriting

Underwriting is the overall process of evaluating risk and deciding loan terms. In BNPL, “automated underwriting” refers to software (rules plus machine learning) doing this job instead of a human, within the decisioning engine.

3.6 Merchant settlement

This is the process of the BNPL provider paying the marketplace the full order value (minus a small merchant discount fee, often 2 to 6 percent) right after the order is approved, so the marketplace gets paid immediately and takes on none of the instalment-collection risk. The BNPL provider now owns the receivable — the right to collect money from the customer over time — and the risk that the customer might not pay.

3.7 Instalment schedule / repayment plan

This is the concrete schedule of amounts and due dates the customer agreed to, generated at the moment of approval, for example: ₹5,000 today (sometimes the first instalment is charged immediately), ₹5,000 on day 14, ₹5,000 on day 28, ₹5,000 on day 42.

3.8 Idempotency

Idempotency means that performing the same operation multiple times produces the same result as performing it once. This matters enormously in BNPL because network retries, double-clicks and distributed system failures are common, and you never want to accidentally approve the same loan twice or charge a customer’s card twice for the same instalment.

3.9 Circuit breaker (used heavily against the credit bureau)

A circuit breaker is a software pattern that stops calling a failing downstream dependency for a short period, instead of retrying it repeatedly and making things worse. If the credit bureau’s API starts timing out, a circuit breaker “trips open” and the system quickly falls back to a cached score or a conservative decision rather than waiting on every request and causing a cascading slowdown across the whole checkout flow.

3.10 Saga pattern

A saga is a way of managing a business transaction that spans multiple services (checkout, credit decision, ledger, merchant payout) without a single traditional database transaction. Each step publishes an event; if a later step fails, compensating actions undo the earlier steps. We will use this to keep the loan-approval and merchant-payout flow consistent even though it touches several independent services.

Now we build the system. We will design it as a set of independently deployable microservices sitting behind an API gateway, integrated into the marketplace’s checkout as a plugin-like subsystem. Every box below is a real, separately deployable unit with its own responsibility, its own data and its own scaling profile.

4.1 Component-by-component breakdown

1. CDN (Content Delivery Network)

Serves the static checkout widget (the “Pay in 4” button, plan-selection UI, disclosure text) from edge locations close to the customer, so the BNPL option renders instantly on the marketplace’s checkout page instead of waiting on a distant origin server.

2. WAF (Web Application Firewall)

Sits in front of the API Gateway and filters out common attacks (SQL injection attempts, bot traffic, credential-stuffing patterns) before they ever reach application code. This is the first line of defence for a system that will be a constant target, because it moves money.

3. API Gateway

The single entry point for all external traffic hitting the BNPL platform. It is responsible for authenticating the marketplace’s server-to-server calls (using signed API keys or mTLS), authenticating the end customer’s session token, applying per-merchant and per-customer rate limits, request validation and routing each request to the correct internal service. It also strips out internal implementation details from responses, so the marketplace only ever sees a clean, versioned public API.

4. Load Balancer

Distributes incoming requests across many running instances of each backend service. We use a Layer 7 (application-aware) load balancer so it can route based on the URL path (for example, routing /credit/decision traffic differently from /instalments/schedule traffic) and perform active health checks, automatically pulling unhealthy instances out of rotation. In our diagram, the load balancer sits both at the edge (in front of the Checkout Integration Service) and internally, in front of each critical microservice cluster, though only one is drawn for clarity.

5. Checkout Integration Service

The “front door” of the BNPL business logic. This is the service the marketplace’s checkout page actually talks to. It exposes a small, stable public API (“check eligibility”, “apply for BNPL”, “confirm plan”) and hides all the internal complexity of orchestration, credit decisioning and ledger updates behind it. This isolation is deliberate: the marketplace should never need to know that fraud checks or credit bureau calls exist behind the scenes.

6. BNPL Orchestrator Service

The coordinator. When a customer applies for BNPL, the orchestrator runs the multi-step saga: call the fraud service, call the credit decision engine, generate the instalment plan, trigger merchant settlement and publish events for downstream services (notifications, analytics). This is where the saga pattern discussed earlier physically lives.

7. Credit Decision Engine

The brain of the system, covered in complete depth in Section 6. It combines rules, a machine learning risk model, bureau data and the customer’s own history with this provider to produce an approve / decline decision, a credit limit and a recommended repayment plan, in well under a second of actual compute time.

8. Fraud and Identity Service

Runs in parallel with the credit decision engine (not after it, to save time) and checks device fingerprint, IP reputation, velocity of applications (how many BNPL applications has this device or card tried in the last hour) and identity document verification signals. A “high fraud risk” result can override even a good credit score and force an automatic decline or manual review.

9. Ledger and Accounting Service

The system of record for money. Every approval, merchant payout, instalment charge, refund, late fee and write-off is recorded here as an immutable, double-entry accounting entry. This service is intentionally boring, slow-changing and heavily tested, because correctness here is non-negotiable — more on this in Section 14.

10. Instalment Scheduler Service

Generates the repayment schedule at approval time and manages recurring background jobs that trigger each instalment charge on its due date, including retry logic for failed payments and escalation to reminders or late fees.

11. Payment Execution Service

Talks to external bank rails, card networks or UPI systems (in the Indian context) to actually move money: paying the merchant upfront, and later collecting each instalment from the customer’s saved payment method.

12. Notification Service

Consumes events from the event bus and sends SMS, push notifications or email — approval confirmations, upcoming instalment reminders, payment failure alerts — without the orchestrator needing to know anything about notification channels.

13. Customer Support / Dispute Service

Gives support agents a read-optimised view of a customer’s loans, payment history and decision explanations, and lets them trigger safe, audited actions like payment date changes or refund initiation.

14. Feature Store

A low-latency key-value store holding pre-computed features (such as “number of BNPL applications in the last 30 days”, “average order value”, “on-time repayment rate”) that the machine learning risk model needs. Pre-computing these ahead of time is what allows the credit decision engine to respond in milliseconds instead of running expensive aggregation queries on the fly.

15. Event Bus (Kafka)

Decouples services from each other. When the orchestrator finishes a decision, it publishes an event once; the notification service, the analytics warehouse and the fraud-model training pipeline all consume that same event independently, without the orchestrator needing to know they exist.

Let us trace exactly what happens, step by step, between the moment a customer taps “Pay in 4” and the moment they see “Approved” on screen. Understanding this sequence is essential — it is the backbone the rest of the design hangs off.

5.1 Step-by-step explanation

1. Customer selects BNPL. The checkout UI, loaded from the CDN, shows a “Pay in 4” option only after a lightweight, pre-computed eligibility flag was already fetched when the cart page loaded (more on this “pre-qualification” trick in Section 9).
2. Request hits the API Gateway with an idempotency key. The checkout UI generates a unique key (usually a UUID) for this specific application attempt and sends it in the request header. If the network glitches and the UI retries the same request, the backend recognises the duplicate key and returns the original result instead of creating a second loan application.
3. The Checkout Service authenticates and forwards to the Orchestrator. This is a thin translation layer — it converts the marketplace’s request format into the BNPL platform’s internal application format.
4. The Orchestrator fans out to Fraud and Credit checks in parallel, not sequentially. This is one of the most important latency optimisations in the whole design. If fraud checking takes 400 milliseconds and credit decisioning takes 600 milliseconds, running them one after another costs 1000 milliseconds; running them in parallel costs only 600 milliseconds — the time of the slower one.
5. The Credit Decision Engine calls the credit bureau (with a strict timeout and circuit breaker) and combines that with internal features to make a decision, described fully in Section 6.
6. The Orchestrator combines both results. A poor fraud verdict can override an otherwise good credit decision. This combination logic is itself a small rules engine.
7. On approval, three things must happen together, reliably: record the loan in the ledger, generate the instalment schedule and trigger the merchant payout. Because these touch three different services, they are coordinated using a saga (Section 16) rather than a single database transaction.
8. The customer sees the result — approved with a clear plan, declined with an alternative payment option, or “pending” if routed to manual review (a small percentage of borderline applications).

5.2 A worked latency budget

It helps to see actual numbers rather than only the general principle. A realistic latency budget for the full application flow, targeting a 2.5 second total, might look like this: network round trip from customer to API Gateway and back, roughly 150 milliseconds; API Gateway authentication and routing, roughly 20 milliseconds; Checkout Service translation and forwarding, roughly 10 milliseconds; the parallel fraud and credit check stage, bounded by whichever is slower — typically the credit engine at up to 1200 milliseconds including the bureau call, with the fraud service comfortably finishing within that same window; combining the two results and running the policy engine, roughly 30 milliseconds; the saga’s ledger write, schedule generation and payout trigger, roughly 400 milliseconds combined since these can also partly overlap; and a final buffer of a few hundred milliseconds for response serialisation and the return trip to the customer’s browser. Laying the budget out this explicitly, component by component, is what allows an engineering team to know in advance exactly which piece to optimise when the total starts creeping past target, rather than guessing during an incident.

This is the component that makes BNPL different from a generic payments feature, so it deserves its own detailed section. The credit decision engine’s job is to turn a pile of signals — bureau data, internal history, order details, device signals — into three outputs: a decision (approve, decline or review), a maximum amount to lend right now and a suggested repayment plan.

6.1 Layer 1: Hard rules (deterministic, non-negotiable)

Before any machine learning model runs, a simple rules layer eliminates obviously unacceptable applications instantly and cheaply. This layer exists for two reasons: it is much faster than running a full model, and some decisions must be deterministic and explainable for regulatory reasons (for example, “customer is under 18” must always decline, with no room for a model to disagree).

Typical hard rules include: applicant’s age below the legal minimum, applicant already has an overdue instalment with this provider, requested order amount exceeds the provider’s absolute maximum exposure per customer, applicant’s device or card is on an internal blocklist, or the applicant’s KYC (identity verification) has failed.

6.2 Layer 2: The machine learning risk model

Applications that pass the hard rules go to a risk model — typically a gradient-boosted decision tree model (such as XGBoost or LightGBM) rather than a deep neural network, because in lending, regulators and internal risk teams usually require model outputs to be explainable feature-by-feature, and tree-based models are far easier to explain than deep learning black boxes.

The model consumes features from several sources:

• Bureau features: existing debt, past delinquencies, credit utilisation, length of credit history.
• Internal history features: this customer’s on-time repayment rate with this specific BNPL provider, number of active loans, total current exposure.
• Order features: order amount, product category (electronics carry different risk than groceries), merchant category.
• Behavioural features: time of day, device type, how long the customer has had this marketplace account, delivery address stability.

The model outputs a probability of default — the estimated likelihood the customer will fail to repay — which is then converted into a risk score (commonly scaled to a 0–999 range for readability by risk analysts and support agents).

6.3 Layer 3: Limit and plan calculation

The risk score alone is not a decision. A separate policy layer converts score plus order amount into an actual credit limit and, if approved, a specific instalment plan. This layer encodes business policy (for example, “customers with a score above 800 can borrow up to ₹50,000 across all active plans; customers scoring 650–800 are capped at ₹15,000”) and can be changed by risk analysts without retraining the machine learning model, because policy tends to change more often (e.g., tightening limits before a recession) than the underlying risk signal does.

6.4 Layer 4: Manual review queue for the middle band

Applications with scores in an ambiguous middle range are not auto-approved or auto-declined; they are placed in a queue for a human risk analyst, along with the model’s explanation, and a decision is returned to the customer within minutes (not seconds) via notification, rather than instantly. This band is deliberately kept small — usually under five percent of applications — because manual review breaks the real-time promise.

6.5 A simplified Java sketch of the decision orchestration

public class CreditDecisionEngine {

    private final RulesEngine rulesEngine;
    private final RiskModelClient riskModel;
    private final PolicyEngine policyEngine;
    private final CreditBureauClient bureauClient;
    private final DecisionAuditLogger auditLogger;

    public CreditDecision decide(ApplicationContext ctx) {
        // Layer 1: fast, deterministic hard rules
        RuleResult ruleResult = rulesEngine.evaluate(ctx);
        if (ruleResult.isHardDecline()) {
            CreditDecision decision = CreditDecision.declined(ruleResult.getReasonCode());
            auditLogger.log(ctx, decision);
            return decision;
        }

        // Layer 2: bureau data with circuit breaker and timeout
        BureauReport bureauReport;
        try {
            bureauReport = bureauClient.softPull(ctx.getCustomerId(), Duration.ofMillis(800));
        } catch (BureauUnavailableException e) {
            // Fall back to internal-only scoring rather than failing the whole request
            bureauReport = BureauReport.unavailable();
        }

        // Layer 3: ML risk model
        double probabilityOfDefault = riskModel.score(ctx, bureauReport);
        int riskScore = ScoreConverter.toScoreBand(probabilityOfDefault);

        // Layer 4: policy engine turns score into limit and plan
        PolicyOutcome outcome = policyEngine.evaluate(riskScore, ctx.getOrderAmount());

        CreditDecision decision;
        if (outcome.isAutoApprove()) {
            decision = CreditDecision.approved(outcome.getLimit(), outcome.getPlan());
        } else if (outcome.isAutoDecline()) {
            decision = CreditDecision.declined(outcome.getReasonCode());
        } else {
            decision = CreditDecision.pendingReview(riskScore);
            reviewQueue.enqueue(ctx, riskScore);
        }

        auditLogger.log(ctx, decision); // always store, even for review/decline
        return decision;
    }
}

6.6 Algorithms and data structures used inside the engine

It helps to name the concrete algorithms and data structures doing the work inside each layer, since interviewers often want to hear this level of detail rather than a purely conceptual description of “a model runs and gives a score”.

• Hard rules layer: implemented as a short-circuiting chain-of-responsibility, where each rule is a small predicate function evaluated in a fixed, ordered list, and evaluation stops at the first triggered hard decline. Ordering matters for performance — cheap, high-hit-rate rules (like a blocklist lookup, implemented as an O(1) hash-set membership check) run before more expensive rules that might need a database round trip.
• Feature assembly: a fan-out of parallel key-value lookups against the feature store, implemented with a thread pool or asynchronous, non-blocking I/O so that fetching twenty different features does not take twenty times as long as fetching one. The results are merged into a single feature vector using a simple map structure keyed by feature name, ready to be handed to the model.
• Risk scoring model: a gradient-boosted decision tree ensemble — essentially an array of many small binary tree structures — where the final score is a weighted sum of each tree’s leaf-node output. Tree traversal for inference is extremely fast, typically well under a millisecond for a model with a few hundred trees, because each tree lookup is just a short series of simple comparisons walking down a shallow binary tree.
• Score-to-band conversion: a binary search over a small, sorted array of score-band boundaries, giving logarithmic-time lookup, though in practice the array is so small this is effectively constant time regardless.
• Idempotency key checking: a hash-based lookup backed by Redis, checking whether a given idempotency key has already been seen, with a short expiry window matching how long a client might realistically retry a failed call.
• Rate limiting at the gateway: commonly implemented with a token-bucket or sliding-window-log algorithm per API key, giving smooth, predictable rate control without the burstiness problems a naive fixed-window counter would create at window boundaries.

6.7 Concurrency considerations inside the engine

The Credit Decision Engine must comfortably handle thousands of concurrent in-flight requests without one slow request blocking others behind it. This is typically achieved with an asynchronous, event-loop-based or reactive programming model rather than one operating-system thread blocked per request, so that while one request is waiting on the credit bureau’s network response, the very same worker thread is free to keep making progress on other requests. Connection pools to the database and feature store are sized deliberately — too small and requests queue up waiting for a free connection, adding latency exactly where you can least afford it; too large and the downstream database itself becomes overwhelmed by more concurrent connections than it can efficiently serve, which can ironically make everything slower.

6.8 Networking considerations for the bureau integration

The call to the external credit bureau typically happens over a dedicated, persistent connection pool rather than opening a fresh connection per request, which would otherwise add avoidable latency from repeated network and encryption handshakes. Many BNPL providers negotiate a private network link to major bureaus for both security and slightly lower, more predictable latency compared to a call routed over the public internet. Address lookups for the bureau’s endpoint are cached aggressively as well, since even a fast lookup on the critical path is unnecessary latency that a long-lived, persistent connection avoids entirely.

A loan is not a single event; it is a lifecycle that continues for weeks after the exciting real-time moment at checkout is over. Understanding the full lifecycle matters because most of the actual engineering effort in a mature BNPL system goes into the “boring” post-approval phase, not the flashy instant-decision phase.

7.1 The full lifecycle of a BNPL loan

8.1 Advantages of this architecture

8.2 Disadvantages and honest trade-offs

8.3 Build versus buy: another honest trade-off

Almost nobody building a BNPL platform builds every component described in this article from scratch, and it is worth being explicit about which pieces are commonly bought rather than built in-house, and why. Credit bureau integration is always bought, since building a competing credit bureau is neither practical nor the point. KYC and identity verification is very often bought from a specialised vendor, since document verification and liveness detection (confirming a selfie matches a live person rather than a photo of a photo) is a deep, narrow specialty most lending teams should not try to reinvent. Card tokenisation and PCI-scope reduction, discussed in Section 11, is also very commonly outsourced to a specialised payment processor for the same reason.

What is almost always built in-house, by contrast, is the Credit Decision Engine’s policy and scoring logic itself, the Ledger Service and the Orchestrator — because these encode the lender’s actual competitive advantage and risk appetite, and outsourcing the core decisioning logic would mean outsourcing the business itself. A useful mental model for this trade-off: buy the components that are regulated, specialised utilities available from vendors who focus entirely on doing that one thing well, and build the components that directly encode your own risk judgment, your own customer relationship and your own money movement, since these are exactly the parts where owning the logic, and the ability to change it quickly, matters most.

BNPL traffic is extremely spiky. A festive sale, a flash sale or a celebrity endorsement can push traffic to ten or fifty times normal volume within minutes. Let us go through the concrete techniques that keep the system fast and correct under that kind of load.

9.1 Pre-qualification: doing work before it is urgent

Rather than computing eligibility from scratch at the exact moment of checkout, the system pre-computes a rough eligibility and tentative limit for active, returning customers during off-peak batch windows, and stores it in a fast cache (Redis). When the customer reaches checkout, the system does a lightweight “is this still valid” re-check rather than a full decision from zero. This shifts a large share of computation away from the highest-pressure moment (checkout) to a lower-pressure moment (background batch processing).

9.2 Horizontal scaling of stateless services

The Checkout Integration Service, Orchestrator, Fraud Service and Credit Decision Engine are all designed to be stateless — they read from and write to external stores (databases, caches, the feature store) rather than holding request state in memory. This means we can add more instances behind the load balancer during a traffic spike and remove them afterward, without any special coordination.

9.3 Caching strategy

• Decision cache (Redis): caches recent bureau responses for a very short time-to-live (a few minutes) so that if a customer’s app retries the same application, the system does not need a second bureau call.
• Feature store: pre-aggregated features refreshed on a schedule (for example, every few hours) rather than computed live from raw transaction history on every request.
• Pre-qualification cache: as described above, computed proactively rather than reactively.

9.4 Queueing and backpressure for the servicing side

Instalment charging jobs, notification sends and analytics events all flow through Kafka rather than being called synchronously. This means a traffic spike in “customers applying for BNPL” does not directly overload “customers being charged their instalments today”, because these are decoupled queues that each scale and get consumed independently.

9.5 Rate limiting and load shedding

The API Gateway enforces per-merchant and per-customer rate limits, and during extreme spikes, the system can gracefully degrade: for example, temporarily widening the manual-review band (sending more borderline cases to review instead of the ML model making faster but slightly less confident automatic calls) or serving a slightly more conservative default score if the feature store is under heavy read pressure, rather than failing requests outright.

Because BNPL sits inside someone else’s checkout flow, an outage here can look, to the marketplace, like their entire checkout is broken — even if only the “Pay in 4” button fails. This raises the bar for availability well above what a typical internal tool needs.

10.1 Redundancy at every layer

• Multiple Availability Zones: every stateless service and the load balancer itself run across at least two AZs, so a single data-center-level failure does not take the platform down.
• Database replication: the ledger database uses synchronous replication to an in-region replica (for fast, safe failover) and asynchronous replication to a standby in a separate region (for disaster recovery from a full regional outage).
• Circuit breakers on all external dependencies: the credit bureau, KYC provider and payment rails are all wrapped with circuit breakers and sensible fallback behaviour, so their failure degrades the system gracefully instead of taking it down entirely.

10.2 Graceful degradation, not just failover

True high availability for a credit system is not only “keep the servers up” — it is “keep making safe decisions even when a dependency is unhealthy”. Concretely: if the credit bureau is unreachable, fall back to a conservative internal-only score with a lower limit cap, rather than declining every applicant or, worse, approving without any risk check. If the fraud service times out, default to routing that application to manual review rather than silently skipping the fraud check.

10.3 Idempotent, retry-safe writes on the money-moving path

Every operation that touches money (merchant payout, instalment charge, refund) is built to be safely retryable: each carries an idempotency key, and the payment execution service checks a record of “have I already processed this exact operation” before calling out to bank rails. This is what allows the system to safely retry after a timeout instead of having to manually reconcile a double payment after the fact.

A BNPL platform sits at the intersection of two of the most sensitive categories of data: financial payment credentials and personal credit information. Security here is not a bolt-on feature; it drives several core architectural decisions.

11.1 PCI DSS scope isolation

Payment Card Industry Data Security Standard (PCI DSS) compliance is required for any system that touches raw card data. Rather than letting card numbers flow through the Orchestrator, Credit Engine or Ledger, the architecture routes any raw card capture through a dedicated, heavily restricted Payment Execution boundary (often backed by a PCI-compliant tokenisation vendor) that immediately converts the card number into a non-sensitive token. Every other service in the system — including the ledger — only ever sees this token, never the real card number. This dramatically shrinks the “PCI scope”, meaning fewer systems need the most expensive, strict compliance controls.

11.2 Encryption everywhere

• In transit: TLS 1.2 or higher for every internal and external call, including service-to-service traffic inside the private network, not just at the public edge.
• At rest: field-level encryption for particularly sensitive fields (identity document numbers, income data) in addition to full-disk or database-level encryption, so a database backup leak alone does not expose raw personal data.

11.3 Strict service-to-service authentication and least privilege

Internal services authenticate to each other using mutual TLS (mTLS) or short-lived signed tokens, not shared static API keys. Each service is granted the minimum data access it needs — for example, the Notification Service can read a customer’s phone number and loan status but has no access to the ledger’s raw accounting entries or the credit bureau report.

11.4 Fraud-specific defences

• Device fingerprinting and velocity checks: detect the same device or card attempting many applications in a short window, a classic signal of stolen-identity fraud rings.
• Synthetic identity detection: cross-checking whether the combination of name, date of birth and identity number has a plausible, coherent history, since synthetic identities often combine a real identity number with a fabricated name.
• Step-up verification: for higher-risk applications, requiring an additional identity check (such as a one-time password to a verified phone number, or a selfie-to-ID match) before finalising approval.

11.5 Data minimisation and DPDP Act compliance (Indian context)

Under India’s Digital Personal Data Protection Act, 2023, the system should collect only the personal data genuinely necessary for the credit decision, obtain clear consent for its use, allow customers to see what data is held about them and delete or anonymise data once it is no longer needed for lending, servicing or a legally required retention period. This shapes engineering decisions such as: not permanently storing full bureau reports when only the derived score is needed long-term, and building a working data-deletion pipeline rather than treating it as a manual, ad hoc process.

11.6 Auditability as a security property

Every credit decision, every access to a customer’s sensitive data by a support agent and every manual override by a risk analyst is logged immutably. This is both a fraud-detection tool (unusual access patterns by internal staff are themselves a risk signal) and a regulatory requirement (you must be able to reconstruct why a specific decision was made, months later, if a regulator or customer disputes it).

11.7 Regulatory reporting as a security-adjacent concern

In many jurisdictions, including under the Reserve Bank of India’s digital lending guidelines, a lender is required to report loan-level data to credit bureaus on a regular cadence, disclose all-in loan costs clearly to the borrower before confirmation and route the loan itself through a regulated entity (a bank or NBFC) rather than an unregulated intermediary. From an architecture standpoint, this means the Ledger Service and the Instalment Scheduler Service need to produce clean, well-structured, reconciled reporting extracts on a defined schedule, and the Checkout Integration Service’s plan-confirmation screen needs to render mandated disclosure text (total repayable amount, any interest or fees and the exact due dates) as first-class response data rather than something bolted on as static text in the frontend.

Treating regulatory reporting as a downstream, best-effort batch job is a common and costly mistake — reconciliation gaps between what the ledger says was lent and what gets reported to a bureau can trigger real regulatory scrutiny, so this reporting pipeline deserves the same monitoring rigor described in Section 12, including alerts if a scheduled reporting job fails or produces a suspicious record count compared to historical baselines.

11.8 Secrets and credential management

Database credentials, API keys for the credit bureau and KYC providers and encryption keys are never stored in application configuration files or source code. They live in a dedicated secrets manager (such as HashiCorp Vault or a managed cloud equivalent), are injected into services at runtime and are rotated on a defined schedule. Access to view or rotate these secrets is itself audited and restricted to a small number of authorised engineers, following the same least-privilege principle applied to service-to-service data access described earlier in this section.

You cannot safely run a real-time lending system without excellent observability, because both engineering failures (an outage) and business failures (the model silently approving too many risky loans) need to be caught quickly.

12.1 The three pillars: metrics, logs and traces

• Metrics: numeric time-series data such as request rate, error rate and p50/p95/p99 latency for each service, collected by an agent (commonly Prometheus) and visualised on dashboards (commonly Grafana).
• Logs: structured, centralised logs (shipped to something like the ELK stack or a managed log platform) that let engineers search for a specific request or customer’s journey across every service it touched.
• Distributed tracing: a system such as Jaeger or OpenTelemetry-based tracing that stitches together the full path of one checkout request across the API Gateway, Orchestrator, Fraud Service and Credit Engine, so a slow request can be pinpointed to the exact component causing the delay.

12.2 Business-level monitoring, not just infrastructure monitoring

Purely technical dashboards (CPU, memory, request latency) are not enough for a lending system. The platform also needs business-risk dashboards tracking: approval rate over time (a sudden jump can mean a broken rule or a mis-deployed model), default rate trending by cohort, average decision latency specifically for the credit engine step and manual review queue size (a growing queue means either fraud attacks or a miscalibrated score band).

12.3 Alerting philosophy

12.4 Model monitoring specifically

Because the risk model’s predictions directly control lending decisions, it needs its own dedicated monitoring beyond standard software metrics: tracking feature drift (are incoming applications starting to look statistically different from the data the model was trained on), and tracking realised default rates against the model’s predicted probabilities over time, to catch the model becoming miscalibrated before it causes significant financial loss.

12.5 Service level objectives and error budgets

Each critical service publishes a clear service level objective, or SLO — for example, the Credit Decision Engine might commit to a p99 latency under 3 seconds and a success rate above 99.9 percent, measured over a rolling 28-day window. The gap between 100 percent and the target success rate is the service’s error budget: a defined, deliberate allowance for imperfection that gives engineering teams room to ship changes and take calculated risks, while still holding a hard, measurable line the business can rely on. When a service is burning through its error budget faster than expected, that alone is treated as a signal to slow down risky deployments until reliability recovers, even if no single alert has fired yet.

12.6 On-call practices for a money-moving system

Because failures here can directly cost money or damage regulatory standing, the on-call rotation for the Ledger Service, Payment Execution Service and Credit Decision Engine typically carries a stricter response-time expectation than a typical internal tool would, often measured in single-digit minutes for the most severe alert tier. Runbooks exist for the most common failure scenarios (bureau outage, payment rail outage, a sudden spike in decline rate) so that an on-call engineer, even one unfamiliar with a specific incident type, has a clear, tested first set of steps to follow rather than improvising under pressure at three in the morning. Post-incident reviews are conducted for every significant incident, focusing on what the monitoring and alerting setup missed or caught late, and feeding improvements back into the dashboards and alert thresholds described earlier in this section — treating observability itself as something that continuously improves after every real-world test, rather than something configured once and left alone.

Each microservice is packaged as a container (Docker) and deployed on an orchestration platform such as Kubernetes, which handles scheduling instances across nodes, restarting failed instances automatically and scaling instance counts based on load.

13.1 CI/CD pipeline

Code changes go through an automated pipeline: unit tests, integration tests (including replaying historical loan applications through a staging credit engine to check for unexpected decision changes), a security scan of the container image and a staged rollout — first to a small percentage of production traffic (a canary release), then gradually to 100 percent, with automatic rollback if error rates or key business metrics (like approval rate) move outside expected bounds during the canary phase.

13.2 Why canary releases matter more here than in a typical web app

A bug in a typical web app might show a broken button. A bug in the credit decision engine’s deployment pipeline could silently approve loans that should have been declined, and by the time anyone notices from a dashboard, real money has already been lent out. This is why the canary phase for the credit engine specifically compares live decision outcomes (approval rate, average approved limit) between the new version and the old version in real time, not just infrastructure error rates.

13.3 Infrastructure as code

The entire cloud infrastructure — networking, database instances, Kubernetes clusters, IAM permissions — is defined as code (using a tool such as Terraform) rather than manually configured through a cloud console. This makes environments reproducible, makes changes reviewable through the same pull-request process as application code and makes disaster recovery in a new region a matter of running the same code rather than manual reconstruction.

13.4 Multi-cloud or single-cloud?

Most BNPL platforms run on a single major cloud provider (AWS, Google Cloud or Azure) using that provider’s managed services for databases, Kubernetes and message queues, because operating a genuinely active-active multi-cloud lending platform adds enormous operational complexity for limited benefit at most companies’ scale. Disaster recovery is instead handled through multi-region deployment within the same cloud provider, which is a more common and proportionate trade-off.

13.5 Cost optimisation

Real-time credit decisioning is not cheap to run at scale, and a well-designed system actively manages this cost rather than treating it as fixed overhead. Several concrete levers matter here.

• Bureau call cost management. Many credit bureaus charge per inquiry. Aggressively caching very recent responses (with a short time-to-live, as covered in Section 14) and short-circuiting on hard rules before ever reaching the bureau call meaningfully reduces the number of billable inquiries without compromising decision quality.
• Right-sizing compute for spiky traffic. Rather than provisioning enough servers for peak festive-sale traffic all year round, the platform relies on autoscaling policies tied to real-time queue depth and request rate, so baseline compute cost stays low on ordinary days and only scales up (and back down) around genuine demand spikes.
• Tiered storage for aging data. Closed loans and old application logs are moved from expensive, fast primary storage to cheaper, colder storage tiers once they are no longer needed for active servicing, while remaining accessible for the audit and regulatory retention periods discussed in Section 11.
• Model inference efficiency. Choosing a gradient-boosted tree model over a much heavier deep learning architecture, as discussed in Section 6, is itself a cost decision as much as an explainability one — tree inference is cheap enough to run on modest compute at very high request volume, whereas a large neural network might require specialised, more expensive inference hardware for comparable throughput.

13.6 Disaster recovery runbook, at a high level

Beyond the replicated infrastructure described in Section 10, the platform maintains a documented, regularly rehearsed disaster recovery runbook: clear criteria for declaring a regional disaster (not just a transient blip), a defined decision-maker and communication plan, automated scripts (not manual click-through steps) for promoting the standby region’s database to primary and a post-failover verification checklist confirming the ledger’s data integrity before resuming full traffic. Disaster recovery drills are run periodically in a controlled way, because a runbook that has never actually been executed tends to fail exactly when it matters most.

14.1 The Ledger Database — why it must be relational and strongly consistent

The ledger uses a relational database (such as PostgreSQL) with ACID transactions, not a loosely consistent NoSQL store, because financial correctness depends on properties like atomicity (a merchant payout and the corresponding loan-liability entry must both succeed or both fail together) and durability (once a payment is confirmed, it must never silently disappear). The ledger follows double-entry accounting: every transaction creates at least two balanced entries (for example, a debit to “loans receivable” and a credit to “merchant payables”), which makes many classes of bugs self-evidently detectable, because the books simply will not balance if something is wrong.

14.2 Customer profile and application data

Customer profile data, application history and decision logs are also typically stored in a relational database, since they benefit from structured queries (a support agent looking up “show me all this customer’s loans”) and from foreign-key relationships between customers, applications and loans. Older, closed-out application data is periodically archived to cheaper, colder storage.

14.3 The Feature Store — why it is a specialised, low-latency store

The feature store prioritises read latency (single-digit milliseconds) over query flexibility, so it is usually a key-value store (such as Redis or a purpose-built feature store like Feast backed by a fast database) rather than a general relational database. Features are computed in batch (or near-real-time streaming) pipelines ahead of time and simply looked up by customer ID during the actual decision, rather than computed live.

14.4 Redis caching layer

Used for the pre-qualification cache, short-lived bureau response caching and session-level rate-limiting counters. Because none of this data is the ultimate source of truth (the ledger and application database are), a cache miss or even a full cache flush is an inconvenience, not a correctness disaster — this is exactly the kind of data that belongs in a cache.

14.5 Kafka as the event backbone

Kafka retains a durable, ordered log of events (loan approved, instalment paid, instalment failed) that multiple independent consumers (notifications, analytics, model training pipelines) can read at their own pace. This decouples producers from consumers completely: the Orchestrator does not need to know or care how many downstream systems eventually read the event it published.

14.6 Read replicas and query isolation

Read-heavy workloads — support agents looking up loan history, analytics queries, the customer-facing “my payments” screen — are served from read replicas rather than the primary ledger database, so that heavy reporting queries never compete for resources with the latency-critical write path of an active credit decision or payment.

14.7 Load balancing strategy

The edge load balancer uses round-robin with active health checks for general traffic, but the Credit Decision Engine’s internal load balancer specifically uses least-connections routing, because credit decision requests have more variable processing time (a bureau call might occasionally be slow) than typical requests, and least-connections avoids sending new requests to an instance that is already backed up with slow ones.

14.8 Partitioning and sharding strategy

As the customer base and loan volume grow, the Ledger and Customer databases are typically partitioned (sharded) by customer ID, using a consistent hashing scheme so that a given customer’s data always routes to the same shard, and adding new shards as the platform grows requires moving only a small, predictable fraction of existing data rather than a full reshuffle. This keeps any single database instance’s working set small enough to fit comfortably in memory for fast reads and keeps write throughput scaling roughly linearly as more shards are added, which matters enormously once loan volume moves from thousands to millions of active customers. Cross-shard queries, such as a platform-wide analytics report, are deliberately kept out of the transactional path entirely and instead run against the separately maintained analytics warehouse, which is built specifically to aggregate across all shards efficiently, rather than forcing the transactional ledger database to serve both fast point lookups and slow, broad aggregate queries at once.

15.1 The public API surface (marketplace-facing)

The marketplace only ever talks to a small, stable, versioned REST API exposed by the Checkout Integration Service. Keeping this surface small and stable is deliberate — it means the entire internal architecture can evolve freely as long as this contract stays consistent.

POST /v1/bnpl/eligibility
  Request:  { customerId, cartValue, merchantId }
  Response: { eligible: true, tentativeLimit: 15000, plans: ["pay_in_4", "pay_in_3_months"] }

POST /v1/bnpl/apply
  Headers:  { Idempotency-Key: "b3f1-..." }
  Request:  { customerId, orderId, amount, selectedPlan, merchantId }
  Response: { status: "approved", planId: "pl_9182", instalments: [...] }
          | { status: "declined", reasonCode: "RISK_THRESHOLD" }
          | { status: "pending_review" }

GET /v1/bnpl/plans/{planId}
  Response: { status: "active", instalments: [ { dueDate, amount, status } ] }

POST /v1/bnpl/plans/{planId}/cancel
  Request:  { reason }
  Response: { status: "cancelled", refundInitiated: true }

15.2 Internal service-to-service communication

Synchronous, latency-critical calls (Orchestrator to Fraud Service, Orchestrator to Credit Engine) use gRPC rather than REST/JSON, because gRPC’s binary protocol and strongly typed contracts (via Protocol Buffers) shave meaningful milliseconds off each hop — and in a system where the entire budget is 2–3 seconds, every hop’s overhead matters. Asynchronous, non-latency-critical communication (publishing “loan approved” for notifications and analytics) uses Kafka events instead of direct service calls.

15.3 Why microservices instead of one big service, specifically for this domain

Beyond the general microservices arguments, BNPL has a domain-specific reason: the Credit Decision Engine and Ledger Service have fundamentally different change velocity and risk profiles. Risk analysts might update decision policy weekly; the ledger’s core double-entry logic might not change for a year at a time and goes through a much heavier review process. Bundling them into one deployable would force the cautious, slow-changing ledger code to be redeployed every time a fast-moving policy tweak ships, increasing the risk of an unrelated bug touching money-critical code.

16.1 Patterns used in this design

Saga pattern (choreography-based)

Used for the approval-to-payout flow. Each service performs its local step and publishes an event; the next service reacts to that event. If the merchant payout step fails after the loan was recorded in the ledger, a compensating event triggers a reversal entry in the ledger, rather than leaving the books in an inconsistent state.

Circuit breaker

Wraps every external dependency call (credit bureau, KYC provider, payment rails) so that a failing dependency degrades gracefully instead of cascading failure through the whole request chain.

CQRS (Command Query Responsibility Segregation), applied narrowly

Write-heavy operations (recording a new loan, updating a ledger entry) go through the primary ledger database, while read-heavy operations (a customer checking their payment schedule, a support agent pulling loan history) are served from a separately optimised read replica or read-model. This keeps reporting and support queries from ever slowing down the critical write path.

Strangler fig pattern (for evolving an existing checkout)

When integrating BNPL into an existing marketplace checkout that was not originally built with it in mind, new BNPL-specific endpoints are introduced alongside the existing checkout flow and gradually take over the “how does the customer pay” decision point, rather than a risky, big-bang rewrite of the entire checkout system.

Idempotent receiver

Every state-changing API accepts an idempotency key and stores a record of processed keys, so retried requests (from network glitches or a customer double-tapping a button) are safely ignored rather than creating duplicate loans or duplicate charges.

16.2 Anti-patterns to avoid

17.1 Best practices

17.2 Common mistakes

• Optimising only for approval rate. A team under pressure to grow adoption can slowly loosen rules until default rates spike months later — approval rate and default rate must always be watched together, not in isolation.
• Forgetting the “middle 90 percent” of the loan lifecycle. Teams often build an excellent instant-decision flow and a mediocre servicing/collections flow, when in practice the servicing flow generates more support tickets and more financial risk over time.
• Under-provisioning the manual review team for sale events. If application volume spikes 20x during a flash sale, the review queue can too, and a review team sized for normal days will create hours-long delays exactly when speed matters most to the business.
• Not testing the circuit breaker’s fallback path in production-like conditions. Fallback code that is never actually exercised until a real bureau outage often has its own undiscovered bugs — chaos-testing this path deliberately is worth the effort.
• Mixing PII and non-PII data in the same cache without field-level protection. A cache is often treated as “less sensitive” than the primary database, but if it holds identity or income data it deserves the same encryption and access discipline.

17.3 A note on testing strategy specific to this domain

Beyond ordinary unit and integration tests, a mature BNPL platform maintains a replay test suite: a large, anonymised set of historical real applications with known outcomes, which is run against every proposed change to the rules engine, the policy layer or the model before it ships. A change that unexpectedly flips the decision on a meaningful share of these historical cases is a strong signal to pause and investigate before deploying, even if every conventional unit test passes cleanly. This replay suite is treated as a living asset, refreshed periodically with more recent applications so it keeps reflecting current customer behaviour and current fraud patterns rather than growing stale and less representative over time. Combined with the shadow-deployment approach described earlier for model changes, this gives the team two independent, complementary safety nets — one comparing against known historical outcomes and one observing real live traffic — before any decisioning change is trusted with real money.

18.1 What these examples have in common, architecturally

• All treat speed at checkout as a first-order product requirement, not a “nice to have” performance goal.
• All separate the fast-moving decision/policy logic from the slow-moving, heavily audited ledger and accounting logic.
• All rely on a graduated trust model — small first purchases, larger limits over time, based on repayment behaviour — rather than trying to fully assess a new customer’s risk from a single data point.
• All maintain a manual review path for ambiguous cases rather than forcing every decision to be fully automated.

18.2 The “graduated trust” strategy in more depth

It is worth expanding on graduated trust, since it quietly shapes a large part of the architecture and is a favourite topic in system design interviews for lending products. A brand-new customer, by definition, has the least data available for the credit engine to work with — no repayment history with this provider, and possibly thin or no bureau history, especially for younger customers who are early in their financial lives. Rather than either rejecting all new customers outright or extending generous limits blindly, well-designed BNPL systems deliberately start new customers at a conservative limit for a small, low-risk first purchase.

Each successfully repaid loan then becomes a new feature feeding back into the next decision: the policy engine, described in Section 6, explicitly rewards a track record of on-time repayment with a higher limit and access to longer repayment plans on subsequent purchases. This creates a natural, self-reinforcing feedback loop where the system’s confidence in a given customer grows gradually and is earned through observed behaviour, rather than being assigned once at signup and left static. Architecturally, this is precisely why the internal history features described in Section 6 (on-time repayment rate, number of prior completed loans) tend to carry substantial weight in the risk model, sometimes even more than raw bureau data for customers who have an established history with the provider.

This same mechanism also functions as a natural fraud defence: a fraud ring attempting to exploit the system at scale typically cannot fake a long history of genuinely on-time repayments across real orders, so the graduated trust model tends to naturally limit the blast radius of fraud attempts to smaller amounts on new or thin-history identities, precisely the population already receiving the most conservative limits.

19.1 Frequently asked questions

Why not just always run a hard credit pull for better accuracy?

A hard pull is slower (some processes involve steps that cannot complete in a couple of seconds), it slightly lowers the customer’s credit score and it is visible to other lenders — all of which conflicts with BNPL’s core promise of a fast, low-friction, low-commitment checkout experience. Soft pulls combined with strong internal features and machine learning give “good enough” accuracy for typically small transaction amounts, at the speed the product requires.

What happens if the customer’s card fails on an instalment due date?

The Instalment Scheduler retries according to a defined policy (for example, immediately, then again in 2 days, then again in 5 days), the Notification Service sends reminders before and after each failed attempt and if all retries are exhausted, the loan moves into the delinquency workflow described in Section 7, which may involve late fees (where legally permitted) and eventually credit bureau reporting of the missed payment.

How is this different from a normal personal loan system?

The core lending mechanics are similar, but BNPL is defined by extreme latency constraints (seconds, not days), deep integration into someone else’s checkout flow rather than a standalone application, typically smaller loan amounts and shorter terms and a business model where the BNPL provider pays the merchant immediately and takes on the collection risk itself.

Why use a rules engine and an ML model together instead of just the ML model?

Hard rules give you fast, cheap, deterministic and easily explainable handling of clear-cut cases (which is often required for regulatory reasons), while the ML model handles the nuanced, harder-to-hand-code risk assessment for everything that passes the rules. Using rules first also reduces the number of applications that need the more expensive model and bureau call.

Where would this system likely fail first under extreme load?

Most commonly, the external credit bureau dependency, since it is outside your control and often was not built for the traffic spikes an e-commerce flash sale can generate — which is exactly why circuit breakers, caching and conservative fallback scoring around that specific dependency receive so much attention in this design.

How do you decide the length and number of instalments offered?

This is primarily a policy decision informed by the order amount and the customer’s risk band, encoded in the policy engine described in Section 6. Smaller, lower-risk orders might default to a simple four-instalment, six-week plan, while larger orders for lower-risk, established customers might unlock longer plans (for example, three or six monthly instalments) that carry interest, subject to the interest rate caps and disclosure requirements set by local financial regulation.

Does the marketplace or the BNPL provider own the customer relationship?

Usually the BNPL provider, since it is the legal lender and the party responsible for servicing, collections and regulatory reporting for the loan. Architecturally, this is why the Notification Service, Customer Support Service and payment-collection logic belong entirely inside the BNPL platform rather than the marketplace’s own systems — the marketplace’s involvement effectively ends once the order is placed and merchant settlement is triggered.

How does this system avoid approving the same customer for far more credit than they can handle across multiple marketplaces?

A BNPL provider operating across multiple marketplace integrations maintains its own unified view of a customer’s total active exposure across all merchants, and the policy engine checks this aggregate exposure, not just the current order, before approving a new application. This is one reason customer identity resolution (reliably recognising the same real person across different marketplace accounts) is itself a meaningful engineering problem in this domain.

Why does the manual review queue need its own service rather than living inside the Orchestrator?

Separating it out lets the review team’s tooling, workload routing and staffing evolve independently of the automated decisioning path, and lets the review queue be scaled, monitored and even temporarily widened or narrowed (as mentioned in Section 9’s discussion of graceful degradation) without touching the orchestrator’s core logic at all.

19.2 Summary

We designed a BNPL platform that plugs into a marketplace’s checkout flow and returns a credit decision in real time. The architecture separates concerns cleanly: a Checkout Integration Service as the stable public-facing boundary, an Orchestrator coordinating a saga across fraud checking, credit decisioning and ledger updates, a layered Credit Decision Engine combining fast deterministic rules with a machine learning risk model and a policy layer and a strongly consistent, double-entry Ledger Service kept deliberately isolated from faster-moving business logic. Around this core, we layered caching and pre-computation for speed, circuit breakers and graceful degradation for resilience, multi-AZ and multi-region deployment for availability, strict data isolation and encryption for security and business-risk-aware monitoring for observability — because in a lending system, “the servers are up” is necessary but nowhere near sufficient for the system to be considered healthy.