PCI DSS for the person building it

PCI DSS usually enters a project as a cloud: someone says “we have to be PCI compliant” and nobody knows whether that means two weeks or six months. The good news is that the size of that burden is decided by a single architectural choice, made at the very start. The bad news is that the option that sounds most reasonable —“let’s build our own form, for control”— is exactly the one that multiplies the work tenfold.

First: PCI DSS is not a Peruvian law

PCI DSS is a card-industry standard, not government regulation. In Peru the party that will demand it is your acquirer or your gateway —Niubiz, Izipay, Culqi— as a contractual condition, not the banking regulator or the tax authority.

This matters for two practical reasons. First: the counterpart you negotiate scope with is commercial, not regulatory — and usually has clear criteria about what they accept. Second: non-compliance does not show up as a state fine, but as something worse for a digital business: losing your ability to charge, or carrying the liability yourself after an incident.

The decision that defines everything: does the card touch your servers?

The entire weight of your compliance depends on where the card-capture form lives. If a validated third party delivers it in full —hosted checkout, tokenized iframe or redirect— you land on the short path. If your site participates in delivering that form, you land on a much longer one.

Notice the jump: the difference between the first and the second is not gradual. It is enough for the JavaScript that builds the card form to be served from your domain —a “direct post”, your own script sending the card to a third party— to move from the shortest route to around 150 controls. And if you end up storing, processing or transmitting the card number, the destination is around 250.

That is why, when we write about Culqi and Niubiz, we insist the card must never touch your servers: it is not an aesthetic preference, it is the difference between a short questionnaire and a compliance project.

The 2025 change almost nobody reported

In January 2025 the PCI SSC updated SAQ A and removed requirements 6.4.3, 11.6.1 and 12.3.1 —those covering script management and tamper detection on the payment page. The October 2024 version retired on 31 March 2025, and the new one has applied since.

It sounds like relief, and partly it is. But it comes with a trade-off worth reading in full: the update raised the eligibility bar. To use SAQ A you must now self-attest that your site is not susceptible to script-based attacks that could affect your e-commerce systems — and that refers to the whole site, not just the payment page.

In other words: the questionnaire got shorter, the responsibility did not. If your site cannot support that attestation, you do not qualify for SAQ A and you fall to A-EP or D, where those requirements still apply in full. And if you are a payment service provider, 6.4.3 and 11.6.1 still bind you regardless.

Merchant levels are not what you think

Levels 1 through 4 are determined by transaction volume and define how you validate, not how much the standard demands. Being level 4 means you may use a questionnaire instead of a certified assessor — not that fewer security requirements apply.

It is an expensive confusion. A small merchant concludes “we are level 4, this barely applies to us”, designs carelessly and ends up on SAQ D anyway, only finding out late. Volume decides the ceremony of validation; architecture decides the work.

What to do in practice

Decide the architecture before the provider, confirm in writing with your acquirer which questionnaire they expect from you, and treat your site’s script inventory as part of the product — not as a separate security topic.

How we do it

We design payment integrations that stay on the short path: tokenization, the provider’s checkout and no card data on your servers — without sacrificing the experience.

We have done it with Culqi and Niubiz in production. If you are deciding how to charge and want to make this call with the full picture —including what it really costs— let’s talk before the architecture is locked in.

In summary

The cost of PCI DSS compliance is not decided by your size: it is decided by whether the card passes through your servers. Delegating capture to the provider’s checkout, iframe or redirect keeps you on the shortest questionnaire; serving the form yourself takes you to around 150 controls, and storing card data to around 250. The 2025 change removed three requirements from SAQ A but raised eligibility —you now attest for the whole site, not just the payment page— so it is a change of shape, not a discount. And merchant levels define how you validate, not how much is demanded. Decide the architecture first: it is the only lever that genuinely moves the cost.

An honest note: this article is engineering guidance, not compliance advice. The authority is the official PCI SSC document library and whatever your acquirer confirms in writing.