Checkout and payment integration
A redirect to your processor's page, an embedded payment frame or hosted card fields. We help you pick the one that fits your business and keeps card numbers off your servers, then build it.
E-commerce and retail: PCI scope by design
Take card payments online — without card data on your servers.
We build checkouts that send card numbers to your payment processor, not through your own systems. That choice decides which PCI DSS form you file and how much of your business gets assessed. We also plan how you look after customer records under India's data law, before launch.
- Payment design settled before code
- Customer-data safeguards designed in
- We reply within one working day.
- PCI DSS v4.0.1
- DPDP Act, 2023
- DPDP Rules, 2025
- Consumer Protection (E-Commerce) Rules, 2020
In brief
- Who it's for
- Online stores, marketplaces and retail brands that take card payments on the web or in an app, with a new checkout or a live one.
- What gets in the way
- How your checkout takes cards decides how much of your business a PCI DSS assessment covers. That is fixed when the checkout is built, and changing it later means rebuilding it.
- How we help
- We settle the payment design before code is written, build the checkout and the customer systems around it, and plan the safeguards India's DPDP Act asks for.
What we build
A checkout, and the systems behind it, built to keep your risk small.
We build web stores and shopping apps, and our own security team reviews what we build, so card and customer data questions are settled while the code is written.
Saved cards and repeat orders
Tokens, stand-in values from your processor, replace saved card numbers for repeat billing. The first card capture still sets your scope, so we design it just as carefully.
A lean payment page
Analytics, chat widgets and tag managers on a payment page each need a written reason under PCI DSS. We keep the page lean and add a way to spot tampering with it.
Order records without card numbers
We design order notes, support tickets and logs to keep card numbers out, because one stray number brings the whole of PCI DSS Requirement 3 with it.
Customer data, mapped and protected
We map where customer records live and who can read them, then build the safeguards India's DPDP Rules expect.
A security check before launch
If your servers handle card data, schedule a web application vulnerability assessment of the payment flow before the store goes live.
Starting from scratch? See web and custom software development and mobile app development.
Scope starts at checkout
Your PCI DSS scope is a design decision.
PCI DSS v4.0.1 counts systems by what they can reach, so the checkout's design sets the size of the job.
PCI DSS is the card industry's security standard, published by the PCI Security Standards Council (PCI SSC). Its scope is the set of systems an assessment covers. A system is pulled in for any one of three reasons:
- It handles card data. It stores, processes or transmits account data.
- It connects to systems that do. Being connected is enough.
- It could affect their security. This test reaches the identity provider your staff sign in with, the logging pipeline, patch management and the cloud control plane.
None of those systems sees a card number, and each can be assessed anyway. A checkout that hands the shopper to the processor, instead of posting card data through your own web servers, changes which questionnaire you file and whether your developers are in scope. PCI DSS scope reduction starts there.
The questionnaire and who decides
Many online stores show compliance with a self-assessment questionnaire (SAQ). SAQ A, the lightest, is open only to certain checkout designs. Your acquirer, the bank that accepts card payments for you, decides which route it will take.
Four checkout patterns
How each checkout pattern changes the assessment.
Where the card number travels decides which questionnaire your store can use.
| Checkout pattern | What reaches your servers | Validation route |
|---|---|---|
| Full redirect to the processor's own page | No card data; the shopper leaves your site | SAQ A |
| Embedded iframe or hosted payment fields | No card number; your page frames theirs | SAQ A plus the script criterion |
| Your own form posts the card number | Card data in transit through your web servers | Not SAQ A; your acquirer sets the route |
| Tokens saved for repeat billing | Tokens after the first capture | Set by how the first capture works |
What a card form on your own server brings with it
When your own form submits the card number to your servers, SAQ A is off the table and your acquirer decides what replaces it. It also makes a web application vulnerability assessment of the payment flow worth scheduling before launch.
What lands on the store:
- Automated protection for the public web application under Requirement 6.4.2
- An authorized, justified inventory of every payment page script under 6.4.3
- Tamper detection for the payment page under 11.6.1
- Your web servers and their logs, now carrying card data in transit
Who signs off. Your acquirer decides which validation route it accepts. We are not a PCI SSC Qualified Security Assessor (QSA) Company or Approved Scanning Vendor, so we prepare you for those sign-offs rather than giving them.
Build decisions
Four decisions that design the scope away.
Each one is settled in checkout code, so we settle it before that code is written.
Pick how the payment page is delivered
Choose between a full redirect, an embedded iframe or hosted fields, and your own form before checkout code is written. The table above shows what each choice sends to your servers.
Settle the script question for embedded pages
Since 31 March 2025, SAQ A for embedded pages requires confirming your site is not open to script attacks. We build protections in the style of Requirements 6.4.3 and 11.6.1, or you get written confirmation from a compliant processor.
Keep card numbers out of order records
Order notes, support tickets and application logs should never hold a card number. Once one is written anywhere, all of Requirement 3 applies, and a ticket queue where shoppers paste card numbers falls in scope.
Put the provider split in writing
Outsourcing payments brings Requirement 12.8 duties: a list of providers, written agreements in which each provider accepts responsibility for account data, and a continuing check on their compliance status.
Customer data
India's rules follow the customer record, not only the card.
Designing card data out still leaves the customer records a store keeps, and what it must tell shoppers.
Most of what a store holds is not card data but names, addresses, phone numbers and orders. India's Digital Personal Data Protection (DPDP) Act, 2023 covers those records.
- The duties start in May 2027. MeitY's DPDP Rules, 2025, notified in November 2025, start the duties a store owes its customers in May 2027.
- Safeguards are designed in. Rule 6 asks for reasonable security safeguards, log retention among them, so customer and order tables need them from the start.
- Even a small leak is reportable. From May 2027, Rule 7 has no materiality threshold, so a leak of customer records is reportable to each person affected and to the Data Protection Board.
- Shoppers must be told about payment security. The Consumer Protection (E-Commerce) Rules, 2020 require marketplace and inventory e-commerce entities to show shoppers information on the security of their payment methods.
- The data inventory is built with the checkout. Which tables hold names, addresses, phone numbers and orders, and who can read each.
Our DPDP Act compliance page maps each tranche of the Rules. Selling to shoppers in the European Union as well? The EU's GDPR brings its own duties; see GDPR compliance.
Find the right help
Start with the situation you're in.
Each row opens the page that covers it in detail.
- We're building a new online store and haven't chosen how checkout takes cards.Web and custom software
- Our shopping app needs a checkout of its own.Mobile app development
- Our own form posts card numbers, and we want a smaller PCI DSS scope.PCI DSS scope reduction
- Our payment flow launches soon and nobody has checked it for weaknesses.Web application assessment
- We hold customer names, addresses and orders, and we sell in India.DPDP Act compliance
- We also sell to shoppers in the European Union.GDPR compliance
- If customer records leak, who reports it, to whom, and how fast?Incident response readiness
FAQ
Questions online stores ask about checkout scope.
Questionnaires, payment page scripts and India's data rules. For anything else, ask us directly.
It depends on how the payment page reaches the shopper. Under PCI DSS v4.0.1, a full redirect to the processor's hosted page points to SAQ A, as does an embedded iframe or hosted fields with an added script criterion. If your own form posts card numbers, SAQ A is out and your acquirer decides the route.
No. Card numbers stay off your servers, but your page still frames the processor's. Since 31 March 2025, SAQ A for embedded pages asks you to confirm your site is not susceptible to script attacks, a criterion full redirects do not carry. PCI SSC accepts your own script protections or written confirmation from a compliant processor.
It removes storage scope, not the assessment. Tokens can stand in for saved card numbers on repeat orders, but the first capture still passes through some checkout, and that path keeps whatever scope its design gives it. A tokenized store whose own form posts card numbers still carries that pattern's requirements.
Yes. On a payment page, PCI DSS v4.0.1 Requirement 6.4.3 expects every script to be authorized, integrity-assured and justified in writing, and Requirement 11.6.1 expects a way to detect tampering. That reaches analytics, chat widgets, tag managers and A/B testing tools, so each tag left off the payment page is one fewer to justify.
The DPDP Rules, 2025 were notified in November 2025, and the duties a business owes the people whose data it holds commence in May 2027. They include notice, consent, reasonable security safeguards under Rule 6 and breach reporting under Rule 7. Before that date, the IT Act's section 43A and the SPDI Rules, 2011 still apply.
The Consumer Protection (E-Commerce) Rules, 2020, notified by the Department of Consumer Affairs in July 2020, require marketplace and inventory e-commerce entities to display information on the payment methods available and the security of those methods. It is a disclosure duty, and what a store can truthfully disclose depends on how its checkout handles card data.
Let's talk
Settle your PCI scope before the checkout ships.
Tell us how card payments reach your store today, or how you plan to take them. Project work is delivered remotely from India during business hours. We reply within one working day.