Payment Gateways for WooCommerce in India

The payment methods an Indian store needs are not the same as a US or European one, and a gateway chosen without that in mind will underperform regardless of its other qualities.

• UPI, which is the default for a very large share of online payments. If UPI is missing, slow or badly implemented, you will feel it in the conversion rate.
• Debit and credit cards, with the tokenisation and additional authentication that current RBI rules require.
• Net banking, still widely used for larger amounts.
• Wallets, which vary in importance by audience.
• EMI options for higher-value carts, which meaningfully change conversion in some categories.
• Cash on delivery, still expected in many categories — and a business decision as much as a payment one.

• Does its WooCommerce plugin get updated regularly, and does it support current WooCommerce versions? An abandoned gateway plugin is a checkout that breaks at the next Woo release.
• Does it keep the customer on your site, or redirect them off and back? Redirect flows lose more people, particularly on mobile browsers that handle the return badly.
• How are failed and pending payments communicated back to WooCommerce? A gateway that leaves orders stuck in 'pending' with no webhook is a permanent source of support tickets.
• What's the settlement cycle, and are there setup or annual fees on top of the transaction rate?
• What's the refund process, and can it be done from the WooCommerce order screen or only in the gateway's dashboard?
• What does support look like when something is wrong at 9pm during a sale?

Most payment problems trace back to the gateway and WooCommerce disagreeing about what happened. The customer paid, the browser closed before returning, and the order sits unpaid while the money has left their account.

The fix is server-to-server notification: the gateway calls your site directly to confirm the payment, independently of whether the customer's browser made it back. Make sure the gateway supports this, that it's configured, and that the endpoint is reachable — a security plugin or firewall blocking the callback URL is a common and baffling cause of stuck orders.

Verify the webhook signature. An unverified payment callback is an endpoint that will happily mark orders paid for anyone who finds it.

• A failed payment should return the customer to a checkout that still has their details, with a clear message and an obvious way to try again or choose another method.
• Never clear the cart on a failed payment.
• Distinguish between declined, cancelled and timed out, so the message is accurate. 'Your bank declined this' and 'the payment timed out' call for different next steps.
• Set up a retry path that doesn't create a duplicate order.
• Monitor the failure rate by method. A sudden rise in one method usually means a gateway-side problem, not a customer-side one.

COD is still expected in a lot of Indian categories, and refusing it costs orders. It also carries real costs: higher return rates, cash handling, and the risk of orders placed casually and refused on arrival.

If you offer it, do it deliberately. Restrict it by order value, by PIN code where your courier supports it, or by product category. Consider an OTP confirmation step on COD orders to filter out casual ones. Charge a handling fee if the economics need it, and disclose it before the payment step.

Track COD return rates separately from prepaid ones. They are different businesses and blending them hides the problem.

Card storage and recurring payments are governed by RBI rules that change periodically, and the practical implications land in your gateway's plugin rather than in your code. Keeping the plugin updated is how you stay compliant, which is another reason maintenance status matters more than fees.

You'll also need GST-compliant invoicing, which WooCommerce doesn't do natively. Set that up before launch — retrofitting sequential invoice numbering onto existing orders is genuinely unpleasant.

Make sure your refund and cancellation policy is on the site and reachable from the checkout. Most gateways require it, and customers look for it before paying.

Nearly everyone tests one successful card payment and calls it done. The failures are where the money goes.

• Successful payment with each method you offer — including UPI on an actual phone, not a desktop emulation.
• Declined card, cancelled payment, and a payment abandoned mid-flow by closing the browser.
• A payment that succeeds at the gateway while the customer never returns to the site — then confirm the webhook marked the order paid.
• A refund, both full and partial, initiated from WooCommerce.
• Checkout on a mid-range Android phone on mobile data, which is how most of your customers will pay.
• The whole flow again after every gateway plugin update and every major WooCommerce update.

A second gateway is genuine insurance: when one has an outage — and they all do — you can switch rather than stop trading. It also lets you offer a method the primary gateway handles poorly.

The cost is another plugin in your checkout, another set of updates, and reconciliation across two dashboards. For a store where a day of downtime matters, that's clearly worth it. For a small store, one well-chosen gateway and a tested fallback plan is usually enough.