Secure Payment: E-commerce Standards and Certifications

When it comes to online payment, the question isn't 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 actual use of strong authentication. A merchant compliant on both counts bears little risk; a merchant who bypassed authentication to smooth out 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 burden 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 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 taken on knowingly.

The customer also has a right to reimbursement in the event of an unauthorized transaction, which their bank must process without delay, unless fraud on their part is suspected. 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 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 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 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 touched the data.

Tokenization is the answer to the need for recurring payments: the merchant keeps 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 for trackers and cookies, where consent must be collected per 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 offers real protection.

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

A third mechanism limits both risks: capping and filtering 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, 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 storing 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 into a 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 shifts the burden of fraud to whoever requested it.

Who pays in case 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 you store a card number? Not in plain text, and not without specific consent. Tokenization enables recurring payments without storing the number itself.

Can a number received by email be entered manually? This should be avoided at all costs: doing so brings the data within the compliance scope of the entire infrastructure that handled it, including the email system.

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

Key takeaways

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

The first is to never access card data, letting entry take place on the provider's side. 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 smooth out 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 non-payment rate against the conversion gain — it is one of the defining trade-offs of the legal framework for an online store.