On February 1 several recommendations in PCI DSS 3.2 become requirements, including two-step logins for administrative access to card systems. Stores using a hosted payment page have least to change; ask your provider what applies.

A date in the card rules

Any business that takes card payments is covered by PCI DSS, the security standard the card industry sets for everyone who handles card numbers.

Small businesses rarely read it. They meet it through a yearly self-assessment questionnaire, usually prompted by their payment provider.

The current version, 3.2, was published last year. Several of its new requirements were marked as best practice until January 31. On February 1 they become mandatory.

What changes on February 1

Most of the new requirements are aimed at service providers: the companies that process, store or transmit card data on behalf of others.

The one most likely to reach a merchant is two-step login, which the standard calls multi-factor authentication, for anyone with administrative access to systems that handle card data.

Another asks that after any significant change to those systems, such as a new checkout or a new server, the security measures are confirmed and the records updated.

Whether either applies to you depends on which questionnaire you fill in, and that depends on the route card numbers take.

Where card numbers touch a small business

The third is the one businesses forget. A card number sent by email sits in the inbox, on every phone that syncs it and in every backup, long after the payment is made.

The questionnaire follows the route

The card industry publishes several versions of the questionnaire, and which one you complete depends on how cards are taken.

A store that sends shoppers to a payment page run entirely by its provider qualifies for the shortest. One whose own pages build or carry the card form faces a much longer list.

Typing phone orders into a provider's online terminal has a version of its own. Storing card numbers anywhere in your own systems brings the whole standard into play.

Every extra route adds to the work. A business that takes cards in several ways may have several questionnaires to answer, or one longer one.

Why a hosted payment page shrinks the job

On a hosted payment page, the shopper types the card number into the provider's system. Your website never receives it, so your server is not part of the card's path.

Card fields the provider places inside your checkout, served from its own systems, can work the same way. Fields built by your site, or a plugin that passes card numbers on from your server, do not.

For most small stores, moving to a hosted or provider-served form is the largest single reduction in what the rules ask of them.

Two-step logins wherever money moves

A two-step login asks for a password and then a code from a phone app, a text message or a small device. A stolen password alone no longer gets anyone in.

Switch it on for the payment provider's dashboard and online terminal, the website's administrator accounts, the hosting control panel and the email accounts payments pass through.

Every person needs a login of their own. A shared password cannot be traced to anyone, and it never gets changed when someone leaves.

A worked example

A charter bus company with a dozen coaches takes deposits for weddings, school trips, ski weekends and holiday parties.

Its website had a deposit form built years ago, with card fields on the company's own page, passed to the payment provider through a plugin.

The office also took card numbers by phone and email, wrote them on booking sheets for the final balance, and keyed them into the provider's online terminal through one shared login.

When this year's questionnaire came due, the office manager realised the version the company had always filled in no longer described how it took cards.

Each route had been added for convenience, one at a time, and each pulled more of the business into the rules: the website, the inbox, the paper and the shared password.

The deposit form now hands customers to the provider's hosted page. Anyone who emails a card number gets a reply with a payment link, and the old messages were deleted.

Booking sheets lost their card number box, and each staff member now has a terminal login of their own, with a code from their phone.

Card numbers in the inbox

Never ask for a card number by email, and do not keep the ones that arrive. Reply with a payment link or a phone number, then delete the message and empty the deleted folder.

Add a line to quotes and booking emails saying how to pay, so customers do not offer their card number in a reply.

Older connections retire in June

The same standard sets June 30 next year as the date for retiring SSL and early versions of TLS, the older methods of encrypting a connection, from card payments.

Providers are switching those connections off, some before the deadline, so an old payment plugin or server can suddenly fail to reach the provider.

Ask whoever maintains the site whether it connects using current encryption, before the provider forces the question.

Questions for the payment provider

Ask which questionnaire applies to you, given how you take cards, and whether anything changes for you on February 1.

Ask whether your checkout method is still supported, whether two-step login is available for each person, and when older connections will be refused. Get the answers in writing.

The counter-case

A business that only takes cards on a standalone counter terminal, with nothing online, has far less to consider. So does a store already on a hosted page, with two-step logins and no card numbers anywhere else.

The standard is set by the card industry through contracts, not by law, and each provider applies it to its own merchants. This is general information, not compliance advice.

For any store taking cards online, though, find out which routes card numbers take, and switch on two-step logins before February.

Before February

  1. Map every route card numbers take.
  2. Ask your provider which questionnaire applies.
  3. Move to a hosted or provider-served form.
  4. Turn on two-step logins everywhere payments happen.
  5. Set up separate logins for each person.
  6. Delete card numbers from email and paper.
  7. Ask about older connections retiring in June.

Step one is the one that decides the rest. Card numbers turn up in unexpected places, and writing down every way a customer has ever paid is how they are found.

The office Wi-Fi those logins travel over is covered in the Wi-Fi flaw announced this week.


Frequently asked questions

What changes in PCI DSS on February 1?

Several requirements in version 3.2, recommended until January 31, become mandatory. Most apply to service providers; the one most likely to reach merchants is two-step login for administrative access.

Does PCI DSS apply to a small store?

Yes. It covers every business that takes card payments, though small ones usually meet it through a yearly self-assessment questionnaire chosen by how they take cards.

How does a hosted payment page help?

Shoppers type their card number on the provider's own page, so it never reaches your website or server. That qualifies most stores for the shortest questionnaire.

Where should two-step logins be switched on?

The payment dashboard and online terminal, the website's administrator accounts, the hosting control panel and any email account payments pass through, with a separate login for each person.

Can customers pay by emailing their card number?

They should not. The number stays in the inbox, on synced phones and in backups. Reply with a payment link or a phone number and delete the message.

What should I check with my provider?

Which questionnaire applies, whether February 1 changes anything for you, whether your checkout method is still supported, whether two-step login is available, and when older connections stop.

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.

Taking cards through your own website?

Tell us how your customers pay. We will map where card numbers go and what moving to a hosted page involves.

Start a Conversation