A PCI DSS-compliant payment gateway in India is a payment service whose assessed card-data systems meet the applicable Payment Card Industry Data Security Standard requirements. For merchants, the practical question is how much card-data handling can move to the provider and what responsibilities remain.
Razorpay’s official security documentation lists PCI DSS Level 1 among its certifications and says copies can be requested through your Key Account Manager. Using a supported Standard Checkout flow can reduce raw card-data exposure on your backend. Your website, access controls, provider oversight and applicable merchant validation still need attention.
A provider’s validation is not a transferable merchant certificate. Review current evidence for the entity and payment service you use, then confirm the assessment method with your acquiring bank or other compliance-accepting entity. This guide explains Checkout data flow, integration choices and the responsibilities to document before launch.
Key Takeaways
- Razorpay’s documented provider compliance status and your merchant PCI DSS validation are two separate decisions, with two separate pieces of evidence.
- A properly implemented provider-managed card-entry flow can reduce raw card-data exposure. Trace the real data flow rather than trusting a checkout label.
- SAQ A eligibility is conditional. Confirm your integration and reporting method with your acquiring bank or other compliance-accepting entity.
- Your website, plugins, access controls, API secrets and service-provider oversight still need attention after launch.
- Current PCI SSC guidance separates embedded payment forms from redirects for script-security eligibility, and SAQ A merchant webpages can still carry ASV scanning requirements.
- Request current, service-specific compliance evidence and document the responsibility split before launch.
What Is a PCI DSS-Compliant Payment Gateway in India?
A PCI DSS-compliant payment gateway has validated the applicable security controls for its assessed card-data environment. For an Indian merchant, the practical benefit depends on the integration: provider-managed card entry can reduce card-data exposure, while the merchant still secures its own environment and confirms the compliance validation it is required to complete.
Provider Compliance, Merchant Compliance and Level 1 Are Different
PCI DSS covers cardholder data, such as the primary account number, and sensitive authentication data, such as CVV. An Attestation of Compliance (AOC) records the assessment outcome and scope. A Self-Assessment Questionnaire (SAQ) is a validation format, a Report on Compliance (ROC) documents an assessment, and a Qualified Security Assessor (QSA) performs qualified assessments. Level 1 describes a payment-brand validation category, not a separate standard, PCI DSS version, or fraud guarantee. See the general PCI DSS explainer for the requirement set.
PCI DSS and India Payment Rules Have Different Jobs
PCI DSS governs payment-card data security and is enforced contractually through acquirers and card brands. The RBI Master Direction on Regulation of Payment Aggregators, issued on 15 September 2025, regulates payment aggregation activity in India, and card-on-file restrictions govern who may store actual card credentials. RBI authorisation is not proof of a provider’s PCI DSS validation, and PCI DSS evidence is not a substitute for authorisation.
DID YOU KNOW: PCI DSS can still apply when a merchant outsources payment processing. PCI SSC’s outsourcing guidance explains that the remaining task is to verify the provider and the shared obligations.
What PCI DSS Evidence Should You Check for Razorpay?
Razorpay’s security documentation lists PCI DSS Level 1 among its certifications, but a merchant should also review current evidence for the relevant legal entity and payment service. Ask for the applicable Attestation of Compliance, assessment date, and service scope, then document which controls Razorpay performs and which remain with your business.
What the Public Documentation Establishes
The Razorpay security documentation lists PCI DSS Level 1 and says certification copies can be requested through your Key Account Manager. The shared responsibility model describes the division between Razorpay’s payment systems and your payment environment. Confirm the assessed service and legal entity using current evidence rather than relying on a badge alone.
Evidence Checklist Before You Rely on a Compliance Claim
| Evidence to check | Question to resolve |
|---|---|
| Assessed legal entity | Does the evidence cover the entity providing your payment service? |
| Standard and assessment period | Which PCI DSS version and dated assessment does it document? |
| Assessed service scope | Does it cover the checkout or payment service and integration you use? |
| AOC or accepted evidence | What documentation does your compliance-accepting entity need? |
| Responsibility allocation | Which requirements are performed by provider, merchant or another party? |
| Ongoing review | Who owns the refresh and the provider-status review? |
A certificate of compliance and a service-provider AOC are different artifacts. PCI SSC distinguishes service-provider assessments from merchant SAQs; request evidence appropriate to the services you use.
PRO-TIP: Ask for the AOC and an integration-specific responsibility explanation together. A provider badge answers far less than a dated scope document plus a review of your actual implementation.
How Razorpay Standard Checkout Can Reduce Merchant Card-Data Exposure
Razorpay Standard Checkout is a Razorpay-managed checkout integration. When implemented using the supported card-entry flow, it can keep raw card details away from the merchant’s backend. The merchant still creates and tracks orders, protects credentials and verifies payment responses. Confirm the exact data flow before deciding your own PCI DSS assessment scope.
Separate the Card-Entry Path From the Order Path
The Standard Checkout prerequisites state that Razorpay developed and manages the Standard Checkout method, while the business configures payment methods, logo and colours. Three paths run alongside each other:
- Order path. Your backend creates an order server-side and passes the returned order details to Checkout. The integration steps documentation explains that the Orders API is a server-side call and that the order ties the order to the payment and secures the request from being tampered with.
- Card-entry path. The customer enters card details in the Razorpay-managed checkout context. The intended reduction is avoiding raw card details on merchant infrastructure.
- Confirmation path. Your backend receives payment identifiers and a signature, verifies the response server-side, and decides whether the payment state permits fulfilment.
Order IDs, payment IDs, amounts and customer or order information are not interchangeable with full card numbers or CVV. Your merchant systems do receive data, and that data still needs sensible handling.
Card entry and processing
Customer enters card details
In the supported Razorpay-managed Checkout context
Razorpay processes the card payment
Through its payment service
Order and payment status
Merchant backend creates an order
Server-side order creation
Checkout uses the order ID
Order linked to the payment
Merchant backend verifies the response
Payment references, signature and payment state
| Lane | What moves |
|---|---|
| Card entry and processing | Customer card details entered in the Razorpay-managed checkout context |
| Order and payment status | Merchant backend creates orders and receives order IDs, payment IDs, signature and payment state |
What Tokenisation Changes, and What It Does Not
Tokenisation replaces usable card credentials in supported flows with a substitute reference, which can reduce reliance on raw card storage. Razorpay’s tokenisation API documentation notes that under RBI PA and PG guidelines businesses cannot save customer card numbers on their own servers. Tokenisation does not certify your website or remove credential and account controls. For depth, read the guide to payment gateway tokenisation and encryption in India, and see Razorpay Payment Gateway for the product overview.
Which Checkout Integration Changes Your PCI DSS Scope?
Your PCI DSS scope depends on where card details are collected and which systems can affect their security. Provider-hosted pages and supported Standard Checkout flows can reduce exposure compared with merchant-controlled card collection. Custom or Server-to-Server integrations need separate review. The integration name alone does not determine your SAQ eligibility.
Integration and Responsibility Comparison
Scroll horizontally to view all columns.
| Integration choice | Merchant decision | Scope implication | Validation action |
|---|---|---|---|
| Payment Links as a shareable provider-hosted destination | Collect through a shared link rather than a card form you build | Can reduce direct handling; link delivery and account access still need review | Confirm all relevant channels and the applicable merchant assessment |
| Payment Pages as a branded hosted collection page | Use a hosted page when you do not want to build a checkout page | Can reduce direct handling; the page configuration and account still matter | Confirm the assessment method covering all collection channels |
| Razorpay Standard Checkout | Implement the official managed card-entry flow and inspect data paths | Can reduce raw-card exposure on the backend; the surrounding webpage still affects payment security | Confirm embedding or redirect behaviour, SAQ eligibility and webpage controls |
| Razorpay Custom Checkout | Review the custom form, scripts and supported integration with your developers | Scope follows the actual implementation; do not assume Standard Checkout eligibility | Assess the data flow and validation requirements before launch |
| Razorpay Server-to-Server Checkout | Request account activation and meet the documented prerequisites | The merchant takes on additional compliance duties | Maintain PCI DSS compliance and share your PCI AOC before each year’s expiry for continued access, as required by Razorpay’s official documentation |
Custom Checkout and Server-to-Server are not synonyms. An API call that creates an order does not by itself mean you are collecting raw card data. Equally, a branded modal is not proof that the whole flow qualifies for a reduced questionnaire. For architectural background, the hosted payment gateway guide covers hosted models in general terms.
PRO-TIP: Review the integration that is actually deployed, including plugins, mobile apps, and secondary payment channels. A clean test flow can change the moment a custom form, a new plugin or an analytics script lands on the payment page.
Do You Still Need PCI DSS Validation or SAQ A With Razorpay?
Yes. Outsourcing payment processing does not automatically remove merchant validation duties. A supported hosted integration may allow a reduced assessment such as SAQ A when every eligibility condition is met. Your acquiring bank or other compliance-accepting entity determines the required reporting method. Confirm the current questionnaire and requirements for your actual environment.
SAQ A Is Conditional, and SAQ A-EP Is Not a Default Fallback
SAQ A applies only when the merchant satisfies its eligibility conditions. The SAQ A v4.0.1 Revision 1 document is dated January 2025. PCI SSC’s 4 August 2026 bulletin updates FAQ 1331. The current FAQ says merchants should confirm validation and reporting requirements with their compliance-accepting entity. Using SAQ criteria within a ROC requires explicit review, discussion and agreement with that entity.
Embedded Forms and Redirects Have Different Script-Security Criteria
PCI SSC FAQ 1588 explains the script-attack eligibility condition for embedded third-party payment forms. A merchant can use appropriate protections or obtain qualifying confirmation that the provider’s solution protects the payment page when implemented according to its instructions. That specific condition does not apply in the same way to full redirects or fully outsourced link payments. Website-security duties still remain. Obtain confirmation for your exact integration; distinguish the questionnaire’s eligibility conditions from the full standard.
Hosted Checkout Does Not Automatically Remove ASV Scans
An Approved Scanning Vendor (ASV) performs external vulnerability scans. PCI SSC FAQ 1604 states that SAQ A for PCI DSS v4.x includes external ASV scanning requirements for merchant ecommerce webpages, including those that redirect to a third party or embed its payment form. Confirm the applicable scanning scope with your compliance-accepting entity instead of assuming “no card storage” means “no scans”.
DID YOU KNOW: The embedded-form script criterion and merchant webpage scanning answer different questions. A redirect can avoid that specific criterion and still carry scanning obligations.
Which Security Responsibilities Stay With the Merchant?
Merchants remain responsible for the systems and decisions they control: website security, access, credentials, plugins, data collection and compliance validation. Razorpay manages its payment systems within its assessed service scope. Document the shared controls and review your provider’s status, rather than treating a provider PCI DSS claim as a replacement for your own security programme.
Merchant and Provider Responsibility Matrix
Scroll horizontally to view all columns.
| Control area | Provider-side role | Merchant-side role |
|---|---|---|
| Payment service and supported card entry | Operate the documented service and supply relevant compliance evidence | Use the supported implementation; verify no unexpected raw card collection |
| Website, CMS and plugins | Provide integration documentation | Patch and secure merchant systems; manage changes and third-party scripts |
| Dashboard and API access | Provide access, authentication and security features | Protect secret keys, apply least privilege, remove unnecessary access |
| Payment confirmation | Supply payment references and documented verification mechanisms | Verify signature and payment state server-side before fulfilment |
| Logs, support and analytics | Handle provider data within its service scope | Keep raw card details and secrets out of logs, forms, tickets and recordings |
| Validation and provider oversight | Supply relevant evidence and clarify shared scope | Confirm the assessment method, retain agreements and review provider status |
| Incident handling | Operate the provider’s response processes | Maintain a response owner and documented escalation route |
PCI SSC’s outsourcing guidance says merchants should retain written provider agreements, define shared responsibilities and monitor provider compliance status at least annually. Use Razorpay’s business security checklist for practical merchant-side controls.
DID YOU KNOW: Razorpay’s shared responsibility documentation says its gateway does not store sensitive information such as CVV or PIN. Keep raw card details and secrets out of merchant logs, support forms and screenshots, even when you use a managed checkout.
How to Launch and Maintain a Checkout With Less Card-Data Exposure
Start by choosing the supported payment flow and reviewing the provider’s current evidence. Map where card details, order data and payment results travel, then confirm merchant validation with your acquirer. Implement and test the documented integration, protect merchant-controlled systems, retain evidence and repeat the review whenever the checkout or provider documentation changes.
Eight Steps From Evaluation to Ongoing Review
- Define the payment channels. List website, mobile app, payment links, hosted pages and any other card-acceptance flow. Output: a channel inventory owned by operations or security.
- Request current provider evidence. Check the relevant entity, service, assessment period and shared controls. Output: approved evidence references and a responsibility record.
- Map the actual data flow. Identify who serves the card-entry form, then inspect backend, logs, analytics and support paths using test data. Output: a reviewed diagram and exposure checklist.
- Confirm merchant validation. Ask your acquirer or other compliance-accepting entity which current SAQ or assessment, AOC and scans apply. Output: a documented determination, not a questionnaire chosen from an article.
- Implement the supported flow. Follow Standard Checkout or your reviewed alternative, keep secret keys server-side, and verify payment responses. The best practices guidance covers server-side order creation and capturing authorised payments. Output: a reviewed implementation.
- Secure the surrounding environment. Patch the CMS and plugins, restrict administration, control scripts and tags, and address applicable scanning findings. Output: a dated website-security review.
- Test before accepting live payments. Use documented test-mode flows, verify payment states and fulfilment behaviour, and confirm no unexpected raw card capture. Output: test evidence and a launch checklist.
- Maintain the review. Assign an owner for provider-status monitoring, validation renewals, applicable scans, integration changes and incident escalation. Output: a review calendar and retained evidence.
PRO-TIP: Keep a short evidence register beside your integration documentation, recording the evidence date, service scope, validation decision, scan scope and next review owner.
These steps do not certify your business or replace an assessor. They produce a documented process that avoids unnecessary card-data handling.
Common Mistakes That Add Compliance Work
Extra compliance work usually comes from unintended card-data collection or unclear ownership. A custom form, support request, plugin or session-recording tool can change the payment environment even when the gateway itself is compliant. Review changes against the documented flow and confirm whether your validation or security controls need to change.
| Mistake | Practical correction |
|---|---|
| Treating a provider certificate as a merchant exemption | Confirm your own validation and the duties you retain |
| Choosing an SAQ from a generic blog | Review actual eligibility with your compliance-accepting entity |
| Adding scripts or session recording without a payment-flow review | Inspect what the tool can capture and which protections apply, using PCI SSC’s payment page security guidance |
| Sending raw card details or secrets to logs or support | Remove that collection path and follow your incident process |
| Relying on an old public certificate | Obtain current evidence for the relevant entity and service |
Frequently Asked Questions
Is Razorpay a PCI DSS-Compliant Payment Gateway in India?
Razorpay’s official security documentation lists PCI DSS Level 1 among its certifications. Before relying on that for your assessment, request current evidence for the relevant legal entity and payment service. Provider validation does not certify your business; your implementation and compliance-accepting entity determine your remaining obligations.
Does Using Razorpay Standard Checkout Make My Business Automatically PCI DSS Compliant?
No. A supported Standard Checkout flow can reduce your exposure to raw card details, but your own obligations remain. Review website security, credentials, plugins, data collection and provider oversight. Confirm the required merchant validation method with your acquiring bank or other compliance-accepting entity, using your actual payment flow.
Do I Need SAQ A or SAQ A-EP When I Use Razorpay?
The integration name alone cannot decide that. SAQ A is available only when all applicable eligibility conditions are satisfied, and SAQ A-EP has different conditions. Ask your compliance-accepting entity which assessment applies. Review where payment-page elements originate and whether merchant-controlled systems can affect account-data security, using the current questionnaire.
Do I Still Need Website Scans If Card Entry Is Hosted?
Possibly, and a hosted flow is not a blanket exemption. PCI SSC FAQ 1604 states that SAQ A includes external ASV scanning requirements for merchant ecommerce webpages that redirect to providers or embed their payment forms. Confirm your applicable scan scope with your compliance-accepting entity.
What Should I Request From Razorpay Before Completing My PCI DSS Assessment?
Request current compliance evidence for the service and entity you use, the assessment date and scope, and a clear explanation of shared responsibilities as set out in the shared responsibility model. If you rely on provider protection for an embedded payment form, obtain written confirmation for your exact implementation.
