Secure payments: standards and e-commerce certifications

When it comes to online payment, the question is not whether an incident will occur, but who will bear the cost. The answer depends on two factors: compliance with the applicable card data standard, and the actual use of strong authentication. A merchant compliant on both counts bears little risk; a merchant who has bypassed authentication to streamline their checkout bears the full cost of fraudulent non-payments.

Strong authentication, and who pays in the event of fraud

The European payment services directive requires strong customer authentication for most online transactions. It relies on at least two independent elements from three categories: something the customer knows (password, code), something they possess (phone, card), something they are (fingerprint, facial recognition).

The resulting liability rule is simple and often misunderstood:

• Where strong authentication has been applied, the burden of a disputed fraudulent transaction does not fall on the merchant.
• Where it has been waived — through an exemption invoked by the merchant or their provider — the risk shifts to whoever requested the exemption.

Exemptions exist: low-value transactions, trusted beneficiaries registered by the customer, real-time risk analysis under certain conditions. They smooth the customer journey, at the cost of a transfer of liability that must be taken on knowingly.

The customer also has a right to a refund in the event of an unauthorised transaction, which their bank must process without delay, unless there is suspicion of fraud on their part. The dispute is then settled between the institutions and the merchant.

The applicable card data standard

Any entity that stores, processes or transmits card data is subject to the industry security standard, regardless of its transaction volume. The level of requirement varies according to the number of annual transactions, but the principle itself is not negotiable.

The most effective way to reduce this burden is to reduce the scope. A merchant who never has access to card data — because entry takes place in a field hosted by the payment provider, or on a redirected page — sees their obligations considerably lightened.

Two practices cancel out this benefit and are regularly encountered: receiving a card number by email or telephone and entering it oneself, and storing numbers in a file "to make future orders easier". In both cases, the scope extends to the entire infrastructure that has touched the data.

Tokenisation is the answer to the need for recurring payment: the merchant retains a token that is unusable outside its context, never the number itself.

What falls under data protection

Payment data is personal data, and its processing is an addition to sector-specific obligations, not a substitute for them.

Three points structure compliance: a legal basis for each processing operation, a retention period limited to what is necessary, and contractual oversight of the payment provider as a data processor.

Retaining bank details to facilitate a future purchase requires the customer's specific consent, separate from acceptance of the terms and conditions. A single tick box covering both the terms and conditions and the retention of the card does not meet this requirement — the same reasoning as that set out for trackers and cookies, where consent must be obtained per purpose.

Non-payment and fraud prevention

Two distinct risks weigh on a merchant, and they call for different responses.

Fraudulent non-payment results from a stolen card or identity theft. Strong authentication neutralises this by shifting the burden. It is the only measure that offers real protection.

Abusive chargebacks occur when a customer disputes a transaction they nevertheless carried out. Here, authentication alone is not enough: it must be possible to demonstrate delivery and the conformity of the service. Useful evidence includes shipment traceability, proof of delivery and the history of exchanges — a subject covered in our article on delivery and returns obligations.

A third safeguard limits both risks: caps and filtering of atypical transactions, by amount, frequency or geographic area.

Usage scenarios

Standard online shop. Use an entry field hosted by the provider, never touch card data, and keep strong authentication enabled by default. This is the configuration that minimises both the compliance burden and the financial risk.

Recurring subscription. Use tokenisation, with specific customer consent for retaining the payment method, separate from acceptance of the terms and conditions.

Telephone sales. This is the riskiest situation: no strong authentication, data dictated verbally. It is preferable to send a payment link, which brings the transaction back within a secure framework and leaves a trace.

Frequently asked questions

Is strong authentication mandatory? Yes, for most online transactions, except under regulated exemptions. Invoking an exemption transfers the burden of fraud to whoever requests it.

Who pays in the event of card fraud? If strong authentication has been applied, the burden does not fall on the merchant. If it has been waived through an exemption, it shifts to whoever requested it.

Do you need to be certified to sell online? The standard applies as soon as card data is stored, processed or transmitted. The level of requirement depends on volume, but the scope is significantly reduced when the merchant never has access to the data.

Can a card number be retained? Not in plain text, and not without specific consent. Tokenisation allows recurring payment without retaining the number itself.

Can a number received by email be entered? This should be avoided at all costs: the data then falls within the compliance scope of the entire infrastructure that handled it, including the mailbox.

How can you defend against an abusive dispute? Through proof of delivery and conformity: shipment traceability, proof of delivery, history of exchanges. Authentication alone does not answer this type of complaint.

Key takeaways

Two decisions determine an online merchant's exposure, and both are taken at the point of choosing a payment checkout.

The first is never to access card data, letting entry take place with the provider. This considerably reduces the compliance burden and eliminates the risk of leaks.

The second is to keep strong authentication rather than invoking exemptions to smooth the customer journey. Each exemption gains a few conversion points and transfers the cost of fraud. The calculation deserves to be made explicitly, weighing the actual non-payment rate against the conversion gain — this is one of the key trade-offs in the legal framework of an online shop.