What PCI DSS Is and Why Your Payment Project Needs It

What PCI DSS is and who it applies to

PCI DSS (Payment Card Industry Data Security Standard) defines how an organization must store, process and transmit payment card data. It is maintained by the PCI SSC council, founded by Visa, Mastercard, American Express, Discover and JCB. It is not a law but a contractual obligation: your acquiring bank and the card schemes require compliance if you want to accept cards.

Many teams in Uzbekistan assume PCI DSS does not concern them because they work with the local Uzcard and Humo systems. But the moment you start accepting international Visa or Mastercard payments directly — through your own checkout form, a mobile app or a server-side integration — you fall within the standard's scope. An acquiring bank simply will not onboard you without proof of compliance.

Merchant levels: where you land

The volume of requirements depends on your annual card transaction count. The card schemes split merchants into four levels:

Level 1 — over 6 million transactions per year. The strictest: a mandatory annual on-site audit by an external QSA assessor with a ROC report.
Level 2 — 1 to 6 million transactions. Usually a self-assessment questionnaire (SAQ), sometimes with QSA involvement.
Level 3 — 20,000 to 1 million online transactions. SAQ plus quarterly ASV scans of the external perimeter.
Level 4 — under 20,000 online transactions or up to 1 million total. Typically SAQ and scanning.

The vast majority of startups and mid-sized projects in Uzbekistan are Level 3 or 4. That is good news: you most likely do not need an expensive on-site audit — a correctly completed SAQ and regular scans are enough.

The key architectural decision is made before the first line of code: will you ever touch card data at all. If a certified payment provider hosts the card entry form and you only ever receive a token, your compliance scope shrinks dramatically — from the heavy SAQ D to the light SAQ A.

The 12 requirements

PCI DSS boils down to 12 requirements grouped into six goals. Stripped of the formal wording, it is sensible engineering hygiene:

Network protection: firewalls, segmentation, no data stored in open segments.
No vendor-default passwords or insecure default settings.
Protection of stored card data: encryption, masking, and never storing CVV.
Encryption of data in transit over open networks (TLS).
Anti-malware protection and vulnerability management.
Secure development and timely patching of code vulnerabilities.
Restricting data access on a least-privilege basis.
Uniquely identifying everyone with access to systems.
Physical protection of hardware and media.
Logging and monitoring of all access to data.
Regular security testing (scans, penetration tests).
Maintaining an information security policy.

The current version of the standard is PCI DSS 4.0.1. A number of new requirements from the 4.0 branch became mandatory after March 2025: stronger authentication, control over scripts on payment pages, and more frequent access-rights reviews. If you are starting a project now, build for 4.0.1 from day one rather than the retired 3.2.1.

Tokenization: cutting the burden

Tokenization replaces the card number with a token that is meaningless to an attacker. The real PAN lives in the provider's secure vault, while your database holds only a reference that cannot be reversed into a card. It is the primary technique for taking your servers out of audit scope.

Encryption protects the data, but it still sits with you — meaning your servers remain within PCI DSS scope with all its requirements.

Tokenization shifts responsibility for storing the card to a certified provider. You are left with a token that is not card data in itself — and the assessment scope drops sharply.

In practice this means using hosted forms, redirect checkout or an iframe from a provider that is already certified. The card then never passes through your backend. For most Uzbek projects integrating through local PSPs, this is the working model — card data never physically reaches your infrastructure.

A common mistake: storing the full card number or CVV "to make repeat charges easier later." CVV must never be stored after authorization in any form, even encrypted. Storing PAN yourself automatically pushes you into the heavy SAQ D and sharply raises the cost and timeline of certification. For recurring payments, use the provider's tokens, not raw cards.

How to prepare and what timelines to plan for

Preparing for compliance follows a clear path:

Define scope: where card data appears, is stored and is transmitted. Draw a data-flow diagram.
Reduce scope through tokenization and network segmentation.
Choose the correct SAQ type for your architecture.
Close technical gaps: TLS, logging, MFA, access control, patching.
Run ASV scans of the external perimeter (quarterly for Levels 3-4).
Complete the SAQ and AOC, and a ROC with a QSA if required.

Realistic timelines: if the architecture was designed from the start with tokenization and hosted checkout, preparation takes from a few weeks to a couple of months. If the project already stores cards and must be re-engineered, plan for three to six months, plus time to remediate findings after the first scan. Certification is not a one-off: the SAQ is renewed annually and ASV scans run quarterly, so it is better to bake compliance into your processes than to scramble once a year.

Conclusion

PCI DSS is not a bureaucratic barrier but a way to avoid losing both money and user trust at the first incident. The cheapest PCI DSS is the one built into the architecture from the very beginning: tokenization, hosted forms and sound segmentation cut the assessment scope many times over. If you are launching a payment project in Uzbekistan and want to design the integration so that card data never reaches your infrastructure, discuss the architecture with the OneDev team before the first payment module is written.

Do we need PCI DSS if we only work through Payme, Click or Uzum?

If the provider hosts the card form and you only receive a token or a payment status, your own scope is minimal. But it does not exempt you entirely: you are still responsible for the security of the integration and usually complete the light SAQ A. Your acquiring bank confirms the exact model.

What is the difference between encryption and tokenization?

Encryption keeps the protected data with you, so your servers stay in audit scope. Tokenization replaces the card with a token and moves PAN storage to a certified provider, taking your infrastructure out of scope.

Can we store CVV for repeat charges?

No. CVV must never be stored after authorization in any form, including encrypted. For recurring payments you use a card token issued by the provider, not the verification code.

What merchant level does a typical Uzbek startup fall into?

Most often Level 3 or 4 — under a million transactions a year. That means self-assessment via SAQ and quarterly ASV scans instead of an expensive on-site QSA audit.

How long does compliance preparation take?

With a tokenized architecture, from a few weeks to a couple of months. If the project already stores cards and must be re-engineered, three to six months plus remediation time.

Which version of the standard should a new project use?

The current PCI DSS 4.0.1. Some new requirements from the 4.0 branch became mandatory after March 2025, so designing for the retired 3.2.1 no longer makes sense.

What PCI DSS is and who it applies to

Merchant levels: where you land

The volume of requirements depends on your annual card transaction count. The card schemes split merchants into four levels:

Level 1 — over 6 million transactions per year. The strictest: a mandatory annual on-site audit by an external QSA assessor with a ROC report.
Level 2 — 1 to 6 million transactions. Usually a self-assessment questionnaire (SAQ), sometimes with QSA involvement.
Level 3 — 20,000 to 1 million online transactions. SAQ plus quarterly ASV scans of the external perimeter.
Level 4 — under 20,000 online transactions or up to 1 million total. Typically SAQ and scanning.

The 12 requirements

PCI DSS boils down to 12 requirements grouped into six goals. Stripped of the formal wording, it is sensible engineering hygiene:

Network protection: firewalls, segmentation, no data stored in open segments.
No vendor-default passwords or insecure default settings.
Protection of stored card data: encryption, masking, and never storing CVV.
Encryption of data in transit over open networks (TLS).
Anti-malware protection and vulnerability management.
Secure development and timely patching of code vulnerabilities.
Restricting data access on a least-privilege basis.
Uniquely identifying everyone with access to systems.
Physical protection of hardware and media.
Logging and monitoring of all access to data.
Regular security testing (scans, penetration tests).
Maintaining an information security policy.

Tokenization: cutting the burden

Encryption protects the data, but it still sits with you — meaning your servers remain within PCI DSS scope with all its requirements.

Tokenization shifts responsibility for storing the card to a certified provider. You are left with a token that is not card data in itself — and the assessment scope drops sharply.

How to prepare and what timelines to plan for

Preparing for compliance follows a clear path:

Define scope: where card data appears, is stored and is transmitted. Draw a data-flow diagram.
Reduce scope through tokenization and network segmentation.
Choose the correct SAQ type for your architecture.
Close technical gaps: TLS, logging, MFA, access control, patching.
Run ASV scans of the external perimeter (quarterly for Levels 3-4).
Complete the SAQ and AOC, and a ROC with a QSA if required.

Conclusion

Do we need PCI DSS if we only work through Payme, Click or Uzum?

What is the difference between encryption and tokenization?

Can we store CVV for repeat charges?

No. CVV must never be stored after authorization in any form, including encrypted. For recurring payments you use a card token issued by the provider, not the verification code.

What merchant level does a typical Uzbek startup fall into?

Most often Level 3 or 4 — under a million transactions a year. That means self-assessment via SAQ and quarterly ASV scans instead of an expensive on-site QSA audit.

How long does compliance preparation take?

With a tokenized architecture, from a few weeks to a couple of months. If the project already stores cards and must be re-engineered, three to six months plus remediation time.

Which version of the standard should a new project use?

The current PCI DSS 4.0.1. Some new requirements from the 4.0 branch became mandatory after March 2025, so designing for the retired 3.2.1 no longer makes sense.

What PCI DSS Is and Why Your Payment Project Needs It

What PCI DSS is and who it applies to

Merchant levels: where you land

The 12 requirements

Tokenization: cutting the burden

How to prepare and what timelines to plan for

Conclusion

Need a similar system or want to discuss your project?

What PCI DSS Is and Why Your Payment Project Needs It

What PCI DSS is and who it applies to

Merchant levels: where you land

The 12 requirements

Tokenization: cutting the burden

How to prepare and what timelines to plan for

Conclusion

Need a similar system or want to discuss your project?