Industry · large and multi-entity businesses
Payments at scale are a map before they're a platform
Large businesses rarely have one payment setup. They have several business units, entities, providers and banks, each added for a good reason at the time. Getting control starts with seeing all of it at once.
| Business unit | Methods | Through | Settles to | Note |
|---|---|---|---|---|
| Retail brand | UPI, cards, wallets | Provider AProvider B | Bank 1 · collections account | B is the fallback for UPI |
| B2B distribution | Bank transfers, NACH | Bank 1 | Bank 1 · virtual accounts | Invoices on credit terms |
| Subscription app | Cards, UPI e-mandates | Provider B | Bank 2 · collections account | Renewals on mandates |
| Payroll and vendors | Payouts | Bank 1Bank 2 | Funded from each unit | Second bank for continuity |
How LILPE fits
One payment layer for Global Enterprises
- Your businessCheckout, apps, platforms
LILPEOne API and dashboard- Routing engineRules, health, cost
- ProvidersPSPs, gateways, acquirers
- Payment networksCards, real-time rails, banks
- 01PaymentRequest arrives
- 02DecisionRules and health
- 03RouteBest provider
- 04AuthorizationApproved or retried
- 05SettlementFunds arrive
- 06ReconciliationMatched and reported
- Intelligent routing Each payment goes to an eligible provider, by your rules and recent performance.
- Smart retry Recoverable failures retried on another provider as one payment.
- Automatic failover Unhealthy providers paused; traffic moves to healthy ones.
- Reconciliation Payments matched to settlements across providers.
Availability and settlement options are confirmed during onboarding.
Why enterprise payments get complicated
Complexity accumulates: a new brand launches with its own provider, an acquisition brings its bank, a subscription product needs mandates, and a second provider is added after an outage. Each decision was sensible. Together they produce many dashboards, reports in different formats, and money landing in many accounts.
The goal isn't necessarily fewer providers. It's one clear picture of every flow, rules for which provider handles what, and a reconciliation that closes every day.
| Symptom | Usual cause |
|---|---|
| Month-end takes weeks | Reports from each provider in its own format |
| Nobody knows the group's cash position today | Settlements landing in many accounts |
| An outage stops sales | One provider per method, no fallback |
| Fees differ for the same service | Contracts negotiated separately by each unit |
Redundancy and routing, decided deliberately
A second provider only helps if payments can actually move to it when needed. Decide in advance which provider handles which payments, what triggers a switch, and who can make it. Write the rules down, because in an incident nobody should be inventing them.
By method
One provider for cards, another for UPI, according to strengths and terms.
By unit or entity
Each business unit's payments to the provider under its contract.
On failure
A fallback provider for a method when the primary has a problem, under agreed conditions.
How LILPE describes routing and orchestration: platform overview.
Controls that scale with the business
The larger the business, the more people can move money, and the more important it is that no single person can move it alone. Outgoing payments in particular need approvals, limits and a record of who did what.
Maker and checker
One prepares, another approves, for every outgoing batch.
Limits by role
Amounts each approver can release on their own.
Beneficiary controls
Adding or changing a payee needs separate approval.
Audit trail
Every action recorded with who, what and when.
Access reviews
Leavers removed on their last day; access reviewed quarterly.
One reconciliation, every day
Reconciliation at enterprise scale fails when it's done provider by provider, at month-end, in spreadsheets. It works when every provider's transactions and settlements, and every bank statement, are brought against your own order and invoice records daily, matched on references you control.
The output isn't a report; it's a short list of exceptions, each with an owner. That's also what auditors want to see.
- 1CollectTransactions, settlements and statements from every source.
- 2NormaliseInto one format, keyed on your references.
- 3MatchOrders to payments to settlements to bank credits.
- 4ResolveExceptions assigned and closed, daily.
- Reconciliation
Payment data and where it lives
RBI's circular on storage of payment system data (6 April 2018) requires payment system providers to store the entire data relating to the payment systems they operate in a system only in India, including full end-to-end transaction details. For the foreign leg of a transaction, the data can also be stored abroad if required.
For a group with operations abroad, that shapes where payment data sits and which systems may process it. Ask each provider how it complies, and how data reaches your own systems and those of your group companies.
Questions for every provider
- Where is our payment data stored and processed?
- How does it reach our systems and group companies?
- What security certifications or audits can you evidence?
- How are incidents reported to us, and how fast?
Choosing providers as a group
Enterprise payment decisions involve finance, technology, risk, legal and procurement, often across several entities. Agree the evaluation criteria before meeting providers: coverage of the methods you need, reliability evidence, pricing across your real volume mix, reporting formats, controls, data handling, support and exit terms. Then compare like with like, on your own numbers.
Where LILPE fits
LILPE positions itself as a payment orchestration layer (see the platform). This page doesn't name any enterprise client or claim particular results. The Enterprise plan is “Contact Sales” on the pricing page, and which capabilities fit your group is confirmed during onboarding.
Enterprise payment questions
Why do large businesses use more than one payment provider?
For resilience (if one has a problem, payments can continue through another), for coverage (different providers are stronger in different methods), and for negotiating position. The cost is more integrations, more contracts and more reconciliation.
What is payment orchestration?
A layer that sits between your systems and several payment providers, deciding which provider handles each payment under rules you set, and bringing their results and reports into one view. See the platform pages for how LILPE describes its approach.
Where must payment data be stored?
RBI requires payment system providers to store the entire data relating to the payment systems they operate in a system only in India; for the foreign leg of a transaction, data can also be stored abroad if required. Ask each provider how it complies.
How should approvals for outgoing payments work?
Through a maker-checker setup: one person prepares a payment or batch, another approves it, with limits by amount and role. Nobody who can add a new beneficiary should be able to approve payments to them alone.
How do we reconcile across many providers?
By bringing every provider's transactions and settlements into one place against your own records, matched on your order or invoice references, daily. Differences get an owner and a deadline, not just a report.
Does LILPE work with enterprises?
This page doesn't name any enterprise client. LILPE's Enterprise plan is 'Contact Sales' on the pricing page; which capabilities fit your group is confirmed during onboarding.
Official sources
- RBI — Storage of Payment System Data (6 Apr 2018)System providers to store the entire payment system data in a system only in India; foreign leg may also be stored abroad.
Last reviewed . Examples, amounts and screens marked illustrative are not LILPE figures.
Guides
Guides and explainers
- PlatformBuilding Payment Infrastructure That Scales With YouWhat changes in payments as a business grows from hundreds to millions of transactions: idempotency, notices, status as data, reconciliation, observability, provider redundancy and the controls that keep it safe.Read the guide
- PlatformSmart Routing 101: How Payment Routing Decisions WorkWhen a business uses more than one payment provider, something has to decide where each payment goes. How routing rules work, what signals they use, where they go wrong, and how to measure whether routing helps.Read the guide
- GuidesPayment Reconciliation Explained: Gateway Settlements and the Three-Way MatchReconciliation is how a business proves that what it sold, what its payment gateway collected and what reached the bank all agree. How it differs from settlement, how to read a settlement report, the three-way match step by step, common mismatches, payout reconciliation and a daily routine that works.Read the guide
- PlatformPayment Orchestration Architecture: The Components and How a Payment Flows Through ThemA vendor-neutral reference architecture for a payment orchestration layer: the unified API and data model, routing engine, provider connectors, token vault, retry controller, webhook normalisation, reconciliation and observability. What each component does, how a payment moves through them, and the design principles that keep the whole thing correct.Read the guide
Get started
From first call to live payments
- 01Tell us what you needYour methods, markets and providers. We confirm what's available for your business.
- 02Sandbox accessTest credentials and the API reference, provided during onboarding.
- 03Integrate and testOne request pattern; run success, failure, refund and webhook flows.
- 04Go liveProduction credentials, with the LILPE team on hand for go-live.
Route every payment to where it succeeds.
Tell us which providers you use today and where payments get stuck. We'll show you what the setup would look like on LILPE.