{"id":28028,"date":"2026-10-07T11:43:52","date_gmt":"2026-10-07T06:13:52","guid":{"rendered":"https:\/\/razorpay.com\/blog\/?p=28028"},"modified":"2026-10-07T11:45:14","modified_gmt":"2026-10-07T06:15:14","slug":"payment-gateway-tokenisation-encryption-india","status":"publish","type":"post","link":"https:\/\/razorpay.com\/blog\/payment-gateway-tokenisation-encryption-india\/","title":{"rendered":"Payment Gateway Tokenisation and Encryption in India 2026: The Complete Card and Customer Data Checklist"},"content":{"rendered":"<p>Payment gateway tokenisation replaces saved card numbers with network tokens, while encryption protects data during transmission and authorised storage. In India, merchants should assess these controls alongside customer consent, access controls and responsibility for customer data. <a href=\"https:\/\/razorpay.com\/docs\/security\/\">Razorpay<\/a> documents card-on-file tokenisation through <a href=\"https:\/\/razorpay.com\/card-tokenisation\/\">TokenHQ<\/a>, PCI DSS Level 1 certification and HTTPS\/TLS protection. This checklist helps you verify those controls across your checkout, logs, and customer-data systems.<\/p>\n<div style=\"border-left: 4px solid #007BFF; background: #f0f8ff; padding: 25px; margin: 30px 0; font-family: Arial, sans-serif; text-align: left;\">\n<h3 style=\"margin-top: 0; color: #007bff; font-size: 22px;\">Key Takeaways<\/h3>\n<ul style=\"margin: 15px 0; padding-left: 20px; color: #333; line-height: 1.6;\">\n<li>Tokenisation and encryption serve different purposes: tokens replace saved-card credentials; encryption protects data where it is transmitted or legitimately retained.<\/li>\n<li>RBI\u2019s card-on-file framework restricts storage of actual card credentials by merchants and payment aggregators.<\/li>\n<li>Merchants and their payment service providers must not retain CVV after authorisation, even if encrypted.<\/li>\n<li>Razorpay TokenHQ supports network tokenisation for saved-card payments.<\/li>\n<li>Use securely configured TLS and assess encryption, access controls and key management separately.<\/li>\n<li>Your PCI DSS assessment depends on your integration and responsibilities. A provider\u2019s certification does not certify your entire business.<\/li>\n<li>Customer names, contact details and addresses need their own protection, retention and access controls.<\/li>\n<li>Assess DPDP obligations against their applicable commencement dates rather than treating all provisions as already operational.<\/li>\n<\/ul>\n<\/div>\n<h2>How Razorpay TokenHQ Supports Secure Saved-Card Payments in India<\/h2>\n<p>Razorpay TokenHQ is a multi-network card-on-file tokenisation solution developed with Visa, Mastercard and RuPay. It helps businesses offer saved-card payments using tokens instead of retaining actual card credentials. <a href=\"https:\/\/razorpay.com\/newsroom\/razorpay-launches-tokenhq-indias-first-multi-network-tokenisation-solution-in-partnership-with-mastercard-rupay-and-visa\/\">Razorpay TokenHQ announcement<\/a>.<\/p>\n<p>Evaluate tokenisation alongside transport security, personal-data protection and the responsibilities that remain with your business.<\/p>\n<div>\n<div>\n<div>\n<table>\n<thead>\n<tr>\n<th>Control<\/th>\n<th>What Razorpay publicly documents<\/th>\n<th>What your business should verify<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Saved-card tokenisation<\/td>\n<td>TokenHQ and support for tokenised saved-card payments<\/td>\n<td>Supported networks, customer consent and the authentication flow<\/td>\n<\/tr>\n<tr>\n<td>Payment security certification<\/td>\n<td>PCI DSS Level 1 certification<\/td>\n<td>Current evidence and the services covered<\/td>\n<\/tr>\n<tr>\n<td>Data transmission<\/td>\n<td>HTTPS using TLS<\/td>\n<td>Your integration and secure transport configuration<\/td>\n<\/tr>\n<tr>\n<td>Customer information<\/td>\n<td>Field-level encryption for sensitive PII<\/td>\n<td>Which fields and services are covered<\/td>\n<\/tr>\n<tr>\n<td>Multiple gateways<\/td>\n<td>Support for processing tokens through other gateways<\/td>\n<td>Supported routing, setup and migration conditions<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<\/div>\n<\/div>\n<h3><strong>What changes in your integration?<\/strong><\/h3>\n<p>Razorpay\u2019s product page describes different arrangements for Standard Checkout, custom checkout, and server-to-server integrations. Confirm the requirements for your setup before implementation. Cross-gateway token use should also be verified against the supported configuration rather than assumed to work automatically.<\/p>\n<h2>What Exactly Are You Allowed to Store? The RBI Card Data Rule in Plain Terms<\/h2>\n<p>Under RBI\u2019s card-on-file framework, entities other than card issuers and card networks must not retain actual card-on-file data. For tracking and reconciliation, permitted limited information includes the last four digits of the card number and the issuer\u2019s name. This storage restriction is separate from PCI DSS rules governing sensitive authentication data.<\/p>\n<h3>What data can appear on your dashboard, logs, or CRM?<\/h3>\n<p><strong>Limited card identifiers:<\/strong> Retain only identifiers permitted for your use case, such as the last four digits and issuer name.<\/p>\n<p><strong>Operational records:<\/strong> Transaction IDs, amounts, timestamps, and token references require appropriate access controls and retention policies. Their presence does not justify retaining raw card credentials.<\/p>\n<p><strong>Sensitive authentication data:<\/strong> Merchants and their payment service providers must not retain CVV after authorisation, even when encrypted. Prevent it from appearing in logs, screenshots, support tickets, or exports.<\/p>\n<h3>What if you still hold card data stored before October 2022?<\/h3>\n<p>Card data stored before the mandate had to be purged. If a legacy database, backup snapshot, or analytics warehouse still holds raw card numbers, that is a live compliance exposure, not a historical one. Run a discovery scan across production databases, backups, warehouses, and log archives, then document what you found and deleted.<\/p>\n<h3>Where raw PAN commonly hides<\/h3>\n<p>Check application debug logs, API request-body capture, APM tooling, CDN, WAF and proxy logs, session replay recordings, support screenshots, internal chat attachments, CRM free-text notes, CSV exports in cloud storage, and pre-2022 backup snapshots.<\/p>\n<blockquote><p><strong>DID YOU KNOW:<\/strong> Encrypting a CVV does not make post-authorisation storage permissible for a merchant or its payment service provider.<\/p><\/blockquote>\n<h2>How Does Network Tokenisation Actually Work, and Why Does RBI Require It?<\/h2>\n<p>Network tokenisation substitutes a payment token for actual card credentials. In a correctly implemented hosted checkout, the business can process a saved-card payment using a token reference without retaining the customer\u2019s raw card number. Confirm the data flow for your integration, including what reaches your servers, logs, and third-party tools.<\/p>\n<h3>Network tokenisation versus gateway tokenisation<\/h3>\n<div>\n<div>\n<div>\n<table>\n<thead>\n<tr>\n<th>Factor<\/th>\n<th>Network tokenisation<\/th>\n<th>Internal gateway tokenisation<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Token arrangement<\/td>\n<td>Operates through the supported card-network tokenisation framework<\/td>\n<td>Uses a provider\u2019s internal reference or token system<\/td>\n<\/tr>\n<tr>\n<td>RBI saved-card evaluation<\/td>\n<td>Verify compliance with the applicable card-on-file framework<\/td>\n<td>An internal reference alone does not establish compliance<\/td>\n<\/tr>\n<tr>\n<td>Card reissue or expiry<\/td>\n<td>Lifecycle support depends on the network and implementation<\/td>\n<td>Behaviour depends on the provider\u2019s underlying architecture<\/td>\n<\/tr>\n<tr>\n<td>Use with another gateway<\/td>\n<td>Depends on supported routing and token arrangements<\/td>\n<td>Depends on provider capabilities and migration support<\/td>\n<\/tr>\n<tr>\n<td>What to request<\/td>\n<td>Network coverage, consent flow and lifecycle documentation<\/td>\n<td>Explanation of what the token represents and where actual credentials are held<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<\/div>\n<\/div>\n<p>A provider may expose an internal reference while using network tokenisation underneath. Ask how the complete flow works rather than judging compliance from the name of the token returned by an API.<\/p>\n<blockquote><p><strong>PRO-TIP:<\/strong> Ask your provider to document the token type, supported networks, card-reissue handling and cross-gateway routing. Test these scenarios before relying on them in production.<\/p><\/blockquote>\n<h2>What Must You Encrypt, and What Does PCI DSS Actually Require?<\/h2>\n<p>PCI DSS requires strong cryptography where applicable, but does not prescribe a specific TLS version. For implementation, use securely configured TLS 1.2 or TLS 1.3, disable vulnerable protocols and cipher suites, and regularly review the configuration. Assess encryption at rest according to the data, system, and applicable requirements.<\/p>\n<h3>Encryption in transit<\/h3>\n<ul>\n<li>Use securely configured TLS 1.2 or TLS 1.3.<\/li>\n<li>Disable SSL and vulnerable TLS configurations, including TLS 1.0 and TLS 1.1.<\/li>\n<li>Review cipher suites, certificate validity, and downgrade protection.<\/li>\n<li>Test the actual configuration rather than relying on the browser\u2019s padlock.<\/li>\n<\/ul>\n<h3>Encryption at rest: what remains after tokenisation?<\/h3>\n<ul>\n<li>Transaction records and settlement data<\/li>\n<li>Masked card references and token reference IDs<\/li>\n<li>Customer names, email addresses, and phone numbers<\/li>\n<li>Shipping and billing addresses<\/li>\n<li>Order history<\/li>\n<li>Refund, <a href=\"https:\/\/razorpay.com\/dispute-guide\">dispute, and chargeback<\/a> records<\/li>\n<\/ul>\n<p>These records can remain sensitive after card tokenisation. Assess encryption, access restrictions, masking and retention for each dataset. Customer information does not automatically fall within PCI DSS scope simply because it relates to a payment.<\/p>\n<h3>Key management<\/h3>\n<p>Encryption depends on protecting the keys as well as the data. Restrict key access, separate permissions for encrypted records and key operations, and document generation, rotation, revocation and recovery. Evaluate managed key services or HSM-backed controls according to the system\u2019s requirements. Ask your provider which controls apply to the specific service you use.<\/p>\n<h2>Where Does Your Responsibility End and Your Payment Gateway&#8217;s Begin?<\/h2>\n<p>Security responsibilities follow the actual integration. Your provider operates its payment infrastructure; your business must secure its website, credentials, and customer-data systems. Document the boundary and confirm your assessment scope.<\/p>\n<div>\n<div>\n<div>\n<table>\n<thead>\n<tr>\n<th>Provider controls to verify<\/th>\n<th>Merchant controls to implement<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Certification and service scope<\/td>\n<td>Confirm the appropriate PCI assessment with your acquirer or assessor<\/td>\n<\/tr>\n<tr>\n<td>Tokenisation and payment-data handling<\/td>\n<td>Prevent unnecessary card-data capture in business systems<\/td>\n<\/tr>\n<tr>\n<td>Secure payment interfaces<\/td>\n<td>Implement the integration according to provider instructions<\/td>\n<\/tr>\n<tr>\n<td>Encryption within the provider\u2019s services<\/td>\n<td>Protect customer records in your CRM, helpdesk and analytics tools<\/td>\n<\/tr>\n<tr>\n<td>Account and integration security features<\/td>\n<td>Secure dashboard access, API credentials and application permissions<\/td>\n<\/tr>\n<tr>\n<td>Payment-page protections supplied by the provider<\/td>\n<td>Address applicable website and script-security responsibilities<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<\/div>\n<\/div>\n<p>Using a validated provider can reduce your assessment scope when the integration meets the relevant criteria. It does not remove your remaining responsibilities.<\/p>\n<h2>The PCI DSS v4.0.1 Checklist: Scripts, Tamper Detection, and SAQ Scope<\/h2>\n<p>Payment-page security includes managing scripts and detecting unauthorised changes. Determine which requirements and assessment criteria apply to your integration, and retain evidence that the relevant controls operate.<\/p>\n<h3>Requirement 6.4.3: unauthorised third-party scripts<\/h3>\n<p>Where applicable, manage payment-page scripts through authorisation, integrity assurance and an inventory with justification for their use. Select controls suited to the scripts and checkout architecture. Subresource Integrity can support integrity checking for suitable scripts; it is not a universal requirement to place an SRI hash on every external script.<\/p>\n<h3>Requirement 11.6.1: silent checkout modification<\/h3>\n<p>Where applicable, implement change and tamper detection for payment-page content and security-impacting HTTP headers as received by the browser. Assign responsibility for reviewing alerts and responding. A Content Security Policy can support browser security, but should not be presented as automatically satisfying the complete detection requirement.<\/p>\n<h3>Do 6.4.3 and 11.6.1 apply to your SAQ?<\/h3>\n<p>Requirements 6.4.3 and 11.6.1 are included in SAQ A-EP and SAQ D. The revised SAQ A addresses script security through an eligibility criterion for merchants embedding a third-party payment form. PCI SSC explains that this particular criterion does not apply to redirects or fully outsourced payment-link flows. Confirm the assessment and evidence required for your implementation.<\/p>\n<h3><strong>Which assessment applies to your business?<\/strong><\/h3>\n<p>Your payment brand and acquirer determine validation requirements. Transaction volume, integration architecture, and other factors can affect the assessment. Obtain written confirmation rather than selecting a level solely from a generic volume table.<\/p>\n<h2>How Authentication and Recurring Payments Fit Into Tokenisation<\/h2>\n<p>Tokenisation, customer authentication, and recurring-payment mandates are separate controls. A saved token does not automatically authorise a payment or establish consent for future debits.<\/p>\n<p><strong>For each payment flow, ask your provider:<\/strong><\/p>\n<ul>\n<li>How is consent to save the card captured?<\/li>\n<li>Which authentication steps apply when creating or using a token?<\/li>\n<li>How are recurring mandates registered, modified, and withdrawn?<\/li>\n<li>What notifications and transaction limits apply?<\/li>\n<li>What happens after card expiry, reissue or token deletion?<\/li>\n<\/ul>\n<p>Keep the answers with your integration documentation and test the relevant customer journeys. Verify applicable regulatory requirements separately for domestic, cross-border and recurring transactions.<\/p>\n<h3>Beyond Card Data: What Do DPDP Rules 2025 Mean for Your Customer Data Checklist?<\/h3>\n<p>The Digital Personal Data Protection Rules, 2025 have phased commencement. The operational provisions concerning security safeguards and breach notification come into force eighteen months after Gazette publication. Map your obligations to the applicable commencement provisions rather than using one blanket \u201cfull compliance\u201d deadline.<\/p>\n<h3>Does tokenising card data satisfy your DPDP obligations?<\/h3>\n<p>No. Card tokenisation does not protect every customer name, address, phone number or support record. Map personal-data collection, access, sharing and retention separately.<\/p>\n<p>Once Rule 7 is operative, it requires notification to affected individuals and the Board without delay, followed by detailed information to the Board within 72 hours of becoming aware of the breach, unless an extension is permitted.<\/p>\n<h3>What customer data still needs mapping?<\/h3>\n<p>Customer names, phone numbers and email addresses, shipping and billing addresses, order history, support ticket contents, behavioural and analytics data, and device identifiers. Review your own <a href=\"https:\/\/razorpay.com\/privacy-policy\">privacy policy<\/a> commitments against what you actually collect.<\/p>\n<h3>Build one incident runbook<\/h3>\n<table>\n<thead>\n<tr>\n<th>Clock<\/th>\n<th>Trigger<\/th>\n<th>Owner<\/th>\n<th>Evidence to retain<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>CERT-In<\/td>\n<td>Relevant cyber incident<\/td>\n<td>Security and incident-response lead<\/td>\n<td>Detection time, systems affected, containment, acknowledgement<\/td>\n<\/tr>\n<tr>\n<td>DPDP, when applicable<\/td>\n<td>Awareness of a personal-data breach<\/td>\n<td>Privacy lead and legal counsel<\/td>\n<td>Initial notifications, detailed Board update, remediation and applicable timing<\/td>\n<\/tr>\n<tr>\n<td>Acquirer and card network<\/td>\n<td>Card-data or payment-flow incident<\/td>\n<td>Payments lead<\/td>\n<td>Acquirer notice, network instructions, forensic evidence<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<blockquote><p><strong>PRO-TIP:<\/strong> Review payment and personal-data flows together, then record the requirements that apply to each dataset.<\/p><\/blockquote>\n<h2>Your Vendor Due-Diligence Checklist: What to Ask Any Payment Gateway Before You Sign<\/h2>\n<p>Request their current PCI DSS Attestation of Compliance with its expiry date, confirm in writing whether they issue network tokens or only internal gateway tokens, and verify their RBI authorisation status and cyber resilience tier.<\/p>\n<ol>\n<li>Current PCI DSS Attestation of Compliance, with expiry date<\/li>\n<li>Network tokenisation support for Visa, Mastercard, and RuPay, in writing<\/li>\n<li>RBI Payment Aggregator authorisation status<\/li>\n<li>TLS version and cipher suites in production<\/li>\n<li>HSM-backed key management and documented rotation schedule<\/li>\n<li>Webhook signing and replay protection<\/li>\n<li>FIU-IND registration and STR filing process under PMLA<\/li>\n<li>Cyber resilience compliance tier and applicable deadline<\/li>\n<li>Dashboard role-based access controls and MFA enforcement<\/li>\n<li>Token portability and migration path if you switch providers<\/li>\n<li>Payment data localisation architecture, including where logs and backups reside<\/li>\n<\/ol>\n<blockquote><p><strong>DID YOU KNOW:<\/strong> RBI&#8217;s Master Directions on Cyber Resilience apply in phases: large non-bank PSOs from 1 April 2025, medium from 1 April 2026, small from 1 April 2028.<\/p><\/blockquote>\n<h2>Does Tokenisation Hurt Checkout Conversion? Separating the Myth From the Data<\/h2>\n<p>No. Network tokenisation operates invisibly behind the saved-card experience. India adopted it at scale, with over 56 crore tokens supporting transactions worth more than Rs 5 lakh crore at RBI&#8217;s October 2023 review point.<\/p>\n<p>19% of shoppers abandon carts over card data trust concerns, so a visibly secure checkout protects conversion. Expect one genuine change: customers may re-authenticate a saved card after a reissue where lifecycle updates are unavailable.<\/p>\n<h2>Your 2026 Tokenisation and Encryption Checklist: The Full Printable List<\/h2>\n<p><strong>Card data rules<\/strong><br \/>\n&#8211; [ ] Confirm no full PAN, CVV, or expiry exists anywhere, including backups and log archives<br \/>\n&#8211; [ ] Verify only last four digits, network, and issuer appear on dashboards and in your CRM<br \/>\n&#8211; [ ] Confirm saved cards use network tokens, not gateway tokens alone<br \/>\n&#8211; [ ] Scan logs, session replay, screenshots, and CSV exports for raw card data<\/p>\n<p><strong>Encryption<\/strong><br \/>\n&#8211; [ ] TLS 1.2 minimum, TLS 1.3 preferred, on every payment page<br \/>\n&#8211; [ ] AES-256 or equivalent for all permitted stored data<br \/>\n&#8211; [ ] Keys managed separately from data, with a documented rotation schedule<\/p>\n<p><strong>PCI DSS v4.0.1<\/strong><br \/>\n&#8211; [ ] Documented script inventory for the checkout page (6.4.3)<br \/>\n&#8211; [ ] Subresource Integrity hashes on all external scripts<br \/>\n&#8211; [ ] Tamper detection and alerting configured, with a named owner (11.6.1)<br \/>\n&#8211; [ ] Confirm which SAQ and level applies, and that your attestation is current<\/p>\n<p><strong>Vendor due diligence<\/strong><br \/>\n&#8211; [ ] All eleven due-diligence items verified and documented<\/p>\n<p><strong>DPDP and customer data<\/strong><br \/>\n&#8211; [ ] Personal data flows mapped across CRM, helpdesk, and analytics<br \/>\n&#8211; [ ] Breach runbook covers CERT-In, the DPDP 72-hour report, and payment partners<br \/>\n&#8211; [ ] Consent and data retention policies reviewed<\/p>\n<p><strong>Dates in force<\/strong><br \/>\n&#8211; [ ] 31 March 2025: PCI DSS future-dated requirements mandatory<br \/>\n&#8211; [ ] 1 April 2026: Authentication Mechanisms Directions compliance<br \/>\n&#8211; [ ] 21 April 2026: E-Mandate Framework, 2026 in effect<br \/>\n&#8211; [ ] 1 October 2026: cross-border card-not-present requirement<br \/>\n&#8211; [ ] 13 May 2027: DPDP Rules full compliance<br \/>\n&#8211; [ ] 1 April 2028: small non-bank PSO cyber resilience phase<\/p>\n<h2>Why Razorpay Is Built for This Checklist, Not Just Compliant With It<\/h2>\n<table>\n<thead>\n<tr>\n<th>Control area<\/th>\n<th>What Razorpay provides<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Regulatory standing<\/td>\n<td>RBI-authorised Payment Aggregator since December 2023, subject to RBI audits and escrow requirements<\/td>\n<\/tr>\n<tr>\n<td>Card data<\/td>\n<td>PCI DSS Level 1 certified infrastructure covering storage, transmission, and tokenisation<\/td>\n<\/tr>\n<tr>\n<td>Saved cards<\/td>\n<td>Network tokenisation via Magic Checkout, aligned to RBI&#8217;s card-on-file mandate<\/td>\n<\/tr>\n<tr>\n<td>Encryption<\/td>\n<td>TLS and AES-256 encryption across the stack<\/td>\n<\/tr>\n<tr>\n<td>API integrity<\/td>\n<td>Signed webhooks, idempotency keys, and replay protection<\/td>\n<\/tr>\n<tr>\n<td>Fraud prevention<\/td>\n<td>Thirdwatch, AI-powered fraud prevention at the payment layer<\/td>\n<\/tr>\n<tr>\n<td>Reliability<\/td>\n<td>99.99% system uptime over the last 12 months<\/td>\n<\/tr>\n<tr>\n<td>Success rates<\/td>\n<td>90 to 95% transaction success rates through smart routing via Optimiser<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>The gateway-side column should be something you verify once, not chase every quarter.<\/p>\n<p><a href=\"https:\/\/razorpay.com\/payment-gateway\/\">Explore Razorpay&#8217;s Payment Gateway<\/a><\/p>\n<h2>Frequently Asked Questions<\/h2>\n<h3><strong>1. Does Razorpay support card tokenisation in India?<\/strong><\/h3>\n<p><span style=\"font-size: 19px;\">Yes. Razorpay offers TokenHQ for card-on-file tokenisation. Confirm supported networks, integration requirements, and the consent and authentication flow for your checkout. <\/span><a style=\"font-size: 19px;\" href=\"https:\/\/razorpay.com\/card-tokenisation\/\">Card tokenisation<\/a><span style=\"font-size: 19px;\">.<\/span><\/p>\n<h3><strong>2. What is the difference between tokenisation and encryption?<\/strong><\/h3>\n<p><span style=\"font-size: 19px;\">Tokenisation substitutes a token for sensitive data. Encryption converts data into ciphertext that an authorised key can decrypt. Tokenisation reduces the need to retain card credentials; encryption protects data that is transmitted or legitimately stored.<\/span><\/p>\n<h3><strong>3. How does Razorpay protect customer information beyond card details?<\/strong><\/h3>\n<p><span style=\"font-size: 19px;\">Razorpay\u2019s security documentation describes HTTPS\/TLS protection and field-level encryption for sensitive personal information. Your business must also protect customer information held in its own CRM, helpdesk, and analytics systems. <\/span><a style=\"font-size: 19px;\" href=\"https:\/\/razorpay.com\/docs\/security\/\">Security documentation<\/a><span style=\"font-size: 19px;\">.<\/span><\/p>\n<h3><strong>4. Can tokenised cards be used with another payment gateway?<\/strong><\/h3>\n<p><span style=\"font-size: 19px;\">Support depends on the token arrangement and integration. Razorpay\u2019s product page describes using tokens with other gateways. Confirm supported routing, migration requirements, and customer actions for your setup. <\/span><a style=\"font-size: 19px;\" href=\"https:\/\/razorpay.com\/card-tokenisation\/\">TokenHQ product page<\/a><span style=\"font-size: 19px;\">.<\/span><\/p>\n<h3><strong>5. Does using a PCI DSS Level 1 provider make my business compliant?<\/strong><\/h3>\n<p><span style=\"font-size: 19px;\">No. Provider certification covers its assessed services. Your business must confirm its own assessment requirements and secure the website, credentials, and data systems it controls.<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Payment gateway tokenisation replaces saved card numbers with network tokens, while encryption protects data during transmission and authorised storage. In India, merchants should assess these controls alongside customer consent, access controls and responsibility for customer data. Razorpay documents card-on-file tokenisation through TokenHQ, PCI DSS Level 1 certification and HTTPS\/TLS protection. This checklist helps you verify<\/p>\n","protected":false},"author":180,"featured_media":28031,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"footnotes":""},"categories":[26],"tags":[],"class_list":{"0":"post-28028","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-payments"},"_links":{"self":[{"href":"https:\/\/razorpay.com\/blog\/wp-json\/wp\/v2\/posts\/28028","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/razorpay.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/razorpay.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/razorpay.com\/blog\/wp-json\/wp\/v2\/users\/180"}],"replies":[{"embeddable":true,"href":"https:\/\/razorpay.com\/blog\/wp-json\/wp\/v2\/comments?post=28028"}],"version-history":[{"count":3,"href":"https:\/\/razorpay.com\/blog\/wp-json\/wp\/v2\/posts\/28028\/revisions"}],"predecessor-version":[{"id":28032,"href":"https:\/\/razorpay.com\/blog\/wp-json\/wp\/v2\/posts\/28028\/revisions\/28032"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/razorpay.com\/blog\/wp-json\/wp\/v2\/media\/28031"}],"wp:attachment":[{"href":"https:\/\/razorpay.com\/blog\/wp-json\/wp\/v2\/media?parent=28028"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/razorpay.com\/blog\/wp-json\/wp\/v2\/categories?post=28028"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/razorpay.com\/blog\/wp-json\/wp\/v2\/tags?post=28028"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}