Secure Payment Gateway Integration for E-Commerce and SaaS Platforms

The Double Charge That Cost More Than the Order

An Indian e-commerce platform integrates a payment gateway. The integration works in testing. On launch day, a customer clicks "Pay" and the payment succeeds—but the browser times out before the confirmation page loads. The customer clicks again. The second request also succeeds. The customer is charged twice for the same order.

The customer complains. The support team refunds one charge. But the same bug affects dozens of orders in the first week. Refunds are processed manually. Reconciliation takes days. Some customers dispute the charges with their banks. The payment gateway charges fees on both transactions, and some of the refunds are not fully recovered.

This is the most common production failure in payment gateway integration, and it is preventable. The root cause is not the gateway. It is the integration: missing idempotency, unverified webhooks, and no reconciliation.

Secure payment gateway integration is the discipline of connecting an application to a payment gateway so that payments are processed securely, reliably, and correctly—even when networks fail, users retry, and webhooks arrive twice. It is not just calling an API. It is handling the failure modes that payments inevitably produce.

For Indian businesses, this matters because payments are the revenue moment. A failed payment is lost revenue. A double charge is a refund and a damaged relationship. A data leak is a regulatory penalty and reputational damage. The integration must be correct, secure, and compliant.

India adds specific considerations. PCI DSS applies to any system that handles card data—but the smart approach is to never handle card data at all, using hosted checkout or tokenisation. RBI tokenisation rules require card-on-file to use tokens, not stored card numbers. 3DS authentication is mandatory for card payments. UPI is the dominant payment method. RBI e-mandates govern recurring payments. And DPDPA applies to payment data.

This guide is written for Indian developers, CTOs, and product managers integrating payment gateways. We will cover the security architecture, the PCI DSS scope reduction, the tokenisation, the idempotency and webhooks, the reconciliation, real costs in rupees and dollars, DPDPA compliance, and a phased implementation framework with clear go/no-go gates.

The Security Architecture: Never Handle Card Data

The most important decision in payment gateway integration is how to handle card data. The answer for most businesses is: do not.

The PCI DSS Scope Problem

PCI DSS (Payment Card Industry Data Security Standard) applies to any system that stores, processes, or transmits card data. Compliance is expensive and ongoing. The scope determines the cost: a system that stores card numbers has a much larger scope than one that never sees them.

The scope reduction principle: Design the integration so that card data never touches your servers. Use hosted checkout, hosted fields, or tokenisation.

The Integration Approaches

1. Hosted checkout (redirect). The customer is redirected to the gateway's hosted page to enter card details. Your servers never see the card data. Simplest, lowest scope.

2. Hosted fields (iframe). The card fields are rendered by the gateway inside an iframe on your page. Your servers never see the card data, but the UX is on your page.

3. Direct API (server-to-server). Your servers receive the card data and send it to the gateway. Highest scope, highest risk. Avoid unless you have a specific reason.

4. Tokenisation. The card is tokenised (by the gateway or the card network), and you store the token, not the card. The token can be used for future charges.

The Integration Approach Table

The recommendation for Indian businesses: Use hosted checkout or hosted fields. Never handle card data directly. For recurring payments, use gateway tokenisation or RBI-compliant card tokens.

For teams building the payment integrations and checkout flows, our Custom Software Development and Website Development practices cover the full stack.

Tokenisation and RBI Rules

RBI Card Tokenisation

RBI requires that card-on-file data be tokenised. Merchants cannot store card numbers. Instead, the card is tokenised by the card network or the gateway, and the merchant stores the token.

How it works:

The customer enters card details on the gateway's hosted page.

The gateway tokenises the card and returns a token.

The merchant stores the token.

Future charges use the token.

The implication: Any recurring payment or saved card feature must use tokenisation. Storing card numbers is not compliant.

RBI E-Mandates

For recurring payments (subscriptions), RBI e-mandate rules apply:

Registration: the customer registers the mandate with their bank (via OTP or app).

Pre-debit notification: the merchant must notify the customer at least 24 hours before the charge.

Additional factor authentication (AFA): for charges above ₹15,000, the customer must authenticate.

Mandate limits: customers can set maximum amounts and frequencies.

The integration requirement: The payment gateway must support e-mandates, and the merchant must implement pre-debit notifications.

UPI Autopay

UPI Autopay is the UPI equivalent of e-mandates. It allows recurring UPI payments with a mandate. The integration must support UPI Autopay for subscription billing.

The Tokenisation Table

3DS Authentication: The Fraud Defence

3-D Secure (3DS) is an authentication protocol that adds a step to card payments—typically an OTP sent to the cardholder's phone. It shifts liability for fraud to the issuing bank.

3DS Versions

3DS 1.0: The original, with redirect to a bank page. High friction.

3DS 2.0: Risk-based authentication. Low-risk transactions may be frictionless; high-risk transactions require OTP.

3DS 2.2: Improved data sharing, better frictionless rates.

The Integration Considerations

1. Frictionless flow. 3DS 2.0 can authenticate without OTP for low-risk transactions, improving conversion.

2. Exemptions. Some transactions are exempt from 3DS (low-value, trusted beneficiary). The gateway handles this.

3. Liability shift. When 3DS is used and the transaction is authenticated, liability for fraud shifts to the issuing bank.

4. Fallback. If 3DS fails, the transaction may fall back to non-3DS (with liability on the merchant) or fail entirely.

The 3DS Table

Idempotency: The Defence Against Double Charges

Idempotency is the single most important reliability pattern in payment integration. It ensures that a retried request does not create a second charge.

The Problem

Networks fail. Users retry. Webhooks arrive twice. Without idempotency, each retry creates a new charge.

The Solution

Every payment request includes a unique idempotency key. The gateway stores the key and the result. If the same key arrives again, the gateway returns the stored result instead of creating a new charge.

The implementation:

Generate a unique key per payment attempt (e.g., order ID + attempt number).

Send the key in the request header.

Store the key on your side and the result.

The Webhook Problem

Webhooks are the gateway's notification that a payment succeeded or failed. Webhooks can arrive twice, out of order, or not at all. The integration must handle:

1. Duplicate webhooks. Verify that the payment has not already been processed before acting.

2. Out-of-order webhooks. A "payment succeeded" webhook may arrive before the "payment initiated" webhook. Handle by checking the current state.

3. Missed webhooks. Poll the gateway for payment status if a webhook does not arrive within a timeout.

4. Webhook verification. Verify the webhook signature to ensure it came from the gateway, not an attacker.

The Idempotency Table

Reconciliation: The Financial Control

Reconciliation is the process of matching your records against the gateway's records to ensure every payment is accounted for.

Why Reconciliation Matters

Detect missing payments. A payment succeeded at the gateway but was not recorded in your system.

Detect duplicate payments. A payment was charged twice.

Detect fee discrepancies. The gateway charged more than expected.

Support audits. Financial records must be accurate.

The Reconciliation Process

1. Daily settlement report. The gateway provides a daily report of settled transactions.

2. Match against internal records. Compare the gateway's transactions against your order records.

3. Investigate discrepancies. Missing, duplicate, or mismatched transactions are investigated.

4. Resolve. Refund duplicates, record missing payments, adjust fees.

The Reconciliation Table

Real Costs in India (2026)

Payment gateway integration costs have two components: gateway fees (per transaction) and integration development.

Gateway Fees

Integration Costs

The Cost of Failure

A double-charge bug can cost more than the integration. Each double charge requires a refund, a support ticket, and potentially a chargeback. At scale, this can be significant.

India-Specific Compliance: PCI DSS, RBI and DPDPA

PCI DSS

PCI DSS applies to any system that handles card data. Using hosted checkout or tokenisation reduces the scope dramatically. The remaining obligations include:

Secure transmission (TLS).

Access control.

Logging and monitoring.

RBI Rules

Tokenisation: card-on-file must be tokenised.

E-mandates: recurring payments require registration, pre-debit notification, and AFA.

Data localisation: payment system data must be stored in India.

DPDPA

Payment data is personal data. Under the DPDP Act:

Consent: customers consent to payment processing.

Data minimisation: store only what is needed (token, not card).

Retention: define retention for payment records.

Security: implement reasonable safeguards.

The Compliance Checklist

Implementation Framework: A Phased Approach With Cost Gates

Phase 1: Gateway Selection (Week 1–2)

Objective: Choose the gateway and integration approach.

Activities:

Evaluate gateways (fees, payment methods, features).

Choose integration approach (hosted checkout, fields).

Assess compliance requirements.

Plan the integration.

Cost: ₹0–₹50,000 ($0–$600).

Go/No-Go: Gateway chosen. Approach decided.

Phase 2: Basic Integration (Week 3–6)

Objective: Integrate the gateway with hosted checkout.

Activities:

Integrate hosted checkout.

Implement payment success/failure handling.

Implement webhook verification.

Implement idempotency.

Cost: ₹50,000–₹1.5 lakh ($600–$1,800).

Go/No-Go: Payments work. No double charges.

Phase 3: Tokenisation and Recurring (Week 7–12)

Objective: Add tokenisation and recurring payments.

Activities:

Implement tokenisation.

Implement e-mandates (if subscriptions).

Implement pre-debit notifications.

Test recurring charges.

Cost: ₹2–8 lakh ($2,400–$9,600).

Go/No-Go: Tokenisation works. Recurring works.

Phase 4: Reconciliation and Scale (Week 13–18)

Objective: Add reconciliation and scale.

Activities:

Implement daily reconciliation.

Implement chargeback handling.

Add multi-gateway routing (if needed).

Monitor and optimize.

Cost: ₹2–6 lakh ($2,400–$7,200).

Go/No-Go: Reconciliation matches. Disputes handled.

Phase Summary Table

Risks, Pitfalls, and Governance

The Most Common Payment Integration Failures

No idempotency. Double charges from retries. Mitigation: Idempotency keys.

Unverified webhooks. Attackers can send fake payment success notifications. Mitigation: Signature verification.

Storing card data. PCI DSS violation and data breach risk. Mitigation: Hosted checkout, tokenisation.

No reconciliation. Payments are lost or duplicated. Mitigation: Daily reconciliation.

Missing pre-debit notification. RBI violation. Mitigation: Notification implementation.

No e-mandate support. Recurring payments fail. Mitigation: Gateway integration.

Risk Summary Table

Benchmark Summary and Decision Framework

Decision Matrix: Integration Approach

Payment Security Priority Table

The One-Paragraph Decision Rule

If you are integrating a payment gateway, use hosted checkout or hosted fields—never handle card data directly. Implement idempotency keys on every payment request. Verify webhook signatures. Use tokenisation for recurring payments. Send pre-debit notifications for e-mandates. Reconcile daily. And ensure PCI DSS, RBI, and DPDPA compliance from day one.

Frequently Asked Questions

1. How much does payment gateway integration cost in India?

Hosted checkout integration costs ₹50,000–₹1.5 lakh ($600–$1,800). Hosted fields with tokenisation costs ₹1.5–4 lakh ($1,800–$4,800). Multi-gateway with reconciliation costs ₹4–10 lakh ($4,800–$12,000).

2. What are the gateway fees?

Razorpay, PayU, and Stripe charge 2% + GST on cards, with UPI typically free. Cashfree charges 1.9–2% + GST.

3. Do I need PCI DSS compliance?

If you handle card data, yes. Using hosted checkout or tokenisation reduces the scope dramatically.

4. What is idempotency and why does it matter?

Idempotency ensures a retried payment request does not create a second charge. It is the most important reliability pattern in payment integration.

5. What is tokenisation?

Tokenisation replaces the card number with a token. RBI requires tokenisation for card-on-file. You store the token, not the card.

6. What are RBI e-mandates?

Rules for recurring payments. They require registration, 24-hour pre-debit notification, and AFA for charges above ₹15,000.

7. What is 3DS authentication?

3-D Secure is an authentication protocol that adds a step (usually OTP) to card payments. It shifts fraud liability to the issuing bank.

8. How do I verify webhooks?

Verify the webhook signature using the secret provided by the gateway. Reject unsigned or incorrectly signed webhooks.

9. What is reconciliation?

Matching your records against the gateway's settlement report to detect missing, duplicate, or incorrect transactions.

10. How does DPDPA affect payment integration?

Payment data is personal data. Consent, data minimisation (store tokens, not cards), retention policies, and security apply.

11. Which gateway should I use in India?

Razorpay for most businesses, PayU for enterprise, Cashfree for payouts and subscriptions, Stripe for global sales.

12. How can Innovative AI Solutions help?

Innovative AI Solutions builds secure payment gateway integrations for Indian e-commerce and SaaS—hosted checkout, tokenisation, e-mandates, idempotency, reconciliation, and PCI DSS/RBI/DPDPA compliance. Our Delhi-based team handles design, implementation, and security review. Visit https://innovativeais.com to discuss your requirements.

Contact Innovative AI Solutions

Ready to accept payments safely, reliably, and compliantly?

[One-line supporting sentence.]

Contact Information

Innovative AI Solutions

📍 Netaji Subhash Place, Pitampura, Delhi – 110034

🌐 Website: https://innovativeaislabs.com 📧 Email: info@innovativeais.com

📞 Phone: +91 7464 099 059 / +91 96899 67356

Business Services

AI Automation

AI Development

AI Consulting

Machine Learning Solutions

Deep Learning Solutions

Generative AI Services

NLP Solutions

AI Agents

AI Chatbots

Voice AI

CRM Development

Custom Software Development

Website Development

Mobile App Development

About the Author

Abhishek Kumar

Founder & CEO, Innovative AI Solutions

5+ years building production AI systems for Indian businesses. Based in Delhi, serving clients across India.

Ready to build AI solutions for your business?

Innovative AI Solutions — Delhi's leading AI development company. Free consultation available.

Get Free Consultation →

A practical 2026 guide for Indian developers integrating payment gateways—PCI DSS scope reduction, tokenisation, 3DS, idempotency, webhook verification, reconciliation, real rupee costs, and RBI/DPDPA compliance. #PaymentGatewayIntegration #SecurePayments #PCIDSS #Tokenisation #RBITokenisation #3DSAuthentication #Idempotency #PaymentWebhooks #Razorpay #PayU #Cashfree #Stripe #UPI #EMandate #Reconciliation #DPDPA #MeitY #DelhiNCR #InnovativeAISolutions

Copyright ©️ 2015–2026 Innovative AI Solutions. All Rights Reserved. | Privacy Policy | Terms & Conditions