Payment gatewayUPI · Cards · Netbanking · Wallets
Accept every payment. Route it to where it succeeds.
- UPI, cards, netbanking and wallets
- Hosted or embedded checkout, your branding
- Routing, retry and failover across providers
- Settlement and reconciliation in one place
Starter plan includes free API access; transaction charges are separate. Availability and settlement options are confirmed during onboarding.
Order #10234
₹2,450.00
- UPIAny UPI app
- CardsCredit and debit
- NetbankingChoose your bank
- WalletsWhere enabled
Secured by 
- Provider A✓ 96.4%
- Provider B94.1%
- Provider C▲ Paused
UPI success rate, last 15 min
Settlement
- Methods
- UPI, cards, netbanking, wallets
- Checkout
- Hosted or embedded
- Settlement
- Commonly 1–2 banking days
- Getting started
- Free API access on Starter
Why LILPE
A payment gateway that doesn't depend on one provider
Best provider for each payment
Rules first, then eligible providers ranked by recent success rate, response time and cost.
Recover failed attempts
Recoverable failures can be retried on another provider, as one payment with one reference.
Keep selling during outages
A provider that crosses error or timeout thresholds is paused for that method; traffic moves to healthy ones.
Your checkout, your brand
Hosted or embedded checkout carrying your branding, on web and mobile.
Card data stays out of your systems
Card numbers never reach your servers; saved cards use network tokens.
Settlements you can reconcile
Orders, payments and settlement lines matched across providers, with exceptions listed.
How it works
From checkout to settlement in four steps
- 1
Customer pays
On your hosted or embedded checkout, by UPI, card, netbanking or wallet.
- 2
LILPE routes
Your rules decide which providers are eligible; recent performance decides which one wins.
- 3
Provider authorises
If it fails for a recoverable reason, the payment can be retried on another provider.
- 4
You get settled
Settlement lines matched to payments, commonly within one or two banking days.
Who it's for
Built for businesses that can't afford a failed checkout
- E-commerce and D2CHigh-volume checkout across UPI, cards and netbanking, with retries when a provider struggles.
- SaaS and subscriptionsFirst payments and renewals, with mandates kept on the provider that holds them.
- MarketplacesCollect from buyers and reconcile across providers before paying sellers.
- EducationFee collection across methods, with references parents and finance teams can trace.
- HealthcareBills and advance payments, with a clear record for every attempt.
- Travel and hospitalityBookings and deposits where a declined payment means a lost booking.
Get started
Start accepting payments with LILPE
- A short call about your methods, volumes and current providers
- Sandbox access and the API reference during onboarding
- Go live with the LILPE team on hand
Availability and settlement options are confirmed during onboarding.
Talk to us about Payment Gateway
Tell us a little about your business and we'll get back to you.
How LILPE works
Where Payment Gateway fits in LILPE
- Your checkoutWeb, app, link or QR
LILPEOne API and dashboard- Routing engineRules, health, cost
- ProvidersGateways, aggregators, acquirers
- Payment networksCards, UPI, netbanking, wallets
Where it sits in the payment lifecycle
- 01PaymentRequest arrives
- 02DecisionRules and health
- 03RouteBest provider
- 04AuthorizationApproved or retried
- 05SettlementFunds arrive
- 06ReconciliationMatched and reported
- Intelligent routingEach payment is routed across the providers connected for your business, by your rules.
- Smart retryRecoverable failures can be retried on another eligible provider as one payment.
- Automatic failoverUnhealthy providers are paused for a method and traffic moves to healthy ones.
- ReconciliationOrders, payments and settlement lines matched across providers, with exceptions listed.
Availability and settlement options are confirmed during onboarding.
The complete guide
Accepting online payments, explained end to end
A payment gateway takes a payment at your checkout, gets it approved by the customer's bank or UPI app, and tells your systems the result. LILPE does this across several connected payment providers and chooses the provider for each payment. This guide covers how that works, what it costs and what can go wrong.
- Observe: Before choosing a route, LILPE reads live UPI health for each connected provider: success rate and response time over the last few minutes.
- Decide: Rules first, then ranking. All three can take UPI at this amount; Provider A has the best recent UPI success, so it gets the payment.
- Recover: Provider A doesn't answer in time. A status check shows the payment was never created there, so nothing reached the customer, and a retry is safe.
- Failover: The retry goes to Provider B with the same idempotency key. Provider A's timeouts have crossed the threshold, so new UPI payments stop going to it for now.
- Complete: The customer approves once in their UPI app. Your server receives payment.authorized, and there is one payment with two attempts.
Chapter 01
What a payment gateway does
When a customer clicks “Pay”, several parties are involved in a few seconds. The customer's bank has to approve the money, a network has to carry the request, and a regulated payment provider has to collect the money for you and later pay it into your bank account.
A payment gateway is the part that connects your checkout to all of that and reports back one clear result.
- 01Customer
Chooses a method and approves the payment
- 02Your checkout
Your website or app, which creates the payment
- 03LILPE
Picks the provider, tracks the payment and reports the result
- 04Payment provider
Aggregator, gateway or acquiring bank that collects the money
- 05Network
UPI (NPCI) or a card network that carries the request
- 06Customer's bank
Approves or declines, and debits the account
Chapter 02
One payment, start to finish
Every payment moves through the same few states, whatever the method. The customer's part in the middle is what differs: a UPI PIN, a card OTP or a bank login.
- created
Your server has created the payment. The customer hasn't paid yet.
- processing
With a provider. The customer is approving it, or the bank is responding.
- authorized
The money is approved. This is when you fulfil the order.
- settled
The provider has paid the money, minus fees, into your bank account.
- failed ← from processing
Declined, abandoned or timed out, with a reason category.
- refunded ← from authorized
You returned all or part of the money.
- The customer picks UPI.
- On a phone, their UPI app opens with the amount filled in (intent). On a computer, they scan a QR code instead.
- They enter their UPI PIN in their own app.
- Their bank debits the account, and the payment is confirmed through NPCI's UPI system.
- The status becomes authorized, usually within seconds.
If the confirmation is delayed, the payment can sit in processing for a while. That's normal for UPI, so don't ask the customer to pay again.
- The customer enters a card or picks a saved card (held as a token).
- Their card issuer asks them to confirm, usually with an OTP.
- The issuer approves or declines.
- On approval the payment is authorized, and captured immediately or later depending on your setup.
- The customer picks their bank.
- They're redirected to the bank's own site and log in.
- They confirm the payment there.
- The bank sends them back to your site and reports the result.
Some banks report late. A payment can show processing for a few minutes before it settles one way or the other.
- The customer picks a wallet.
- They log in to the wallet or confirm with an OTP.
- The wallet balance is debited.
- The payment is authorized.
Chapter 03
Payment methods
Offer the methods your customers actually use, and know where each one tends to break. That tells you where a second provider matters most.
| Method | How the customer pays | Where it usually goes wrong | Refund goes back to |
|---|---|---|---|
| UPI | UPI app (intent) on a phone, QR code on a computer; approves with UPI PIN | PSP or bank slowdowns at peak hours; no UPI app on a desktop | The bank account linked to the UPI ID |
| Cards | Card details or a saved token, then an OTP from the issuer | Issuer declines, and customers dropping off at the OTP step | The same card |
| Netbanking | Redirect to the bank's site and log in | An individual bank's netbanking being down | The same bank account |
| Wallets | Wallet login or OTP | Low wallet balance; wallet provider incidents | The wallet balance |
| Pay later and EMI | Eligibility check, then confirmation | The customer isn't eligible | Depends on the lender or issuer |
UPI payments have per-transaction limits set by NPCI and by the customer's bank. Which methods you can offer depends on the providers connected for your business, and is confirmed during onboarding.
Chapter 04
How fees work
A payment fee is usually a percentage of the payment, sometimes with a flat amount on top. It is called the merchant discount rate (MDR). It varies by method, by card network and type, and by your agreement. GST is charged on the fee, not on the payment.
LILPE pricing is quoted for each business, so this page doesn't list rates. What it can do is show you how the pieces fit together, using your own numbers.
| Component | What it is | Worth knowing |
|---|---|---|
| MDR | The processing fee on each payment, as a percentage, a flat amount, or both | Differs by method, card network, card type (debit, credit, corporate) and your agreement |
| Zero-MDR payments | RuPay debit card payments, and UPI payments up to ₹2,000 | Zero since January 2020 under government rules. Until 14 October 2026 that covers every UPI payment; from 15 October 2026, NPCI sets 0.4% on UPI merchant payments above ₹2,000, capped at ₹300. Providers may still charge for other services |
| International cards | Cards issued outside India | Usually priced higher than domestic cards; see the International Payment Gateway |
| Refunds and chargebacks | Money returned to the customer, or taken back through a dispute | Whether the original fee is returned, and any dispute fee, depends on the provider |
| GST | Tax on the fee | Charged on the fee amount, at the rate shown on your invoice |
- Card payments in a month
- Fee at an illustrative 2%
- GST on the feeAt the rate on your invoice
- Net before refunds
Your numbers, your rates
Enter an amount, your percentage fee and the GST rate on your invoice to see the breakdown.
Calculated only from the numbers you enter. It isn't a LILPE quote or a LILPE rate.
Want the actual numbers for your business? See how LILPE pricing works.
Chapter 05
Which setup fits your business
Start from how your customers reach you. The right setup follows from that.
You have a website or app and want the quickest route to taking payments
Hosted or embedded checkout
Payment has to feel native inside your app or product
You sell through chat, email or invoices, or don't have a website
Customers pay at a counter or on delivery
Some of your customers are outside India
Chapter 06
Integration options
All options sit on the same routing, statuses, webhooks and settlement. The difference is how much of the checkout you build yourself.
| Option | What you build | Card details | Good for |
|---|---|---|---|
| Hosted checkout | A server call to create the payment, then send the customer to the checkout | Entered on the hosted checkout, never on your servers | Most websites, and the fastest start |
| Embedded checkout | The same, with the checkout shown inside your page | As above | Keeping customers on your site |
| Collection API | Your own payment UI, calling the API | Captured through a secure tokenisation step, never on your servers | In-app flows, custom marketplace checkouts |
| Payment Links | Nothing. Create links in the dashboard | Entered on the payment page | Invoices, chat sales, one-off requests |
Chapter 07
API and webhooks
Your server creates a payment and gets back the next step for the customer. When the result is known, LILPE sends your server a signed webhook. Two rules prevent most integration bugs:
- send an idempotency key with every create request, so a network retry can't create a second payment;
- treat the webhook, not the customer's redirect, as the signal that the payment succeeded.
For developers
The shapes below are illustrative. The full reference, with every field, comes with sandbox access.
POST /v1/payments
Idempotency-Key: order-10234-1
{
"amount": 245000,
"currency": "INR",
"method": "upi",
"reference_id": "order-10234"
}{
"id": "pay_7Hq2",
"status": "processing",
"next_action": { "type": "upi_intent", "url": "upi://pay?..." }
}{
"type": "payment.authorized",
"data": { "id": "pay_7Hq2", "reference_id": "order-10234", "amount": 245000 }
}Details: one status and error model · webhook signing and retries
Chapter 08
Why payments fail
Most failures fall into a few groups: some the customer causes, some the bank, some the provider. Only the provider-side ones can be fixed by trying another route. Retrying the rest just adds noise.
| What happened | Usual cause | On whose side | Retry on another route? | What to tell the customer |
|---|---|---|---|---|
| Wrong UPI PIN or card OTP | Customer entered it wrongly | Customer | No | Try again; check the PIN or OTP |
| Insufficient funds | Balance or limit too low | Customer | No | Try another method |
| Declined by the issuer | Bank risk rules, card blocked or expired | Customer's bank | No | Try another card or method |
| Bank or issuer unavailable | The customer's bank isn't responding | Customer's bank | Yes, where fresh approval is possible | Try again in a moment |
| Provider timeout or error | The provider or its link to the network is struggling | Provider | Yes, after a status check | Nothing; the retry is automatic |
| Customer left the flow | Closed the app, or didn't approve in time | Customer | No | Send a reminder or payment link |
A timeout isn't a failure until it's confirmed. The first provider is checked before any retry, so no one is charged twice.
“Failed” but the money was debited
Sometimes a bank debits the customer even though the payment didn't complete. For these failed transactions, RBI requires automatic reversal within set deadlines, T+1 for UPI and T+5 for card payments, and compensation of ₹100 a day if the bank misses them. The reversal comes from the bank. It isn't a refund you issue.
Chapter 09
Routing and recovery across providers
The trace at the top of this page is the whole idea in one payment. LILPE watches how each connected provider is performing, sends each payment to the one most likely to approve it, retries provider-side failures elsewhere, and stops sending traffic to a provider that's failing.
You don't configure any of this in your checkout. It happens behind the same integration.
| Phase | What happens | Read more |
|---|---|---|
| Observe | Live success rate and response time per provider and method | Provider performance |
| Decide | Your rules first, then ranking on live performance | Intelligent routing |
| Recover | Status check, then retry on another provider if it's safe | Smart retry |
| Failover | New payments stop going to a failing provider | Automatic failover |
| Complete | One signed event to your server, whichever provider approved it | Unified webhooks |
Chapter 10
Refunds, reversals and chargebacks
Three ways money goes back to a customer, started by three different parties.
| Type | Who starts it | When it happens |
|---|---|---|
| Refund | You | A return, a cancellation or a goodwill gesture on a successful payment. It goes back through the provider that took the payment |
| Reversal | The customer's bank | A failed payment debited the account anyway (see chapter 8) |
| Chargeback | The customer, through their card issuer | A dispute about a card payment; you respond with evidence |
More in the Refund API guide.
Chapter 11
Settlement and reconciliation
An authorized payment isn't money in your account yet. Each provider pays you in batches, on its own cycle (commonly one or two banking days), after deducting fees and GST on them. Refunds are often netted out of the same batch.
With several providers you get several credits, so each settlement line is matched back to its payment and order. Read the Settlement guide.
Chapter 12
Security and compliance
Card data.Under RBI's card-on-file tokenisation rules, only card issuers and card networks may store actual card numbers. A saved card is kept as a token, created with the customer's explicit consent and confirmed by their bank. With LILPE, card numbers never reach your systems.
Customer approval.Every method has its own approval step: a UPI PIN in the customer's app, an OTP from the card issuer, or a login at the customer's bank. That step happens outside your checkout.
LILPE's controls.Details of LILPE's security controls, audits and certifications are shared during onboarding due diligence. This page doesn't claim any certification.
Chapter 13
Industry playbooks
The same gateway, set up differently depending on what you sell and how your customers pay.
| Business | What customers use | What to watch | Setup that fits |
|---|---|---|---|
| D2C and e-commerce | UPI first, then cards | Traffic spikes during sales | A second UPI route; retries on provider errors |
| SaaS and subscriptions | Cards, UPI | Recurring charges need mandates | Checkout for the first payment; see Subscription Payments for recurring |
| Education | Netbanking, UPI | Fee deadlines create bursts | Payment links for fee reminders; spread load across providers |
| Travel and hospitality | Cards, often high value | Declines on large tickets; cancellations | Route large tickets deliberately; plan refunds |
| Gaming and digital content | Small UPI payments | Evening peaks | Rank UPI providers on live success |
| Marketplaces | All methods | Refunds per order, per seller | Your order and seller references on every payment |
FAQ
Payment gateway questions
What is a payment gateway, in one sentence?
It's the service that takes a payment at your checkout, gets it approved by the customer's bank or UPI app, and tells your systems whether it succeeded.
Is a payment gateway the same as a payment aggregator?
Not quite. A gateway is the technology that carries the payment. A payment aggregator is the regulated business that collects the money on a merchant's behalf and settles it to them. Many companies do both.
How is LILPE different from a single payment gateway?
A single gateway sends every payment to one provider. LILPE connects your checkout to several providers and decides, payment by payment, which one to use. If a provider has problems, the others carry the traffic.
Which payment methods can my customers use?
UPI, credit and debit cards, netbanking and wallets. Pay-later and EMI options are available where a connected provider supports them for your business.
What does it cost?
Fees depend on the payment method, the card type and your agreement. LILPE quotes pricing for each business. The fee chapter on this page explains each component, and the calculator works from your own rates.
Why did a customer see “failed” but their money was debited?
The bank debited the account, but the payment didn't complete. For failed transactions, RBI sets deadlines for the automatic reversal: T+1 for UPI and T+5 for card payments, with compensation if the bank misses them. This is separate from a refund you issue.
Should I mark the order paid when the customer lands on my success page?
No. Wait for the webhook, or check the payment's status. Customers close tabs and lose signal, so the redirect only tells you they finished the flow.
What happens if a provider goes down?
New payments go to another connected provider that supports the same method. Payments already in progress on the affected provider complete or fail there.
Can I keep saved cards?
Not the card numbers themselves. Under RBI's card-on-file tokenisation rules, saved cards are held as tokens, with the customer's consent.
When does the money reach my bank account?
Each provider settles on its own cycle, commonly one or two banking days after the payment. The Settlement guide explains the cycle, the deductions and the holidays that shift it.
Do I sign a separate agreement with each provider?
Provider onboarding is handled as part of your LILPE onboarding. Each provider still runs its own merchant checks, and how the agreements are structured for your business is set out during onboarding.
Can I accept payments from customers abroad?
Yes, through connected providers that support international cards. See the International Payment Gateway page.
How it works underneath
- Intelligent RoutingBest provider for every transactionView details
- Smart RetryRecover failed attempts on another providerView details
- Automatic FailoverRoute around degraded providersView details
- Unified WebhooksOne normalised event streamView details
Related products
Sources
- RBI — Harmonisation of Turn Around Time and customer compensation for failed transactions (20 Sep 2019)T+1 reversal for UPI/IMPS, T+5 for cards, ₹100/day compensation. Applies to failed transactions.
- RBI — Permitting Card-on-File Tokenisation (CoFT) Services (7 Sep 2021)Only card issuers and networks may store actual card data; tokenisation needs explicit consent with an additional factor of authentication.
- PIB — zero MDR on RuPay debit cards and BHIM-UPIMDR made zero from January 2020 under section 10A of the Payment and Settlement Systems Act and section 269SU of the Income-tax Act.
- NPCI — Merchant Discount Rate (MDR) on Select UPI (P2M) Transactions: FAQs (15 Sep 2026)From 15 Oct 2026: UPI merchant payments up to ₹2,000 stay at zero; above ₹2,000, 0.4% capped at ₹300, with a flat ₹5 for railways, telecom, insurance, fuel and utility bills.
Last reviewed . Examples, rates and traces marked illustrative are not LILPE figures.
Guides
Guides and explainers
- PlatformPayment Gateway Integration: Hosted Checkout, Redirect or API?There are four common ways to put a payment gateway into a website or app, from a redirect you can set up in an afternoon to a full API integration your developers own. How each one works, what it means for your security and PCI DSS scope, the steps every integration shares, and how to test before going live.Read the guide
- PaymentsPayment Gateway Charges in India: How to Read a Pricing SheetA payment gateway's headline rate is only one line of what you pay. Setup and annual fees, per-method transaction rates, international and EMI pricing, refund and chargeback fees, settlement speed, minimum commitments and GST all add up. What each line means, which ones regulation fixes, how to work out your real cost, and what to ask before you sign.Read the guide
- CompliancePayment Gateway vs Payment Aggregator: Where the Money Actually SitsA payment gateway moves payment messages; a payment aggregator collects the money and settles it to you. That one difference decides who is regulated, who checks your business, who holds your funds and who you chase when a settlement is late.Read the guide
- PaymentsOnline Payment Failed? Where Payments Break, and What Happens to Your MoneyA failed online payment can break in five different places: your phone, the merchant's checkout, the payment provider, the network between banks, or your own bank. Each leaves different clues and needs a different fix. Here's how to tell which one you've hit, what each error usually means, and when it's safe to try again.Read the guide
- PaymentsHow Net Banking Payments Work: From Bank Redirect to ConfirmationChoose your bank, log in on its page, approve, and come back to the store: net banking looks simple, but several systems have to agree before an order is marked paid. The flow step by step, who does what, why net banking payments fail or get stuck with money debited, what customers and merchants should do, and how net banking compares with UPI and cards.Read the guide
- EngineeringDuplicate Payments: Why Customers Get Charged Twice and How to Prevent ItA customer pays once and is charged twice. It's rarely a provider fault: it's a double tap, a timeout followed by a blind retry, or two providers that both said yes. Where duplicates come from, the four layers that stop them (including idempotency keys done properly), and what to do when one slips through.Read the guide
- PlatformPayment Success Rate: How to Measure It Without Fooling YourselfPayment success rate is the number every payments team quotes and few define the same way. Attempt-level or order-level, what goes in the denominator, how retries, pending payments and customer drop-offs distort it, the breakdowns that actually explain a drop, and how to turn it into alerts that fire for the right reasons.Read the guide
- PaymentsSwitching Payment Gateways: A Migration Plan That Doesn't Lose PaymentsMoving to a new payment gateway is mostly easy for one-off checkout payments and mostly hard for everything attached to the old one: saved cards, recurring mandates, refunds on past payments, printed QR codes, virtual accounts and reconciliation. An inventory of what has to move, a phased plan with a parallel run, and the tail you'll need to keep the old account open for.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 in the sandbox.
- 04Go liveProduction credentials, with the LILPE team on hand for go-live.
Tell us how your customers pay today
Share your methods, your current provider and where payments fail. We'll walk you through what routing across providers would change.