PCI DSS · Card payments
PCI DSS v4.0 says live primary account numbers (PANs) aren't used in pre-production environments unless those environments are protected like the cardholder data environment. A system copy brings live card data with it. Synthesized refreshes SAP test systems with test card numbers instead, keeping every order, invoice and payment linked.
Not a compliance assessment: your Qualified Security Assessor confirms scope.
On SAP, we measure results on your own data in a 10-day validation.
The requirement
PCI DSS v4.0 · Requirements 6.5 and 3.46.5.5: live PANs are not used in pre-production environments, except where those environments are in the cardholder data environment and protected accordingly.
6.5.6: test data and test accounts are removed from system components before the system goes into production.
3.4.1: PAN is masked when displayed, so only people with a business need see more than the BIN and last four digits.
Paraphrased. Read the standard and confirm scope with your QSA.
Read the source: PCI DSS document library, PCI Security Standards Council
In SAP
| Area | Where card data can appear | In a test copy |
|---|---|---|
| Customer master | Payment cards assigned to customers (VCKUN) | Copied as they are, unless replaced |
| Sales and billing | Card authorizations on sales orders and billing (FPLTC) | Linked to the orders and invoices tests depend on |
| Receivables and payments | Card payments and clearing in FI or FI-CA | Must still match the billing documents |
| Connected payment systems | Tokens and card references | Must match SAP for end-to-end tests |
Many landscapes encrypt or tokenise card numbers in production. A copy still carries them, or their references, into pre-production.
How it works
A scan flags card numbers in standard and custom tables, including free-text fields.
Swap live PANs for test numbers in the right format, the same way in SAP and the payment systems around it.
Orders, billing documents and payments still point to each other, so order-to-cash tests run.
Scope, rules and who ran it, ready for your assessor.
We've got you covered
Not with live PANs, unless the pre-production environment is in the cardholder data environment and protected to every applicable requirement. Most teams use test card numbers instead.
It reduces exposure, but a system copy still moves tokens, references and sometimes card data into test, and tests often need realistic card fields. Replacing them in the copy removes the question.
Numbers in the right format, so validations and payment flows behave as they do in production, but linked to no real account.
Yes, wherever Synthesized can connect to them. A source can be any production application or database, SAP or not, so connected billing, payment and CRM databases get the same test card numbers as SAP, and references between them still match. External payment processors keep their own sandbox and test modes.
Your Qualified Security Assessor. We provide the masking rules and refresh records they need to review pre-production.
Next step
A scan of one SAP test system shows where card data sits today, in standard and custom tables.
SAP, S/4HANA, SAP HANA, SuccessFactors, Ariba, Concur and other SAP products and services mentioned herein, as well as their respective logos, are trademarks or registered trademarks of SAP SE (or an SAP affiliate company) in Germany and other countries. All other product and service names mentioned are the trademarks of their respective companies.
