PCI DSS 3.2 changes little directly for a small shop. What matters is how your checkout takes cards: a hosted payment page means the shortest questionnaire, while card numbers touching your server bring in the full standard.

A new version of the card rules

PCI DSS is the card industry's security standard, and it applies to any business that accepts card payments. A new version of it, 3.2, was published today.

Most small shops never read the standard itself. They meet it once a year, as a self-assessment questionnaire their payment provider asks them to complete.

The new version changes little for a small shop directly. What it is worth doing this week is checking that the questionnaire you tick still describes how your site takes cards.

What version 3.2 changes

The bulk of what is new targets payment processors and other firms that handle card data on behalf of businesses, along with large merchants.

For a small shop, the change most likely to matter is two-step login: anyone who can administer a system touching card data must enter a code as well as a password.

New requirements count as best practice until February 1, 2018, when they become mandatory. That is time to plan, not a reason to wait.

The new version also confirms the date for retiring old encryption: June 30, 2018, pushed back from the end of June this year.

The ways a checkout takes cards

How much of the standard applies to you depends on one question: does a card number ever touch your website?

The fourth is the one many older shops have without knowing it. A plugin that collects the card on your page and forwards it from your server puts the whole website inside the rules.

The route decides the questionnaire

The card industry publishes several questionnaires, and the route a card number takes decides which one is yours.

A shop whose provider supplies the whole payment page or frame completes the shortest, called SAQ A.

A shop whose own pages deliver the card form completes SAQ A-EP, which is far longer and includes regular scans of the website.

When card numbers pass through or are stored on your own systems, the full standard applies, through SAQ D. For a small shop that is a great deal of work, most of it avoidable.

Old encryption has a date

SSL and early TLS are older versions of the encryption behind the padlock in the address bar. Weaknesses found in them mean they can no longer be trusted with card payments.

Under the standard they must be retired by June 30, 2018, on payment pages and on the connections a site makes to its provider.

Providers will switch them off on their own timetables, some well before that. A shop running an old plugin on an old server can find one morning that its checkout no longer reaches the provider.

Shoppers on very old browsers, such as Internet Explorer on Windows XP, will lose the ability to pay at the same moment.

A worked example

A surfboard shaper in a small coastal town builds custom boards in a workshop behind the shop. Its online store takes deposits on custom orders and sells fins, leashes and wax to surfers elsewhere.

The checkout collected card details in a form on the shop's own page, then passed them from the site's server to the payment provider.

Every year the owner ticked the shortest questionnaire, believing the provider handled the cards. It did, but only after they had passed through the shop's server.

That was the mechanism. Because cards travelled through the site, the whole website, its hosting and every admin login were inside the rules.

The shop switched the plugin to the provider's hosted payment page. Customers now pay on a page carrying the shop's logo, return to an order confirmation, and no card number touches the site.

The host confirmed the server supports current encryption, and the shortest questionnaire now genuinely describes the store.

What a hosted page does not cover

A hosted page moves card numbers off your site. It does not move responsibility for the site itself.

If someone breaks into the store and changes where the pay button leads, shoppers type their cards into a page that only looks like your provider's.

So the usual care still applies: current software, strong and separate admin passwords, and two-step login on the provider's dashboard wherever it is offered.

Questions for your payment provider

Ask the provider to name the questionnaire that fits your checkout as it works today, and whether your plugin or integration is accepted for it.

Ask when the provider will stop accepting old encryption from connected sites, and whether its hosted page can carry your logo and colours.

Keep the answers in writing with the questionnaire. They are the record of why you ticked what you ticked.

Questions for whoever runs the site

Which payment plugin the store uses, which version it is on, and when it was last updated.

Whether the server offers TLS 1.2, the current version, which depends on how old its operating system and encryption software are.

And whether card numbers have been kept anywhere in the site, its database or its backups. Old orders and exported spreadsheets are where they usually turn up.

The counter-case

A shop already on a hosted page, with no card numbers stored anywhere, has very little to change because of version 3.2.

No law requires the standard. The card brands impose it through the agreements businesses sign with their payment providers, and providers decide how to check it. Treat this post as general information rather than compliance advice.

For every other shop, find out which route card numbers take before the next questionnaire, and move to a hosted page if they touch your site.

Before the next questionnaire

  1. Find out how your checkout takes cards.
  2. Ask your provider which questionnaire applies.
  3. Move to a hosted page if cards touch your server.
  4. Search the database and backups for stored numbers.
  5. Confirm the server offers current encryption.
  6. Turn on two-step login for the payment dashboard.
  7. Keep the answers with the questionnaire.

Step one decides everything after it. Owners usually know which provider they use but not which route the card number takes, and the questionnaire, the work and the risk all follow from that route.

The payment option that involves no card at all is covered in accepting e-transfers for online orders.

Frequently asked questions

What is PCI DSS 3.2?

It is today's new version of the card industry's security standard, which covers any business accepting cards. Small shops generally deal with it through an annual self-assessment questionnaire.

What changes in 3.2 for small shops?

Little, directly. Most of what is new targets payment processors and large merchants, becomes mandatory on February 1, 2018, and includes two-step login for people administering card systems.

Which questionnaire applies to my shop?

It depends on the route card numbers take. A hosted payment page or provider frame means SAQ A; your own card form means a much longer one.

Why does a hosted payment page help?

The card number is typed into the provider's own page and never passes through your site or hosting, so most of the standard stays with the provider.

When must old encryption be retired?

SSL and early TLS must be retired from card payments by June 30, 2018. Providers may switch them off sooner, so check your plugin and server now.

Is PCI DSS a law?

No. The card brands impose it through the agreements businesses sign with their payment providers. Treat this as general information rather than compliance advice, and ask your provider what applies.

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.

Not sure how your checkout takes cards?

Send us your store's address. We will trace the route a card number takes and tell you which questionnaire fits.

Start a Conversation