ESPR and Online Marketplaces: What Platforms, 3PLs, and Brands Selling Through Third-Party Channels Must Know

Most ESPR commentary focuses on the manufacturer, the importer, and the authorised representative. That framing is correct as far as it goes - those actors carry the heaviest obligations. But Regulation (EU) 2024/1781 also names two actor types that have received far less attention: fulfilment service providers and providers of online marketplaces and online search engines. For platform compliance teams, 3PLs serving non-EU sellers, and brands distributing through third-party channels, those provisions are the ones that matter most operationally.

This post covers only those two actor types and how DPP data flows through a platform listing. The manufacturer/importer/distributor duty breakdown is covered in a separate post.

---

Fulfilment Service Providers: Article 27 and the Importer-Substitution Risk

What Article 27 Actually Says

ESPR explicitly covers fulfilment service providers under Article 27, and providers of online marketplaces and online search engines under Article 29. The core obligation in Article 27 is narrow but consequential: fulfilment service providers must ensure that, for products they handle that are covered by a delegated act adopted pursuant to Article 4, the conditions during warehousing, packaging, addressing, or dispatching do not jeopardise the products' compliance with that delegated act.

Read literally, this is a handling-integrity obligation, not a conformity-assessment obligation. The 3PL is not required to verify that the product has a valid DPP, check CE marking, or review technical documentation - those duties sit with the manufacturer and importer. What the 3PL must not do is damage or alter the product in ways that undermine its compliance status.

That is a comparatively light set of obligations. The European Environmental Bureau (EEB) and a coalition of 59 NGOs and industry groups have argued explicitly that this is insufficient - warning that "online sellers could escape the EU's new product sustainability requirements using the E-market loopholes" and calling for stronger proactive duties on platforms and fulfilment operators. The EEB has also stated that "without proper oversight, online marketplaces become a backdoor for environmental dumping." Those arguments did not fully prevail in the final text, but they signal where enforcement pressure is likely to build.

The Importer-Substitution Problem

Here is where Article 27 becomes commercially significant for 3PLs serving non-EU sellers. ESPR, like the Market Surveillance Regulation (EU) 2019/1020 on which it builds, requires that at least one EU-established economic operator be responsible for a product placed on the EU market. The hierarchy runs: manufacturer (if EU-established) -> importer -> authorised representative -> and, as a backstop, the fulfilment service provider.

Where no manufacturer, importer, or authorised representative is established in the EU, the fulfilment service provider established in the Union can end up carrying the obligations of the economic operator responsible for the product. This is not a theoretical edge case. It is the default outcome for any non-EU seller who ships inventory into an EU fulfilment centre without first appointing an authorised representative or using an EU-established importer of record.

For a 3PL, the commercial implications are direct:

• You may become the responsible economic operator by default, not by choice, simply because your client failed to appoint anyone else.
• That means you could be the entity market surveillance authorities contact first, and the entity required to produce technical documentation, DPP records, and conformity declarations you do not hold.
• Unlike importers and authorised representatives, fulfilment service providers have no formal connection with the manufacturer that would enable them to fulfil those tasks - they would need to contractually obtain that information from their clients in advance.

The practical fix is straightforward in principle: 3PLs serving non-EU sellers should require, as a condition of onboarding, evidence that an EU-established importer or authorised representative has been appointed for each product category in scope. Without that evidence, the 3PL is accepting an exposure it may not have priced.

---

Online Marketplaces and Search Engines: Article 29

The Four Core Duties

Article 29 of ESPR sets out the obligations of providers of online marketplaces and online search engines, in particular concerning cooperation with market surveillance authorities. The structure of Article 29 is worth reading carefully, because it layers obligations in a specific way.

First, Article 29 incorporates by reference the general obligations in Articles 11 and 30 of the Digital Services Act (Regulation (EU) 2022/2065). Those DSA provisions - covering notice-and-action mechanisms and transparency - apply to online marketplaces for ESPR purposes. This is a cross-regulation hook, not a standalone ESPR obligation.

Second, and on top of those general DSA obligations, Article 29 adds ESPR-specific duties:

1. Cooperate with market surveillance authorities on request and in specific cases to facilitate action to eliminate or mitigate non-compliance of a product offered for sale online through their services.
2. Comply with orders to remove listings, disable access to non-compliant products, or display warnings to consumers.
3. Grant authorities access to online interfaces for monitoring purposes.
4. Data-scraping backstop: where sellers obstruct or prevent authorities from accessing product information, the marketplace must provide that access through its own interface.

These are reactive obligations - they are triggered by authority requests or orders, not by proactive monitoring duties. That is the key limitation the EEB and others have criticised: the marketplace is not required to verify DPP existence before listing, only to act when told to.

The Interface Design Duty

There is a separate, forward-looking obligation that sits alongside the reactive duties and has significant product-detail-page implications. ESPR requires that online interfaces be designed so that sellers can display the information the regulation requires - including the DPP data carrier and required product information - at the point of sale, including in distance selling.

This is distinct from the physical data carrier requirement. On a physical product, the data carrier (QR code, GS1 DataMatrix, RFID/NFC tag) is affixed to the product or its packaging and travels with it. In a distance sale - where the consumer purchases before receiving the product - the data carrier on the physical item is irrelevant at the moment of purchase decision. The consumer cannot scan a QR code on a product they have not yet received.

The DPP must be accessible to consumers at the place of purchase, including online. That means the marketplace listing itself must surface the DPP link or data carrier equivalent so that a consumer can access the passport before completing the purchase. In practice, this translates to a requirement for a dedicated DPP field in the product listing schema - a URL or resolvable identifier that points to the passport - displayed on the product detail page alongside price, images, and seller information.

This is not a cosmetic change to listing templates. It requires:

• A structured data field in the listing schema to hold the DPP identifier or URL.
• Validation that the identifier resolves to a live, registered passport in the EU DPP Registry.
• Display logic that renders the DPP link in a consumer-accessible format on the product detail page.
• Consistency between the identifier in the listing and the identifier on the physical product - mismatches between the two are a realistic and auditable failure mode.

---

The Regulatory Stack: ESPR, DSA, and GPSR

Platform compliance teams need to hold three distinct regimes in mind simultaneously, and the attribution of obligations to specific articles matters.

A critical attribution note: Trader traceability - the "know your business customer" obligation requiring marketplaces to collect and verify seller identity information before allowing them to list - is Article 30 of the DSA, not ESPR. It is in force since 17 February 2024. Do not attribute it to ESPR. The two regimes are complementary: DSA Article 30 ensures you know who your sellers are; ESPR Article 29 governs what you must do when those sellers' products turn out to be non-compliant.

Similarly, the GPSR (Regulation (EU) 2023/988) imposes its own marketplace obligations - including the requirement that a responsible person established in the EU exists for every product listed. GPSR marketplace duties sit alongside ESPR, not inside it.

---

Realistic Failure Modes

The gap between the text of Article 29 and real-world platform operations is wide. Here are the failure modes most likely to attract enforcement attention once delegated acts start applying:

1. Listings with no DPP link. Once a delegated act applies to a product category, a listing without a surfaced DPP identifier is non-compliant. Platforms relying on sellers to voluntarily include DPP data in free-text fields will find that field empty for most SKUs.

2. Mismatched identifiers. The unique product identifier in the listing must match the identifier registered in the EU DPP Registry and the data carrier on the physical product. Sellers who generate a DPP for one product variant and apply it to a listing for a different variant - or who update the physical product without updating the registry entry - create a mismatch that is detectable by market surveillance authorities with basic tooling.

3. Dropshipped goods with no EU-established operator. A non-EU seller dropshipping directly to EU consumers through a marketplace, with no EU importer, no authorised representative, and no EU-established fulfilment provider, leaves a gap in the economic operator chain that ESPR requires to be filled. The marketplace is not automatically the responsible operator, but it may be the only entity authorities can reach.

4. Seller attestation with no verification. Platforms that collect a seller's self-certification that their products have a valid DPP - without any technical check that the identifier resolves, is registered, and matches the product - are building a compliance process that looks adequate on paper but will not survive a market surveillance audit.

---

What to Build Now

Delegated acts for the first product categories are expected from 2027 onwards, with batteries under the separate Battery Regulation already carrying a hard deadline of 18 February 2027. The infrastructure changes needed to surface DPP data in listings are not trivial, and the lead time for platform engineering work is measured in quarters, not weeks.

For Platform Operators

• Add a DPP field to your listing schema now. A structured, validated field for a DPP identifier or URL is the minimum infrastructure requirement. Free-text product description fields are not adequate.
• Build identifier validation into the listing flow. At minimum, check that the identifier resolves. Once the EU DPP Registry is operational (required by 19 July 2026), validation against the registry should be part of the listing submission process for in-scope product categories.
• Design a takedown workflow. Article 29 requires compliance with authority orders to remove listings or disable access. That workflow needs to be documented, tested, and operable within the timeframes authorities will expect.
• Integrate DSA Article 30 KYBC data with ESPR onboarding checks. The seller identity data you collect under DSA Article 30 is the foundation for verifying whether an EU responsible person exists - a GPSR requirement that also underpins ESPR compliance. These should be a single onboarding flow, not separate silos.

For Sellers on Third-Party Platforms

• Be ready to supply a DPP identifier at listing time, not after the product ships. The identifier must be registered in the EU DPP Registry before market placement.
• Ensure identifier consistency across the registry entry, the listing, and the physical data carrier on the product. Treat these as a single system, not three separate tasks.
• Appoint an EU authorised representative or use an EU importer of record before listing on any EU-facing marketplace. Do not assume the marketplace or 3PL will absorb that obligation.

For Brands Selling Through Third-Party Platforms

If you are a brand whose products are sold through third-party marketplaces - whether you supply those marketplaces directly or sell through distributors who do - you retain responsibility for the DPP and the data it contains. The marketplace is not your compliance backstop.

Contractually, this means:

• Require distributors and resellers to surface your DPP identifier in their listings, not substitute their own or omit it.
• Audit listings periodically for identifier accuracy and DPP accessibility. A distributor who lists your product with a broken or missing DPP link is creating a compliance gap that traces back to you.
• Include DPP data-supply obligations in your distribution agreements - specifying the format, the update cadence, and the consequences of non-compliance.

---

The Honest Assessment

ESPR's obligations on fulfilment service providers and online marketplaces are, as currently drafted, lighter than those on manufacturers and importers. The handling-integrity duty in Article 27 and the reactive cooperation duties in Article 29 do not require platforms or 3PLs to proactively verify DPP compliance before a product is listed or handled. The EEB and a broad coalition of NGOs and industry groups have argued this is a structural weakness that creates a route for non-compliant products - particularly from non-EU sellers - to reach EU consumers without meaningful gatekeeping.

That policy debate is ongoing. What is not debatable is the interface design obligation: once delegated acts apply, platforms must be capable of surfacing DPP data at the point of sale. That is an engineering and data-architecture requirement, not a legal formality. The time to build it is before the first delegated act lands, not after.