Settlement Models and Escrow Accounts in Digital Payments

What Is Settlement?

Settlement is the step where funds actually move from the acquirer or aggregator that processed a transaction into the merchant's own bank account. Authorization - the moment a payment is approved at checkout - happens in seconds. Settlement is the separate process that follows: batching approved transactions together and transferring the net proceeds, after fees and any holdbacks, to the merchant.

Until settlement happens, the merchant has confirmation that a sale went through, but not yet the money in their own account. That gap, and how it is managed, is a core design question for any payment or marketplace platform.

Settlement Cycles: Batch vs. Real-Time

Settlement timing generally falls into two broad patterns. Batch settlement groups a day's (or period's) transactions together and settles them on a fixed cycle, commonly described using notation like T+1 or T+2 - meaning funds reach the merchant one or two business days after the transaction date. Instant or real-time settlement, by contrast, aims to move funds to the merchant much faster, sometimes within the same day or close to immediately, typically through a different processing arrangement or at an additional cost.

Which cycle applies, and how quickly funds actually arrive in practice, depends on the acquirer, the aggregator, the payment method, and the specific commercial agreement in place. This article describes the general concepts rather than any specific provider's current guaranteed timelines.

Why Escrow Accounts Exist for Aggregators and Marketplaces

When a Payment Aggregator or a marketplace collects money on behalf of many merchants or sellers, it is, for a short window, holding money that isn't its own. An escrow account exists to keep that money safely separated and accounted for: funds collected from customers sit in the escrow account and are released to the correct merchant or seller only once the relevant settlement conditions - such as order confirmation or the end of a return window - are met.

At a conceptual level, RBI's escrow account framework for this kind of activity is built around that idea of safety and transparency: money belonging to merchants should be identifiable, protected from being used for the aggregator's own operating expenses, and released according to clear, pre-agreed rules, rather than sitting in a general-purpose account indistinguishable from the aggregator's own funds.

Nodal Account vs. Escrow Account: The General Distinction

Nodal and escrow accounts are related concepts that are often mentioned together, and the rules governing each have evolved over time, so the distinction below is described only in general terms. A nodal account is typically an account used by an intermediary to route customer payments through to merchants, historically associated with certain categories of online payment intermediaries. An escrow account, in the Payment Aggregator context, is generally the structure RBI's PA framework points toward for holding merchant funds in transit, with more specific expectations attached to how it is operated and overseen.

In practice, both serve a similar underlying purpose - keeping customer and merchant money properly segregated and accounted for while it is in transit - and the structure applicable to any given business should be confirmed against current RBI guidance rather than inferred from a general description like this one.

How Settlement, Reconciliation, and Disbursement Fit Together

In a well-built payment platform, settlement doesn't happen in isolation. Three processes typically work together:

• Settlement moves the net funds for a batch of transactions from the acquiring side to the aggregator's or merchant's account.
• Reconciliation matches every transaction record - from the payment gateway, the bank statement, and the merchant's own order records - to confirm that what was charged, what was settled, and what was recorded all agree, and to flag exceptions.
• Disbursement is the final step of paying out settled funds to the correct destination - a single merchant, or in a marketplace, potentially many individual sellers - net of fees, refunds, and any holdbacks.

Designing these three processes to work together cleanly, with a clear audit trail at each step, is one of the more operationally important parts of building a payment or marketplace platform. Errors here surface directly as merchant trust and support-ticket volume, often well after the checkout experience itself is done.