A 2027 live-commerce experiment is already asking retailers to build a separate checkout, integrate with a selected payment provider and measure refunds and failures. The economics of a future digital euro, however, cannot be inferred from the pilot’s fee-free transactions.
As of October 18, 2026, the European Central Bank is recruiting e-commerce and mobile-commerce merchants for a controlled test beginning in the second half of 2027. Applications close on October 27, 2026, at 17:00 CET. The test is significant because it turns years of currency architecture into a practical retail question: can a shopper finish an online purchase, obtain a refund and resolve a payment problem without creating another fragmented checkout system? The central conclusion is deliberately narrower than the usual digital-euro narrative. A merchant can test an ECB-supported payment flow next year; it cannot yet assume a commercially launched digital euro, permanent zero merchant fees or guaranteed conversion gains.
What Exactly Will Be Tested—and What Will Not?
The 12-month pilot is expected to begin in the second half of 2027. Thirty-six euro-area payment service providers have been selected. Initial individual users will be staff of the ECB and participating national central banks, rather than an open population of European consumers. Merchants must be accepted into the pilot and connect to an acquiring participating payment service provider (PSP). The ECB describes the beta instrument as an experimental payment service; it is not the final digital euro and is not a commercial retail currency already in circulation [1][2].
The difference matters to planning and valuation. A business integrating a payment option for several hundred eligible staff members has tested workflows, not general-market consumer demand. Pilot adoption is intentionally constrained. A high payment success rate could demonstrate technical readiness while telling almost nothing about how millions of consumers would choose among cards, account-to-account transfers and central-bank digital money. Conversely, a weak result may reflect the pilot’s limited user pool and special access restrictions rather than a fatal defect in the eventual design.
The central bank’s September 15 invitation specifically concerns remote person-to-business payments: online and mobile checkout. The broader pilot also covers person-to-person and proximity transactions. It is a mistake to take one merchant’s online acceptance experiment as proof that offline, in-store and cross-border retail experiences are production-ready. The bank has said it aims to be prepared for a possible initial issuance in 2029, subject to legislation and a later issuance decision; neither the pilot nor the tentative date commits it to launch [1][3].
A useful analogy is payment-system certification, not a cryptocurrency token listing. Retailers are being invited to produce evidence about integration, payment completion, recovery from errors, reconciliation and customer experience. That evidence may influence future technical requirements. It does not create an entitlement to an exclusive digital-euro merchant channel.
The Checkout Journey: Who Does What?
The transaction chain has at least five operational actors: the eligible customer, the merchant checkout, the acquiring PSP, the distributor PSP serving the payer, and the Eurosystem’s digital euro service platform (DESP). The pilot merchant supplies the online shopping experience, checkout integration, fulfilment and customer service. The acquiring PSP provides merchant-facing payment acceptance, onboarding and integration assistance. The distributing PSP offers the payer access through the Eurosystem-provided application or a participating PSP’s app [2].
For a remote purchase, a test customer selects the beta digital euro on a restricted checkout page. The PSP-driven flow initiates and validates the payment; the underlying platform supports inter-PSP message routing and settlement functions. The merchant must obtain an unambiguous success or rejection status before releasing the order. It then has to reconcile that event to its order identifier, inventory reservation and merchant account ledger. The public technical documentation describes distinct payment and refund identifiers: a refund is linked to the original payment instruction, not merely to an invoice number invented by the store [2][4].
A merchant should not design the checkout around a simplistic assumption that a payment confirmation, delivery confirmation and receipt are one event. An authorization-like step could succeed while its acknowledgement is lost. A shopper might reload a page, causing an accidental duplicate attempt. A partial refund for two out of five products is a different operation from cancelling the entire order. Each state requires clear system ownership, idempotent order handling and a customer-facing explanation. This is exactly the kind of real commerce complexity that a pilot is supposed to uncover.
The ECB requires participating online merchants to offer a dedicated or suitably adapted checkout visible only to pilot users. The merchant must not display the experimental button to its entire customer base. That rule both protects non-participants from failed journeys and makes this a genuine development project: product flags, eligibility checks, staff testing, refund flows and customer support scripts must all agree on who is allowed to pay [2]. The design resembles the way large payment processors isolate a beta payment method from production, a point underscored by Worldpay’s separate authorization and settlement disruptions.
Two Contracts, Three Responsibilities
Merchant access is not secured merely by passing a PSP’s normal onboarding process. Eligible sellers need a merchant participation agreement with the ECB and an acquiring arrangement with a pilot PSP. The former governs experimental participation and feedback; the latter makes transactions possible. Merchants must also have the required establishment and reach across at least two pilot locations, subject to the ECB’s detailed eligibility and weighted selection criteria. High-risk sectors may be excluded under the call documentation [2][3].
The responsibility split is strategically important. The ECB is running the pilot and supplying its shared payment infrastructure. A PSP runs the acquiring relationship and merchant integration. The seller remains responsible for its store, shipping commitments, return policies, accounting and customer communications. A payment pilot does not transfer obligations under consumer law or data-protection law from merchants to central banks. The ECB specifically points to existing payment-services, anti-money-laundering and privacy regimes applicable to pilot PSPs [2].
For an online retailer, the legal questions must be converted into operational ones: Which entity receives a disputed payment instruction? Who decides a refund? What evidence is preserved for a customer saying the item never arrived? Who has personal data, and which data may be retained after the pilot? What happens to any unresolved complaint when the 12-month test ends? These are commercial risk allocations. A retailer should request explicit answers before agreeing to dedicate engineering capacity.
There is also a marketing constraint. A selected merchant should not claim the ECB has endorsed its business or imply that pilot participation guarantees access to a future digital euro. The central bank says participation confers no future rights. The experiment produces feedback, not exclusivity or a brand license [2].
What Does “No Fees” Actually Mean?
An easily missed detail in the ECB FAQ is that pilot PSPs cannot charge participating users, including merchants, fees for the pilot payment services. Merchants nevertheless bear their own costs for technical integration, testing and operations, and the ECB is not offering a participation subsidy [2]. The zero-fee rule applies to a controlled experiment, not to a future final merchant-pricing rule.
Consider an illustrative e-commerce business that sells 10,000 orders per month at an average ticket of €45. Assume its current marginal payment-acquiring cost is 1.4% plus €0.20 per transaction, or €0.83 per order. If a hypothetical future alternative displaced 5% of its orders and cost nothing per transaction, the maximum avoidable variable fee would be 500 × €0.83 = €415 a month, before any new operating costs. At 20% share the gross avoided fee would rise to €1,660 monthly. Neither outcome is a forecast, and the figures are not terms announced by the ECB for a final digital euro.
Suppose implementation costs €18,000 and additional operations €250 per month. Under that deliberately optimistic zero-per-transaction-fee scenario, adoption would need to exceed approximately 21.1% just to cover the ongoing €250 plus recover €1,500 a month over 12 months: (€1,500 + €250) ÷ (€0.83 × 10,000). A small pilot can be valuable as research while remaining uneconomic as an immediate cash-saving project. A multi-year merchant strategy should model future fees, fraud losses, dispute costs and technical debt, not simply quote the pilot tariff.
FIGURE 1 — Hypothetical avoided card fees at different future adoption rates
The distinction is even clearer in the pilot itself. The shopper population is restricted, the seller carries its own integration bill, and there is no commercially representative mix of payment instruments. Even if the payment processing is technically successful, a positive ROI must come primarily from information and readiness, not transaction fee savings. This is similar to Xendit’s repeated payout recovery problems, where reliability and recovery evidence matter more than the theoretical cost of an API call.
The Merchant’s Four Most Valuable Metrics
Raw “payment success rate” is not enough. A checkout can succeed technically and still perform badly commercially if customers abandon extra screens, receive confusing refund explanations or lose access to order status. A practical scorecard should follow payment initiation to merchant-recognized receipt and eventually to reconciled settlement. It should also record the share of orders needing manual customer support.
First measure completed paid orders per eligible checkout session, not merely accepted PSP requests. Second, measure median and 95th-percentile time to confirmed payment; a slow tail is what shoppers experience during outages. Third, measure duplicate attempts, recoverable errors and irreconcilable orders. Fourth, measure the elapsed time and failure rate for linked full and partial refunds. A payment solution with attractive headline settlement economics can lose value through support and exception handling.
Illustratively, out of 1,000 eligible test checkout starts, suppose 930 reach payment confirmation, 25 become retry loops, 20 time out and 25 are actively abandoned. The completion rate is 93%. If 10 of the confirmed payments later require manual reconciliation, an operations-adjusted clean-completion measure falls to 92%. That one-percentage-point gap can matter more to a small retailer than a few basis points of hypothetical fee reduction. Labels and denominators must remain stable: a merchant should not compare “authorizations attempted” in cards with “checkouts opened” in a new app and conclude one rail is superior.
FIGURE 2 — Illustrative 1,000-checkout funnel with support exceptions
Separate incident categories are vital. A merchant should be able to distinguish payer authentication problems from checkout code failures, PSP outages and settlement delays. The value of tracing dependencies was also demonstrated in the Paystack and PawaPay telecom disruption, where a shared upstream provider contributed to seemingly separate business-facing failures. A digital euro does not remove upstream integration risk by naming a common settlement asset.
Refunds, Data and Merchant Working Capital
The ECB explicitly treats business-to-person refunds as part of the remote purchase use case, not as a separate extra payment category. Public materials refer to an original payment-instruction identifier that links a refund to the initial transaction. This matters because an online shop’s refund logic touches inventory management, card-replacement customer journeys, consumer-protection obligations and finance-team reconciliation [2][4]. A payment innovation without credible exception handling will not be merchant-ready.
Cash-flow claims deserve particular restraint. Pilot PSPs manage related liquidity and technical accounts; the ECB FAQ describes manual funding and defunding of dedicated settlement accounts during the pilot. It would be inaccurate to promise that a merchant receives bank-deposit-like funding on precisely the same timetable as a familiar card acquiring product. The beta monetary arrangements themselves are pilot-specific, and the future regulatory design may differ [2].
A merchant should perform separate ledger reconciliations for initiated payment, confirmed payment, funded balance and refunded amount. A €90 sale refunded by €30 and then €60 produces two refund events but no net revenue, despite the presence of multiple completed payment messages. That is an accounting logic test, not a statement about whether the final digital euro could be programmable. Retailers should resist confusing conditional business processes built on a payment rail with central-bank programming of the money itself.
How Should an Online Merchant Decide Whether to Apply?
The ECB application window closes October 27, 2026. A merchant with an established euro-area presence, internal product-development capacity and a credible pilot PSP relationship could gain real operational insight. A seller that relies on a fragile checkout plugin and a single developer may find the effort disproportionately costly. The commercial decision should start with an estimate of engineering hours, testing environments, support training, security review and the cost of maintaining a restricted checkout for one year.
There are four conditions under which participation is more persuasive: the retailer can isolate beta users safely; it can log payments and refunds at order level; it can measure failure causes without exposing customer data; and it has a specific product-learning question that the pilot can answer. If its only expected benefit is “free processing,” the business case is weak. Fees during the pilot cannot be mistaken for the economics of a final product.
A useful counterfactual is to ask what would falsify the bullish merchant thesis. If integration requires bespoke development for every acquiring PSP, if payment completion takes longer than existing alternatives, if refund matching produces high support costs, or if pilot outcomes cannot be replicated at scale, retailers should discount any projected future savings. A common technical platform does not automatically eliminate commercial fragmentation.
FIGURE 3 — Merchant break-even adoption sensitivity under hypothetical implementation costs
Bottom Line
The digital euro pilot is best understood as a coordinated merchant and PSP systems test, not a consumer launch or a pricing announcement. It will test restricted online shopping, acquiring integration, payment-state reliability and connected refunds. Selected retailers must bring a dedicated checkout, comply with two contractual relationships and finance their own internal work. The best output is a reproducible evidence set: conversion, latency, exception handling, reconciliation and customer service costs. It is those metrics—not an ECB logo beside a zero-fee beta button—that will decide whether the digital euro improves everyday commerce.
Methodology
All figures marked illustrative are original arithmetic based on assumed 10,000 monthly orders, €45 ticket size, incumbent marginal fee of 1.4% plus €0.20, €18,000 integration and €250 monthly running cost. They do not report pilot transaction volumes, an ECB fee proposal or a forecast of consumer adoption. The 30.1% break-even is a 12-month amortization scenario with no alternative marginal fee, and excludes refunds and fraud cost differences. Official statements were checked as of October 18, 2026.
Sources
Primary documents and official materials were checked on October 18, 2026. Titles link to source pages.
[1] ECB — Digital euro pilot overview and selected PSPs — Official timetable, 36 participating PSPs, restricted test population, and conditional issuance pathway.
[2] ECB — Digital euro pilot frequently asked questions, updated September 15, 2026 — Detailed eligibility, merchant checkout isolation, pilot fees, refunds and data responsibilities.
[3] ECB — Call for e-commerce and m-commerce merchants, September 15, 2026 — Original September merchant recruitment notice and binding application deadline.
[4] ECB — Digital euro pilot technical documents and research index — Index to the technical requirements a merchant integration team should examine.
[5] ECB — Digital euro overview and design FAQ, August 17, 2026 — ECB distinction between preparatory test, legal issuance, and future design intentions.
[6] ECB — March 2026 call for PSP participation — Shows the separate earlier selection process for the payment service providers.
[7] European Commission — Digital euro legislative proposal, COM(2023)369 — The Commission proposal, not adopted final merchant law; useful for legal context.
[8] Council of the EU — Council negotiating position on the digital euro, December 19, 2025 — Council negotiating position including proposed fee caps, distinct from pilot pricing.
[9] European Commission — FAQ on digital euro merchant acceptance and proposed merchant-fee rules — Commission explanation of prospective acceptance and compensation, not settled rules.
[10] EUR-Lex — Legislative procedure 2023/0212(COD): digital euro — Legislative docket confirming the proposed regulation is a continuing procedure.
[11] ECB — Digital euro pilot frontend acceptance-instrument specifications (April 2026) — Merchant payment and refund frontend design references for test engineering.
[12] EUR-Lex — Payment Services Directive (PSD2): Directive 2015/2366 — Existing payment-services directive cited in the pilot regulatory framework.
Johan Shamshad is a financial markets writer at Dave Finances covering cryptocurrencies, trading platforms, brokers, fintech, financial regulation, and developments across global markets. He previously worked at Gulf News, adding newsroom experience to his coverage of fast-moving financial and digital-asset markets.
His work focuses on identifying market-moving events, company developments, regulatory changes, product launches, and shifts in trading and financial infrastructure.
Johan contributes news and analysis designed to help readers understand not only what happened, but why a development matters and how it may affect the wider financial landscape. You can reach out to him via his social media accounts:
Linkedin: https://www.linkedin.com/in/johan-shamshad-742851262/
X: https://x.com/Yasmine_FX
Investing: https://www.investing.com/members/contributors/279781574