WooCommerce Payment Gateway Integration: Stripe vs Razorpay

Payment gateway integration is where WooCommerce projects get serious: real money, real customer trust, and real consequences when something is misconfigured. Having integrated both Stripe and Razorpay on production stores — for clients selling internationally and within India — here is a practical comparison and the integration lessons that only show up after go-live.

Stripe vs Razorpay: Choose by Market, Not by Features

The decision is simpler than most comparisons make it. Stripe is the default choice for stores selling to customers in North America, Europe, and most international markets: superb developer experience, clean documentation, strong subscription support, and Apple Pay / Google Pay built in. Razorpay is the default for stores selling primarily in India: native UPI support (which dominates Indian online payments), netbanking across every major bank, EMI options, and settlement in INR without currency friction.

• Selling internationally? Stripe, almost without exception.
• Selling in India? Razorpay — UPI alone decides it. A checkout without UPI loses Indian customers at the payment step.
• Both markets? Run both gateways side by side and let WooCommerce show the right options; both official plugins coexist happily.

Fees are comparable (roughly 2% + fixed fee per transaction, varying by card type and country), so market fit — not pricing — should drive the choice.

Integration: the Right Way for Each

Both providers ship official WooCommerce plugins, and you should use them — custom gateway code is for genuinely custom needs, not for standard checkouts. The real work is configuration:

1. Create restricted API keys. Never paste full-access keys into WordPress. Stripe supports restricted keys; generate them with only the permissions the plugin needs.
2. Configure webhooks properly. This is the step most DIY setups miss. Without webhooks, an order can be paid at the gateway while WooCommerce still shows it as pending — usually discovered when a customer emails asking where their order is. Register the webhook endpoint, subscribe to payment events, and verify the signing secret.
3. Test the failure paths, not just success. Use test cards for declined payments, 3D Secure challenges, and abandoned checkouts. Both gateways provide test card numbers for every scenario — use all of them before launch.
4. Verify order status transitions. Paid orders should move to Processing, failed payments should restock inventory, and refunds issued in the gateway dashboard should sync back to WooCommerce.

Security Is Mostly About What You Don't Do

Modern integrations keep card data entirely off your server — Stripe Elements and Razorpay Checkout render the sensitive fields inside their own iframes, which keeps you in the lightest PCI compliance scope (SAQ A). Your responsibilities are the surrounding hygiene: HTTPS everywhere with HSTS, API secrets stored outside version control, webhook signatures verified on every event, and WordPress itself kept updated — because the most common "payment hack" is actually a compromised WordPress admin, not a gateway breach. That last part is exactly why ongoing website maintenance matters more on ecommerce sites than anywhere else.

Subscriptions and Recurring Billing

Recurring revenue changes the integration calculus. With Stripe + WooCommerce Subscriptions, tokenized cards renew automatically, failed renewals retry on a schedule you control, and customers can update payment methods from their account page — it is the most battle-tested recurring stack in WooCommerce. With Razorpay, recurring card payments in India carry an extra wrinkle: RBI's e-mandate rules require customer authentication for auto-debits, and UPI Autopay has per-transaction limits. It works, but design the billing model around those constraints from day one rather than discovering them after launch — a subscription product priced above the auto-debit limit will fail renewals in ways that look like random churn.

Multi-Currency and Cross-Border Selling

If a store prices in more than one currency, decide early where conversion happens. Stripe can present and settle in dozens of currencies, but settlement currency conversions carry fees — a store selling in USD/EUR/GBP should ideally hold balances or accounts in those currencies. Razorpay supports international cards on an Indian entity, but expect higher decline rates on foreign cards and factor that into checkout analytics before concluding your checkout is broken. In both cases, display prices in the customer's currency: currency surprise at the payment step is one of the most reliable cart-abandonment triggers I have measured.

Refunds, Disputes, and the Admin Reality

Plan for the unhappy paths because they arrive with the first hundred orders. Wire refunds so they are issued from WooCommerce (both official plugins support it) — refunding only in the gateway dashboard leaves order status and stock out of sync. For chargebacks, respond inside the deadline with evidence: order confirmation, delivery tracking, and communication history win a meaningful share of disputes if actually submitted. On Stripe, turn on Radar's rules for obviously risky patterns; on Razorpay, enable the equivalent risk checks. And log every webhook event the store receives — when a payment dispute lands weeks after the order, that log is how you reconstruct what happened.

Testing Webhooks Without Guesswork

Webhooks fail silently, so test them deliberately. The Stripe CLI (stripe listen --forward-to localhost/wc-api/...) replays live-shaped events against your development store; Razorpay's dashboard can fire test webhooks per event type. Verify three things: the signature check rejects tampered payloads, duplicate events do not double-process an order (both gateways redeliver on timeout), and the endpoint responds within the timeout window — a webhook handler that triggers slow emails synchronously will time out, get retried, and double-send.

The Go-Live Checklist I Actually Use

• Live API keys in place, test keys removed, restricted permissions confirmed
• Webhook endpoint registered against the live environment and firing (test-mode webhooks do not carry over)
• One real transaction with a real card, refunded immediately afterward
• Order confirmation and failed-payment emails rendering correctly
• Currency, taxes, and shipping calculating correctly at checkout
• Checkout tested on a real phone over mobile data — not just desktop DevTools

Final Thoughts

Both Stripe and Razorpay are excellent; the mistake is not choosing the "wrong" one but configuring either one halfway. Webhooks, failure-path testing, and a real live transaction before launch separate stores that quietly lose orders from stores that just work. If you would rather have the whole thing — gateway setup, webhooks, testing, and launch — handled professionally, payment integration is a core part of my ecommerce development services.