Settlement Engine · Live · T+1
Gross Transaction Value
Puma India · MID: 40231900 · Visa Credit
₹10,000.00
MDR Deduction
Visa Credit Domestic · 1.40%
- ₹140.00
Interchange Passthrough
Visa ICP · Issuer Share 0.80%
- ₹80.00
Processing & Platform Fee
Flat ₹2.50 + gateway 0.02%
- ₹4.50
ISO/Agent Commission
RetailCo PayFac · 0.15% of GTV
- ₹15.00
Net Settlement to Merchant
ICICI Bank · A/C ****1221 · T+1
₹9,760.50
SETTL-ID · BATCH: 20260626-0841
Puma India Pvt. Ltd.
2,840 transactions settledBatch closed in 340ms
Matched

Settlement at Scale

The Numbers Behind Every Settled Transaction

DigiPay.Guru's Settlement System is built for volume, accuracy, and compliance — from a single merchant to a network of thousands.

T+0

Same-Day Settlement Supported

99.99%

Reconciliation Accuracy

200+

MDR & Fee Rule Combinations

50M+

Transactions Settled Monthly

Why It Exists

Three Things That Are True About Payment Settlement

01

A wrong settlement is worse than no settlement.

Every rupee that lands in the wrong account — or doesn't land at all — becomes a dispute, a support ticket, or a regulatory finding. Settlement systems that get it almost right are the most expensive systems you can operate. Precision isn't a feature. It's the entire product.

02

Manual reconciliation is a liability masquerading as a process.

When your reconciliation team exports CSVs and cross-references bank files at midnight, you are one human error away from a financial discrepancy that takes weeks to resolve. Automation doesn't just save time — it eliminates an entire category of risk that manual processes permanently carry.

03

Complexity is not an excuse for opacity.

MDR, interchange, processing fees, ISO commissions, sub-merchant splits — settlement is genuinely complex. But complexity should be contained inside the engine, not exposed to your merchants and your ops team. The output should always be simple: who gets paid what, and when.

Settlement Engine

The Engine Behind Every Cleared Rupee

The Settlement Engine is the core of the system — a rule-based, event-driven processor that takes a raw transaction and produces a verified, audited net payout for every party in the acquiring chain.

How it Works

From Transaction to Bank Credit. Automatically.

Every cleared transaction triggers a settlement pipeline. The engine reads the merchant's fee profile, applies MDR, deducts interchange, calculates commissions, and computes the net payout — in milliseconds.

Batches run on configurable cycles: T+0 for instant settlement, T+1 for next-day, or custom windows. Every batch produces an immutable audit record. Nothing is manual. Nothing is approximated.

Rule-Based Settlement Engine

Configure once. Settle forever. The engine reads merchant-level rules from the Merchant Management System and applies them automatically to every transaction in every batch — no manual intervention required at run time.

Per-merchant, per-outlet, and per-terminal settlement rules
Configurable settlement cycles: T+0, T+1, T+2, weekly, or custom
Multi-bank settlement — credit different accounts per outlet
Holding and reserve rules for risk-controlled merchants
Immutable settlement ledger — every batch cryptographically signed
Settlement Cycle
T+1 · Daily Batch
Batch Run Time
03:00 IST (configurable)
Bank Credit ETA
Next business day · 09:00
Transactions in Batch
2,840 · ₹4.1 Cr gross
Batch Status: ✓ Closed & Signed
Multi-Party Settlement Distribution

In a PayFac, ISO, or hierarchical acquiring model, a single transaction produces obligations for multiple parties. The engine splits and routes each party's share automatically — acquirer, ISO, sub merchant, and gateway — in a single settlement run.

Split settlement across unlimited parties in the hierarchy
Each party's account credited independently with itemized breakdown
Real-time visibility for each party into their own settlement status
IMPS, NEFT, RTGS, ACH bank transfer support
Acquirer Net
₹3,200.00
ISO Commission
₹480.00
Sub-Merchant Credit
₹9,750.50
Gateway Fee
₹14.50
Transfer Method
IMPS · Batch 0841

Processing Fees

Every Fee. Calculated Correctly. Every Time.

Merchants pay the fee they agreed to. Not one paisa more, not one paisa less.

Processing fees in payment acquiring are rarely simple. A merchant's fee profile might include a flat per-transaction charge, a percentage of the transaction value, a minimum floor, a maximum cap — applied differently for domestic vs. international cards, and different again for credit vs. debit.

The Fee Management module maintains a structured fee matrix per merchant and applies it to every transaction at the moment of settlement — not as an approximation, but as a calculation verified against the fee rule in force at that exact date and time.

Flat fee + percentage combinations with floor and cap
Effective date scheduling — future-date fee changes
Domestic vs. international card differentiation
Card-type specific rules: debit, credit, prepaid, corporate
Fee simulation: model the impact before you apply it
Fee Matrix — RetailCo Group8 Active Rules
CARD TYPEFLAT%NET
Visa Debit · Domestic₹00.75%99.25%
Visa Credit · Domestic₹01.40%98.60%
Mastercard Premium₹01.80%98.20%
Amex · International₹02.50%97.50%
RuPay · All₹00.00%100.00%
UPI QR₹00.00%100.00%
Rate change scheduled: Visa Credit → 1.35% effective 1 Aug 2026
Commission Distribution · Batch 0841Distributed
PARTYRULEAMOUNT
Nexus Bank (Acquirer)Residue₹3,200.00
RetailCo PayFac0.15% GTV₹1,500.00
Field Agent · MH-12₹2/txn₹480.00
Tech Platform Fee0.08% GTV₹800.00
4 parties · Total distributed: ₹5,980.00 · Cycle closed

Commissions & Revenue Splits

Every Partner Gets Their Share. Automatically.

The acquiring chain isn't two parties. It's five. Everyone gets paid correctly, every cycle.

In a modern acquiring ecosystem, revenue doesn't flow from one entity to another — it flows through a network of relationships: acquirer banks, ISOs, payment facilitators, sub-agents, and technology partners all have a stake in each transaction.

The Commission Engine models this network as a configurable revenue sharing tree. Each node in the hierarchy has its own commission rule — a percentage of gross revenue, a percentage of MDR collected, or a flat per-transaction fee — and the engine computes, aggregates, and distributes every party's share in the same settlement run that pays the merchant. No disputes about who gets what.

Revenue share models: % of gross, % of MDR, or flat per transaction
Unlimited hierarchy depth — ISOs, sub-ISOs, agents, and referrers
Each partner sees only their own commission statement
Commission payout cycles independent of merchant settlement cycles
Exportable commission reports for partner reconciliation

MDR — Merchant Discount Rate

MDR Isn't Just a Number. It's a Revenue Architecture.

The MDR you charge a merchant determines your margin. The MDR engine makes sure every basis point is applied correctly.

Merchant Discount Rate (MDR) is the percentage of each transaction that a merchant pays for the privilege of accepting cards. It sounds simple — but in practice, MDR is a layered structure. The acquirer sets a headline MDR for the merchant. From that MDR, the acquirer must fund the interchange going to the issuing bank, the scheme assessment fees paid to Visa or Mastercard, and their own processing costs. What remains is the acquirer's spread — and that margin lives or dies on the accuracy of MDR application at scale.

DigiPay.Guru's MDR engine manages this entire stack. It applies the correct MDR per transaction based on card scheme, card type, transaction channel, and amount band — and tracks the disaggregation of that MDR into interchange, scheme fees, and acquirer margin automatically.

MDR rules per scheme: Visa, Mastercard, RuPay, Amex, Diners
Card-type differentiation: debit, credit, corporate, premium, international
Channel differentiation: POS, SoftPOS, mPOS, eCommerce, QR
MDR disaggregation: interchange + scheme fee + acquirer spread
Blended rate and interchange-plus models both supported
MCC-based MDR — different rates for different merchant categories
MDR Disaggregation · ₹10,000 Visa CreditCalculated
COMPONENTRATEAMOUNT
Gross MDR Charged1.40%₹140.00
Interchange to Issuer0.80%₹80.00
Visa Scheme Assessment0.11%₹11.00
Acquirer Spread (Net)0.49%₹49.00
Acquirer margin: ₹49.00 per ₹10,000 · 0.49% spread locked
Interchange Analysis · Today8 Schemes
CARD / TIERRATEVOLUME
Visa · CPS/Retail0.80%₹4,20,000
Visa · EIRF (downgraded)1.85%₹28,000
Mastercard · Merit III0.91%₹1,85,000
RuPay · Standard0.00%₹2,10,000
2 transactions downgraded to EIRF — excess cost ₹235. Review MCC data.

Interchange Management

Interchange Is Not a Cost. It's a Variable.

Interchange rates shift with card type, merchant category, and scheme rules. The system tracks every one of them.

Interchange is the largest single cost in a payment acquiring operation. It is paid by the acquirer to the card issuer for every card transaction, and it varies by card scheme, card product type, merchant category code, transaction type, and country. Visa and Mastercard publish interchange tables with dozens of rate categories — and the rate applied to a specific transaction depends on how accurately the acquirer qualifies it.

Misqualification — submitting a transaction with incorrect data that triggers a higher interchange tier — is one of the most common and expensive mistakes in acquiring operations. DigiPay.Guru's Interchange Management module maintains current interchange tables, applies the correct tier to every transaction, and flags qualification failures before they hit your settlement. It also models interchange-plus pricing, allowing you to pass through the exact interchange cost to merchants with transparency, and retain your markup separately.

Live interchange tables for Visa, Mastercard, RuPay, and Amex
Automatic MCC-to-interchange-tier mapping per transaction
Qualification failure detection — flag downgrade risk before settlement
Interchange-plus and blended pricing models configurable per merchant
Cross-border interchange tracking for international card transactions
Interchange cost reporting for acquirer margin analysis

Automated Reconciliation

Reconciliation That Closes Itself.

Every transaction that enters the system must exit it — matched, verified, and accounted for. Automatically.

Reconciliation is the process of confirming that what the payment network says happened matches what your system recorded — and that the money that was supposed to move actually did. In large acquiring operations, this means matching millions of transaction records across multiple sources: your switch, the card scheme, the issuing bank, and your own settlement files.

Manual reconciliation at this scale is not just slow — it's structurally unreliable. DigiPay.Guru's Reconciliation Engine automates this entire process. It ingests transaction data from every source, matches records using a configurable ruleset, flags exceptions automatically, and produces a daily reconciliation report that closes the books — verified to the last paisa.

Three-way matching: switch records × scheme files × bank credits
Automatic exception flagging — unmatched, over-settled, under-settled
Configurable matching tolerance windows for timing differences
Chargeback and dispute tracking through the full lifecycle
Daily, weekly, and on-demand reconciliation reports
Audit-ready export: PDF, CSV, and structured API response
Reconciliation Report · 26 Jun 202699.9% Matched
CATEGORYCOUNTAMOUNT
✓ Matched transactions2,837₹1.38 Cr
△ Pending (timing)3₹4,200
▣ Chargebacks open2₹1,840
✗ Exceptions0₹0
Books closed at 23:47 IST · 3 pending items auto-queued for T+2 matching

Full Settlement Coverage

Nothing Falls Through. Nothing Is Estimated.

Six capabilities that together make DigiPay.Guru's settlement system the most complete in the acquiring stack.

Real-Time Settlement Visibility

Every batch, every transaction, every payout — visible in real time on a single dashboard. Merchants see their settlement status. Ops sees exceptions. Finance sees the ledger. Nothing is hidden.

Configurable Settlement Cycles

T+0 same-day settlement for premium merchants. T+1 next-day for standard. T+2 or weekly for risk-controlled accounts. Each merchant's cycle is configured independently — no platform-wide restrictions.

Chargeback & Dispute Management

Chargebacks automatically deducted from the next settlement cycle. Full chargeback lifecycle tracking — retrieval request, chargeback notice, representment, pre-arbitration, and final resolution — with notification at each stage.

Financial Reporting & GL Export

Daily settlement reports, MDR income statements, interchange cost analysis, and commission ledgers — all exportable in CSV, PDF, or via API. Built for finance teams who need audit-ready outputs, not raw database dumps.

Reserve & Holdback Management

Configure rolling or fixed reserves for high-risk merchants. Reserve funds are tracked separately in the settlement ledger and released automatically at the end of the reserve period — no manual release required.

Core Banking & ERP Integration

Settlement data flows directly into your core banking system or ERP via REST API or SFTP batch file — in any standard format. No CSV downloads. The books reconcile themselves.

Platform Ecosystem

Settlement Is the Final Step
of a Larger System

The Settlement System connects directly to every upstream product — transactions, merchants, fees, and terminals all feed into a single, closed-loop financial operation.

UPSTREAM SOURCE

Merchant Acquiring Platform

Transactions authorized by the Acquiring Platform flow directly into the Settlement Engine. Every cleared authorization creates a settlement obligation — automatically queued for the next batch.

Learn more
CONFIGURATION LAYER

Merchant Management System

Fee rules, MDR rates, commission structures, and merchant bank accounts are all configured in the MMS. The Settlement Engine reads these at runtime — no manual entry per batch.

Learn more
TRANSACTION SOURCE

POS Acquiring Platform

Every POS terminal transaction enters the settlement pipeline. Terminal-level transaction data provides the granularity needed for per-outlet reconciliation and MCC-based fee application.

Learn more

One More Thing.

Settlement Should Be Invisible to Everyone Except the Merchant's Bank.

When settlement works the way it should, nobody talks about it. Merchants see cleared funds. Finance sees matched books. Compliance sees clean audit trails. That's what we built.

See the Settlement Engine Live
Section Page CTA

Frequently asked questions

T+0 settlement means the merchant receives their funds on the same day the transactions occur — not the next business day. The DigiPay.Guru Settlement System supports T+0, T+1, T+2, weekly, and fully custom settlement cycles, configurable per merchant. T+0 settlement typically requires real-time bank transfer rails (IMPS in India) and is generally reserved for premium or pre-approved merchant tiers. Each merchant's cycle is configured independently in the Merchant Management System.

MDR (Merchant Discount Rate) is the fee percentage deducted from each transaction before settlement. The system applies MDR at the individual transaction level, using the merchant's configured fee matrix. Every merchant can have a different MDR — differentiated by card scheme (Visa, Mastercard, RuPay), card type (debit, credit, corporate, premium), transaction channel (POS, SoftPOS, eCommerce), and amount band. MDR rules are configured in the Merchant Management System and applied automatically during settlement — there is no manual calculation involved.

Interchange-plus (or cost-plus) pricing is a model where the merchant pays the actual interchange rate set by the card scheme, plus a fixed markup retained by the acquirer. This is more transparent than a blended MDR because the merchant sees exactly what portion goes to the card issuer and what the acquirer earns. DigiPay.Guru's Settlement System supports both interchange-plus and blended MDR models, configurable per merchant. The system maintains live interchange tables for all supported schemes and applies the correct tier to each transaction.

In a PayFac or ISO model, a single transaction involves multiple parties who each have a financial stake: the acquirer bank, the ISO or PayFac, possibly a sub-ISO or referral agent, and the sub-merchant. The Settlement System models these as a hierarchy. Each party has a configured commission rule — percentage of gross, percentage of MDR collected, or flat per-transaction. The settlement run computes every party's share simultaneously and credits each party's designated bank account in the same batch. Each party receives a statement showing only their own transactions and commissions.

When a chargeback is received, the system automatically creates a debit entry against the affected merchant and deducts the chargeback amount from their next settlement batch. The chargeback is tracked through its full lifecycle — retrieval request, chargeback notice, merchant representment, pre-arbitration, and final ruling — with automated notifications at each stage. If the chargeback is reversed (merchant wins), the amount is credited back in the next settlement. Chargeback rates are monitored per merchant and flagged when thresholds approach scheme limits.

The Reconciliation Engine performs a three-way match: it compares your internal transaction records (from the switch or gateway) against the card scheme settlement files (Visa/Mastercard clearing reports) and the actual bank credit confirmation. When all three match, the transaction is considered reconciled and the books close. When they don't match, the engine flags the exception with a reason code — timing difference, scheme adjustment, partial settlement, or true discrepancy — and queues it for automated resolution or human review. The engine runs daily and produces a reconciliation report that is auditable and exportable.

Read our insightful blogs!

Stay updated with the latest trends and innovations in finTech with our insightful blogs.