Secure payment: e-commerce standards and 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 standard applicable to card data, and the actual use of strong authentication. A merchant compliant on both points bears little risk; a merchant who bypassed authentication to streamline their checkout bears the full cost of fraudulent non-payments.

Strong authentication, and who pays in case of fraud

The European directive on payment services 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 have (phone, card), something they are (fingerprint, facial recognition).

The resulting liability rule is simple and often misunderstood:

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

Exemptions do exist: low-value transactions, trusted beneficiaries registered by the customer, real-time risk analysis under certain conditions. They streamline the checkout flow, at the cost of a shift in liability that must be knowingly accepted.

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

The standard applicable to card data

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

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

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

Tokenization is the answer to the need for recurring payments: 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 adds to sector-specific obligations without replacing them.

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

Storing bank details to facilitate a future purchase requires the customer's specific consent, separate from acceptance of the terms and conditions. A single checkbox covering both the terms and conditions and card retention does not satisfy this requirement — the same reasoning applies as explained for trackers and cookies, where consent must be collected for each purpose.

Non-payments 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 neutralizes it by shifting the burden. It is the only mechanism that truly provides protection.

Abusive chargebacks occur when a customer disputes a transaction they actually made. Here, authentication is not enough: it is necessary to be able to demonstrate delivery and the conformity of the service provided. Useful evidence includes shipment tracking, proof of delivery and the history of exchanges — a topic covered in more detail in our article on delivery and returns obligations.

A third mechanism limits both: capping and filtering of atypical transactions, by amount, frequency or geographic area.

Use-case scenarios

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

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

Phone 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 shifts the burden of fraud to whoever requested it.

Who pays in the event of card fraud? If strong authentication was applied, the burden does not fall on the merchant. If it was 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 requirements depends on volume, but the scope is greatly reduced when the merchant never accesses the data.

Can a card number be stored? Not in plain text, and not without specific consent. Tokenization allows for recurring payments without storing 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 has handled it, including the email system.

How can you defend against an abusive dispute? Through proof of delivery and conformity: shipment tracking, proof of delivery, and history of exchanges. Authentication alone does not address this claim.

Key takeaways

Two decisions determine an online merchant's exposure, and both are made when choosing a payment checkout flow.

The first is to never access card data, letting entry take place at the provider's end. This considerably reduces the compliance burden and eliminates the risk of a data leak.

The second is to keep strong authentication in place rather than invoking exemptions to streamline the checkout flow. Each exemption gains a few points of conversion and shifts the cost of fraud. This trade-off deserves to be calculated explicitly, weighing the actual rate of non-payments against the conversion gain — it is one of the key structural trade-offs of the legal framework for an online store.