The payment form appears twice during checkout

Why double entry is the most reliable symptom

A customer writes in to say they had to enter their card twice: the first page seemed to reload, then the usual payment form asked for the same details again. The order went through, the amount is right, only one charge appears. From the back office, nothing looks wrong.

That is precisely the signature of a technique Sansec documented in February 2026 as “double-tap skimming”, detected on 16 February 2026 on the shop of a supermarket chain in the global top 10 — around €100 billion in annual revenue, more than 10,000 stores across 25 countries — part of whose e-commerce infrastructure runs on PrestaShop. A fake payment form appears first and captures the card details, then the real form takes over and the order completes normally. Most customers accept the second entry without suspecting the data has already been stolen.

The symptom is reliable because it is structural. The theft needs the customer to fill in a form that leads nowhere, so it needs them to start again. On the merchant side there is no alert, no abnormal failure rate, no odd line in the orders: you hear about it from a customer who found it strange, or from a fraud chargeback a month later.

Where to look: theme files, then the database

Sansec points to two places on the merchant side. First, script tags injected into theme files, notably _partials/head.tpl on PrestaShop: the template loaded on every page, checkout included. Second, JavaScript that watches input fields and stores the values in the browser’s localStorage under a prefix, to be picked up and sent elsewhere. I am not publishing the destination.

The database is the other place to open. In January 2025 PrestaShop documented a wave of attacks exploiting SQL injection in third-party modules, not in the core, to plant malicious content in the PS_SHOP_NAME configuration value. That value is then used to load unauthorised JavaScript which captures customer input. The recommended check is direct: read PS_SHOP_NAME in the database and confirm it holds nothing but your shop name. PrestaShop also advises updating every native and third-party module, using a custom database prefix rather than ps_, and running a web application firewall.

Both routes tell the same story: a theme template and a configuration value are two places nobody ever re-reads, and they decide what runs on the payment page.

Hosted payment fields do not put you out of reach

Many merchants consider the matter closed because card entry happens in a frame or on a page hosted by the payment provider, so card numbers never touch their server. That holds for the form itself. It does not hold for the page around it.

In the double entry scenario the injected code does not attack the provider’s field: it renders its own overlay before it, inside the page you control. The customer sees a credible payment screen, in their language and in your branding — Sansec notes these overlays are now carefully localised and that generative AI tools speed up their production. As long as the page hosting the payment can be modified, a hosted integration does not prevent the theft.

What this page does not contain

I am not writing any method for reproducing the attack, any injected code, any destination address, or any way of finding vulnerable shops. This page exists to observe, verify and fix, not to equip anyone.

If any of the signs above is present, the next step is not patching one file: it is a full clean-up, rotating every credential, and putting integrity monitoring on the payment page so the next change is caught the same day rather than a month later by a chargeback.