UPI vs COD at Checkout: How to Build the Payment Options Section of Your Online Store

UPI vs COD at Checkout: How to Build the Payment Options Section of Your Online Store So Both Work Properly

Most Indian online stores should offer both UPI and Cash on Delivery, but the build matters more than the choice: put UPI first and make it work in one tap on mobile, keep COD available only where your rules allow it, show the final amount for each option before the customer commits, and make sure every payment outcome (paid, failed, pending, COD confirmed) updates the order correctly. This guide treats the payment-options block of a Shopify, WooCommerce or custom checkout as a piece of website engineering, with a specification you can hand to a developer. It is not a courier or payments-fee comparison; for the gateway side see our article on adding a payment gateway to your online store, and for COD rules and verification see building COD rules into your checkout.

Why UPI deserves first place on the page: it is how a very large share of Indian shoppers already pay. NPCI's published statistics, as reported in the press, put UPI at roughly 24 billion transactions in September 2026 alone (see NPCI statistics and secondary reporting; verify the latest month on NPCI's own page before quoting it). Familiarity is not the same as a smooth checkout, though. A store that sends a mobile shopper through a slow page, a confusing QR code on a phone, or a failed payment with no recovery loses orders that were already decided.

What the payment block has to do

Think of the payment section as five jobs.

1. Present the options in a sensible order with plain labels.
2. Collect payment with the least typing possible.
3. Handle failure and uncertainty without losing the cart.
4. Apply COD rules consistently and explain them.
5. Tell the store exactly what happened, so stock, invoices and messages are correct.

Everything below is detail on one of these.

Job 1: Presenting the options

Order and defaults

On mobile, list UPI first, then cards and netbanking, then COD, unless your data shows otherwise. Do not pre-select COD. Pre-selecting it nudges customers into the option with the highest return-to-origin risk, and any claim that a different order "converts better" should be tested on your own store, not taken from an article. Run a simple split test for a few weeks and compare completed, paid and delivered orders, not just checkout completion.

Labels and trust

Use the names customers know: "UPI (Google Pay, PhonePe, Paytm and other apps)", "Cards", "Netbanking", "Cash on Delivery". Show the amount payable under each option if it differs (for instance a COD handling fee or a prepaid discount) before the customer selects it, not after. Our article on checkout design that avoids dark patterns explains why surprise charges at the last step create legal and trust problems.

Prepaid incentives

If you offer a prepaid discount or a COD fee, state it plainly: "Pay online and save ₹X" or "COD handling charge ₹X". Make sure the charge is genuine cost recovery and is shown in the order summary before payment. Legal advice on pricing claims is for your own adviser.

Job 2: Making UPI work on a phone

The build differs for mobile and desktop.

• On mobile, use UPI intent (opening the customer's installed UPI app directly) where your gateway supports it, rather than asking for a UPI ID. Fewer keystrokes mean fewer abandoned payments. Offer "enter UPI ID" as a fallback.
• On desktop, offer a QR code with a clear instruction and a visible timer, plus the UPI ID collect option where your gateway supports it. Explain what happens next ("Approve the request in your UPI app").
• Keep the customer on a stable page. Opening the app and returning should land the shopper back on a page that shows the payment status, not an empty cart.
• Test in real apps on real phones: at least one budget Android handset, one recent iPhone, and the common UPI apps. Behaviour differs between apps and operating systems, and emulators miss it.
• Pay attention to speed. A slow payment step undermines everything; see our store speed and Core Web Vitals guide.

For recurring payments and subscriptions, UPI Autopay has its own rules, covered in building UPI Autopay into a checkout.

Job 3: Failure, pending and the double-charge fear

The most damaging checkout moment is "my money was deducted but the order failed". Design for it.

The key engineering rule is that the webhook from the payment provider, not the browser redirect, is the source of truth for whether an order is paid. Redirects can be lost when a customer closes a tab. Verify signatures on webhooks, make handling idempotent so a repeated webhook does not create two orders, and log every payment event. Our guide on keeping webhooks, orders and refunds in sync goes through this in detail.

Show the customer an honest message while a payment is pending, and send the order confirmation only after payment is confirmed. For COD, send it when the order is accepted.

Job 4: COD rules that the checkout enforces

COD should be a controlled option, not an open door. Decide the rules and implement them in the checkout so the page and the back office agree.

• Eligibility by PIN code, using the list your courier actually serves for COD. Show COD as unavailable (with the reason) for others rather than failing later.
• Order value limits. Set a minimum and maximum COD basket if your risk data supports it; confirm the numbers from your own order history, not a generic figure.
• Product exclusions. Customised, perishable or very high-value items may be prepaid only.
• Customer history. First-time buyers may face different rules from repeat buyers with successful deliveries; apply this transparently and carefully.
• Order verification. Confirm risky COD orders by WhatsApp or call before dispatch; the process is described in our COD verification guide and in reducing COD returns.
• Clear message at checkout: "Pay ₹X in cash to the delivery person. Please keep the exact amount ready."
• Bot and fake-order protection, which matters especially for COD because it needs no payment; see stopping fake orders and bot checkouts.

Implementation notes by platform: Shopify handles manual payment methods and can filter them with rules or apps; WooCommerce uses payment gateway conditions that plugins extend; custom builds apply a rules function that returns the available methods for a given cart and address. Whichever you use, run the same rules on the server at order creation, not only in the browser, or a customer can bypass them.

Job 5: Tell the store what happened

Every method should produce a consistent set of order states that downstream systems rely on.

• Paid online: paid, ready to pack.
• COD placed: awaiting verification, then confirmed.
• COD delivered and collected: payment collected, pending remittance from the courier.
• COD refused or not delivered: cancelled or returned, stock restored.
• Refunds: linked to the original payment, with their own status.

Store the payment method and gateway reference on the order so reports can separate COD from prepaid. This enables the two metrics that tell you whether your checkout is working: the share of orders prepaid, and the delivered-and-paid rate by method. Both are straightforward to produce once the data is stored properly. Our thank-you page and tracking guide shows how to avoid counting unpaid or failed orders as sales in analytics.

Mobile layout details that matter

• Put the payment options in one scrollable section with large tap targets.
• Keep the total price visible at all times.
• Use numeric keyboards for phone and PIN fields, and autofill for addresses.
• Support guest checkout; see checkout forms and guest checkout.
• Re-confirm the delivery address next to the COD option, since address errors are a major cause of failed COD deliveries.

RBI authentication and card payments

Card payments and some other methods are subject to RBI's authentication rules; the effect on checkout design is covered in what RBI's 2FA rules mean for your checkout. Your gateway handles most of this, but you should test cards that trigger extra authentication and make sure the customer returns to a clear status page.

A testing checklist

Run these on staging with the gateway's test mode, then once with a small real payment before launch.

1. UPI intent on Android and iPhone opens the app and returns to a status page.
2. UPI QR flow on desktop completes and updates the order.
3. A failed payment lets the customer retry or choose another method with the cart intact.
4. A pending payment shows a "do not pay again" message and resolves via webhook.
5. A repeated webhook does not create a duplicate order.
6. COD appears only for eligible PIN codes and values, with the right message.
7. A COD fee or prepaid discount appears before selection and in the order summary.
8. Order emails and messages are sent at the right moment for each method.
9. Reports split COD and prepaid correctly.
10. Refunds update the order and the customer message.

What to measure after launch

Track by payment method: checkout completion, payment failure rate and the reasons, share of prepaid orders, delivered-and-paid rate, refused COD rate, and support tickets about payment. Look at them weekly for the first month and after any change. If you change the order of options or the COD rules, change one thing at a time. Revisit the settings each quarter, because courier coverage and customer behaviour shift.

Frequently Asked Questions

Should an Indian online store offer both UPI and COD?

Most should, with UPI as the default and COD available under clear rules. UPI gives confirmed payment and fast settlement, while COD reaches customers who are not ready to pay online. Review the balance using your own delivered-and-paid data.

How do I stop customers paying twice when a UPI payment is pending?

Show a clear pending message that says not to pay again, keep the order in a pending state and update it only when the payment provider's webhook confirms the result. Send a resume link if the customer leaves the page.

Can I disable COD for certain PIN codes or products?

Yes. Apply rules by PIN code, order value or product type, and enforce them on the server at order creation as well as in the checkout page so they cannot be bypassed. Show customers why COD is unavailable.

Should the COD option be selected by default?

No. Leaving all methods unselected, or selecting UPI, avoids pushing customers into the highest-risk option. Test the effect on paid and delivered orders in your own store before changing it.

What should happen if money is debited but the order fails?

The store should match the gateway reference automatically, either confirming the order or refunding the payment within the window you state. Show the customer that window and a contact route, and log every payment event for reconciliation.

Sources and notes

UPI volumes: NPCI UPI statistics; the September 2026 figure of about 24 billion transactions comes from secondary reporting of NPCI data, StartupTalky, and should be checked against NPCI before reuse. Gateway behaviour (UPI intent, QR, webhooks) differs by provider, so follow your gateway's current documentation. This article updates an earlier piece on the same topic and keeps its original publication date.

Working with Govindani Infotech on checkout builds

Govindani Infotech is a Pune-based website design and development company at 2nd Floor, Landmark Plaza, 206 Satara Road, Parvati Paytha, Pune 411009. We build e-commerce stores and checkout systems with payment, WhatsApp and CRM integration.

To discuss your payment block, message us on WhatsApp at wa.me/919201958278 or use our contact page. We will tell you what a review covers before any price is discussed. See also our website creation services.

About the author: written by the Govindani Infotech e-commerce development team in Pune.