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 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 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 possess (phone, card), something they are (fingerprint, facial recognition).

The liability rule that follows from this is simple and often misunderstood:

• When strong authentication has been applied, the burden of a disputed fraudulent transaction does not fall on the merchant.
• When it has been bypassed — 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 streamline the journey, at the cost of a transfer of liability that must be undertaken 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 standard for card data

Any entity that stores, processes or transmits card data is subject to the sector's security standard, regardless of its volume of activity. The level of requirement 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 has access to card data — because entry takes place in a field hosted by the payment provider, or on a redirected page — sees its obligations considerably lightened.

Two practices cancel out this benefit and are regularly encountered: receiving a card number by email or phone 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 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 a contractual framework governing the payment provider in its capacity as processor.

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

Non-payment and the fight against fraud

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 it by transferring the burden. It is the only mechanism that genuinely protects.

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

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

Usage scenarios

Standard online store. Use an entry field hosted by the provider, never touch card data, 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 the customer's specific consent for storing the payment method, distinct from acceptance of the terms and conditions.

Sale by phone. 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 the secure framework and leaves a trace.

Frequently asked questions

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

Who pays in case of card fraud? If strong authentication was applied, the burden does not fall on the merchant. If it was bypassed via an exemption, it shifts to whoever requested it.

Do you need certification 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 greatly reduced when the merchant never accesses the data.

Can a card number be stored? Not in plain text, and not without specific consent. Tokenisation enables recurring payment 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 processed it, including the email system.

How can one defend against an abusive dispute? Through proof of delivery and conformity: shipment traceability, proof of delivery, exchange history. Authentication alone does not address this grievance.

Key takeaways

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

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

The second is to retain strong authentication rather than invoking exemptions to streamline the journey. Every exemption gains a few conversion points and transfers the cost of fraud. This trade-off deserves to be calculated explicitly, weighing the actual non-payment rate against the conversion gain — it is one of the structuring trade-offs of the legal framework of an online store.