Picture a ₹1,499 order on a small online clothing store. The customer taps "Pay", approves the payment in their UPI app and lands on a thank-you page. For the customer, that's the end. For the store, it's the start of a sequence that ends later, when the money arrives in the bank, minus fees, mixed in with every other order.
Knowing that sequence is what lets you choose the right provider, set your store up so orders and payments never drift apart, and handle the awkward cases: the customer who paid but sees "payment failed", the refund that takes a week, the settlement that doesn't match the day's sales.
This guide follows the store's side. If you're comparing providers on the general questions (who holds your money, pricing, support, exit), our checklist for choosing a payment gateway covers those for any kind of business.
The lifecycle of one order
Here's the ₹1,499 order from the store's point of view. Each step is covered below.
- 1CheckoutOrder created; customer picks a method
- 2AuthenticateUPI PIN, card OTP or bank login
- 3AuthorizeThe customer's bank approves
- 4ConfirmWebhook tells your store; order is marked paid
- 5SettleProvider pays you, net of fees
- 6ReconcileOrders, payments and settlements agree
1. Checkout: create the order first
A well-built store creates the order, with its amount and a reference, before sending the customer to pay. The payment request then carries that reference, so whatever happens next, the payment can be tied back to the order. Stores that create the order only after a successful payment are the ones that later find payments with no order attached.
2. The customer pays: what changes by method
The provider's checkout takes the customer through their chosen method. Each works differently:
| Method | What the customer does | What to know as a store |
|---|---|---|
| UPI | On a phone, taps a button that opens their UPI app ("intent"). On a desktop, scans a QR code shown on screen. Approves with their UPI PIN. | NPCI requires intent for app and mobile-web stores and a dynamic QR for other web checkouts, and customers must be able to pay from any UPI app. |
| Cards | Enters card details or picks a saved card, then completes an OTP or bank-app approval | You can't store card numbers; saved cards are tokens. Our guide to how card payments work covers tokens, authorization and capture. |
| Net banking | Redirected to their bank's site, logs in and approves | More steps, more drop-off, and more "closed the bank page" failures |
| Wallets | Pays from a prepaid wallet balance | Depends on which wallets your provider supports |
| EMI and pay later | Chooses an instalment option at checkout | Offered through the provider and lending partners; terms vary |
3. Authorization: the customer's bank decides
Whatever the method, the customer's bank makes the final decision: enough money or limit, within limits, not flagged by fraud checks. If it declines, the customer sees a failure and can try another method. Reading your failure reports by reason, method and bank shows which failures are yours to fix and which are the customer's.
4. Confirmation: trust the webhook, not the redirect
After paying, the customer's browser is sent back to your store. That redirect is the least reliable signal you'll get: the customer may close the tab, lose their connection, or come back before the result is final. The reliable signals are the provider's server-to-server notification (a webhook) and its status API.
- Mark the order paid only when the webhook or a status check confirms the payment, and verify the webhook's signature so a fake one can't mark an order paid.
- Make your webhook handler safe to receive the same message twice. Providers resend when they don't get a reply.
- If a payment is pending, keep the order pending. Don't cancel it, and don't ask the customer to pay again yet; many pending payments resolve within minutes.
- Run a periodic job that checks the status of orders stuck in "payment pending", so a lost webhook never leaves a paid order unshipped.
5. Settlement: where your money is, and when you get it
Most stores use a payment aggregator. Under RBI's 2025 directions, a non-bank aggregator keeps the money it collects for you in an escrow account with a scheduled commercial bank, and pays it out to you on the schedule set in your agreement, which must state the settlement timelines clearly. RBI doesn't fix a single timeline for everyone; it's part of what you agree.
Settlements usually arrive as one amount covering many orders, after the provider's fees and any refunds or chargebacks deducted. That's why a settlement rarely equals the day's sales, and why your provider's settlement report matters more than your bank statement.
6. Refunds and returns
When an order is cancelled or returned, you start a refund through your provider, usually from the dashboard or by API. A few rules shape how it works:
- Refunds through an aggregator go back to the customer's original payment method (a UPI payment to the UPI account, a card payment to the card) unless the customer asks for another mode of their own.
- Partial refunds are normal for partial returns; keep each tied to its original payment.
- A refund is a new payment back to the customer, so it takes longer to show than a reversal of a payment that never completed.
- Customers keep their right to dispute a card payment with their bank (a chargeback) whatever your refund policy says, so a fast, clear refund process prevents a lot of disputes.
The refund API guide covers the mechanics, including how refunds, reversals and chargebacks differ on the merchant's side.
7. Reconciliation: making three records agree
At the end of each day, three records should agree: your orders, the payments your provider captured, and the settlements that reached your bank, with refunds, chargebacks and fees accounted for. When they don't, something needs attention: a paid order not marked paid, a refund not processed, a settlement short of what you expected. Doing this daily, by reference rather than by amount, is what keeps a store's books clean. Our guide to payment reconciliation sets out a routine.
Choosing how to connect your store
Providers usually offer two ways to take payments, and many stores start with one and move to the other.
| Compared on | Hosted checkout or redirect | API integration |
|---|---|---|
| How it works | Customer pays on the provider's page, or in its pop-up, and comes back | Your store collects the payment details through the provider's components and talks to its API |
| Effort to build | Low: often a plugin or a few lines of code | Higher: your developers build the flow |
| Control of the look and steps | Limited to the provider's options | Full |
| Card data handling | Stays with the provider, which keeps your security burden low | Your systems are involved, so security requirements on you are higher |
| Good for | Most small and mid-size stores, and getting live quickly | Stores that need custom flows, saved methods, subscriptions or several providers |
Whichever you choose, payment aggregators are required to make sure their merchants' systems meet the applicable security standards, such as PCI-DSS, so expect questions about how card data is handled. If your store runs on a platform such as Shopify or WooCommerce, the payment set-up usually happens through the platform's payment settings rather than custom code. Our guide to payment gateway integration compares redirect, hosted, embedded and API methods in depth.
If your store runs on Shopify, WooCommerce or another platform
Most small and mid-size stores don't build checkout from scratch: they run on a platform such as Shopify, WooCommerce, Magento or Wix, and add a payment provider through the platform's payment settings or an app or plugin. That changes what you need to check:
- Whether the provider has a supported integration for your platform, and who maintains it. An integration that falls behind platform updates breaks checkout at the worst time.
- Which payment methods appear inside the platform's checkout, and whether UPI opens the customer's app on mobile (intent) and shows a dynamic QR on desktop, as NPCI's rules require for app and web merchants.
- How order status is updated. A good integration marks orders paid from the provider's webhook, not from the customer returning to your store, and handles pending payments without cancelling the order.
- How refunds work: from your platform's order screen, or only in the provider's dashboard.
- What reports you get for reconciliation, and whether they carry your platform's order numbers.
Our pages for Shopify and WooCommerce describe how LILPE connects to those platforms. For custom-built stores, our guide to payment gateway integration compares the integration methods.
A store owner's checklist
These are the questions that matter most for an online store specifically. Ask each provider, and get the answers in writing:
- Which methods can my customers use, and does UPI open the app directly on phones (intent) with a QR on desktop?
- How do you notify my store of a payment (webhooks), how do I verify them, and how do I check a payment's status by my order reference?
- What is my settlement schedule, in the agreement, and what will the settlement report show me?
- What are the fees by method, and are they deducted before settlement?
- How do I refund, fully and partly, by dashboard and API, and how fast does it reach the customer?
- How are chargebacks handled, and how long do I have to respond?
- What happens to my checkout when your service, or a particular bank, is having problems?
- If I take cash on delivery today, what can you offer to move customers to prepaid?
Where an orchestration layer fits
As stores grow, some connect more than one payment provider: to add methods, to keep checkout running when one provider has a bad hour, or to send each payment to the provider most likely to approve it. A payment orchestration layer sits above the providers and makes that decision for each payment, while the providers still collect and settle the money under their own agreements. LILPE is a payment orchestration platform built for that; our payment gateway guide explains how it works, and availability for your business is confirmed during onboarding.
Frequently asked questions
Do I need a payment gateway or a payment aggregator for my online store?
Most online stores sign up with a payment aggregator, which collects payments into an escrow account and settles them to you, and provides the gateway technology as part of the service. A gateway on its own only carries payment data; it doesn't hold or settle money. Our guide to payment gateway vs payment aggregator explains the difference.
How long does settlement take for an online store?
It's set in your agreement with your provider. RBI requires a payment aggregator's agreement with a merchant to state the settlement timelines clearly, rather than fixing one timeline for everyone. Ask for it in writing before you sign.
Can I charge customers a fee for paying online?
Not for paying by UPI: NPCI doesn't allow a surcharge on UPI payments. If you charge a convenience fee, it must be shown before the customer chooses how to pay, be the same across UPI, debit card, credit card and net banking, and, for payments through an aggregator, be displayed to the customer before the payment.
Can my store save customers' cards?
Not the card numbers. Under RBI's rules, only card issuers and card networks may store them. You can offer saved cards using tokens, which the customer creates with their consent and an OTP from their bank.
Why does my settlement amount differ from my day's sales?
Because settlements are net of the provider's fees and any refunds or chargebacks, can cover payments from more than one day, and exclude payments not yet captured or settled. Match your provider's settlement report to your orders by reference to see exactly what's included.
Go deeper
Official sources
- RBI — Reserve Bank of India (Regulation of Payment Aggregators) Directions, 2025 (15 Sep 2025)Escrow accounts and settlement to merchants 'as per the agreement' with transparent timelines (16); merchants' systems to meet security standards such as PCI-DSS (9(a)); charges displayed before payment (10(c)); refunds to the original method (10(f)); chargeback rights unaffected (18(h)).
- NPCI — UPI Consolidated Circular, Version 1.0, NPCI/UPI/CC/01 (18 Sep 2026)No surcharge on UPI; convenience fees disclosed upfront and consistent across debit modes (7.5); intent for app and mobile-web merchants and dynamic QR for other web merchants (7.6); pay by any UPI app (7.7).
- RBI — Restriction on Storage of Actual Card Data [i.e. Card-on-File (CoF)] (24 Jun 2022)From 1 October 2022, only card issuers and card networks may store card-on-file data.
- RBI — Tokenisation – Card Transactions: Permitting Card-on-File Tokenisation (CoFT) Services (7 Sep 2021)Tokens created with the customer's explicit consent and an additional factor of authentication.
- RBI — Harmonisation of Turn Around Time and customer compensation for failed transactions (20 Sep 2019)Reversal deadlines when a customer is debited but the merchant gets no confirmation.
Last reviewed . Examples, amounts and screens marked illustrative are not LILPE figures.
