A Digital Product Passport readiness checklist for PrestaShop merchants

There is a predictable way that Digital Product Passport projects go wrong. A merchant reads about the regulation, concludes it is a software problem, buys or builds a module, and then discovers that the module has three hundred empty fields and no one can fill them. The software was the easy part. Getting a supplier in another country to tell you the recycled content percentage of a component, in writing, with a document behind it, is the hard part — and it takes months.

So this checklist is ordered by lead time. The things at the top are the things that will still be in progress a year from now if you do not start them. The things at the bottom can be done in a fortnight whenever you like.

Phase 1 — Scope: what do you actually sell?

You cannot collect data until you know which products need it, and catalogue data is rarely organised the way regulation is.

• Export your full catalogue with supplier, brand, country of manufacture and category. Not the merchandising category — the physical product type.
• Tag each product against a regulated product group. Expect this to be messy. Retail categories and regulatory product groups do not line up, and a single SKU can sit in two regimes at once.
• Flag every product containing a battery. The battery obligation attaches to the battery, not to the finished product, and it catches merchants who do not think of themselves as battery sellers at all.
• Identify your role per product line — reseller, importer, or own-brand. This single distinction changes whether you owe the whole passport or almost none of it, and it frequently varies across lines within one store.
• Separate EU-market sales from the rest. If you ship outside the EU as well, the obligation follows the market, not the warehouse.

The output of this phase is a spreadsheet where every SKU has a product group, a role and an in-scope flag. It is unglamorous and it is the foundation for everything else.

Phase 2 — Gap analysis: what data is missing?

For each in-scope product group, list the required fields, then check what you already hold. Merchants are usually surprised in both directions: some fields are already in the catalogue as unstructured marketing text, and others have never been recorded by anyone in the chain.

• Fields you already have, in the wrong form. "Made with 40% recycled aluminium" in a description is data — it is just not structured, sourced or verifiable. Extract it, but do not trust it until the supplier confirms it.
• Fields nobody in your chain holds. Carbon footprint figures are the usual example. These require calculation to a defined methodology, not estimation, and if your supplier has never produced one it will take them a long time.
• Fields that vary by batch. Recycled content often changes between production runs. If your passport data model assumes one value per SKU forever, it will be wrong the first time a supplier changes feedstock.

Rank the gaps by how many SKUs they affect and how hard the data is to obtain. That ranking is your supplier request order.

Phase 3 — Suppliers: start now, this is the long pole

This is the phase to start first and the one merchants start last. Budget six to eighteen months across a full supplier base, and expect a meaningful minority never to respond usefully at all.

• Write one request template per product group, listing the exact fields, the units, and the evidence you need behind each. Vague requests get vague answers that you cannot put in a passport.
• Ask for the document, not just the number. A percentage in an email is not something you can stand behind if an authority asks. A test report or a declaration on letterhead is.
• Put it in new purchasing contracts. The cheapest time to get passport data is when you are negotiating anything else. Renewals are a natural hook.
• Track response status per supplier per field, not per supplier. "Supplier responded" is not a useful state when they answered four fields out of eleven.
• Have a plan for non-responders. Sometimes the answer is a different supplier. It is better to learn that eighteen months out than three weeks out.

Phase 4 — Data model: design for the import

Only now is it worth designing storage. Doing it earlier means designing against a guess at what the data looks like; doing it now means designing against real supplier responses.

• Design the import format first. It is the import that reveals which fields are multi-valued, which need units, and which need a date range. Build the schema to fit the import, not the other way around.
• Type everything. A percentage is a number with a unit and a valid range, not a string. Weak typing is how "40%", "0.4" and "forty percent" end up in the same column.
• Store provenance alongside each value — where it came from, when, and which document backs it. You will need this the first time a figure is challenged.
• Version it. When a value changes you need to know what the passport said before, because products sold under the old value are still out there.
• Plan for multiple languages if you sell across the EU. Some passport content is consumer-facing text, and consumer-facing means in the consumer's language.

The PrestaShop guides cover how this maps onto features, custom entities and modules for each version.

Phase 5 — Identifiers and carriers

• Decide your identifier scheme before you print anything. Identifiers have to be unique, stable and resolvable, and changing scheme after products are in the field is unpleasant.
• Make the URL permanent. The passport has to stay reachable for a long period after sale — longer than most merchants keep a URL structure stable. Do not put a CMS category or a year in the path.
• Test the QR at real print size, on the real substrate, after whatever finishing process the packaging goes through. A code that scans on screen and not on a matte laminated box is a code that does not work.
• Decide what happens to old products. Products already sold, discontinued lines, and returned stock all still have identifiers that someone may scan.

Phase 6 — Storefront display

• Put the passport, or a link to it, on the product page. The distance-selling requirement means consumer-facing passport information must be available before purchase.
• Make it work without JavaScript and on a phone with a poor connection — the person scanning a QR code in a recycling centre is not on your office wifi.
• Do not gate it. No login, no cookie wall, no interstitial between the scan and the data.
• Make it accessible. A passport rendered only as an image of a table is not machine-readable and not screen-reader readable.

Phase 7 — Operations: keep it true

A passport is not a launch, it is a maintained record. The failure mode a year in is a catalogue full of passports that were accurate when published and are quietly wrong now.

• Make passport data part of onboarding a new SKU, so the gap never reopens.
• Re-request supplier data on a cycle, and whenever a supplier changes a component.
• Monitor for broken passport URLs the way you monitor for broken product pages, because a dead passport link is a compliance failure and not just a 404.
• Keep an audit trail that lets you answer "what did this passport say on this date" without archaeology.

If you only do three things

For a merchant who cannot resource all of this, the three that matter most, in order:

1. Establish your role per product line. It determines whether you have a large problem or a small one, and it is a day's work.
2. Start the supplier data requests. Nothing else has a lead time like this, and every week of delay is a week added to the end.
3. Fix the identifier and URL scheme before printing anything. It is the one decision that is genuinely expensive to reverse.

Questions

Sources

• Regulation (EU) 2024/1781 (ESPR) — full text on EUR-Lex
• Regulation (EU) 2019/1020 — economic operator obligations