If you sell to French or Benelux customers, relay-point delivery isn't a nice-to-have bolted onto your carrier list, for a large share of shoppers in those markets it's the default way they expect to receive a parcel. Mondial Relay is the dominant relay network across France, Belgium, Spain, the Netherlands, Luxembourg and Portugal, and the whole proposition rests on one screen: the map widget where a customer picks the shop, locker or tobacconist they'll collect from. That widget is also where most PrestaShop integrations quietly break. This guide is specifically about getting Mondial Relay relay points working inside PrestaShop checkout, the merchant account, the carrier mapping, the point-selection widget, labels and the tracking-URL gotcha. For choosing a carrier mix in the first place, or for the generic mechanics of carrier modules, the cluster links below carry that weight so this page can stay on its one job.
Last updated: June 2026.
Why relay points are a distinct integration problem
"Livraison en point relais" means the parcel goes to a local pickup point, a shop, a tobacconist, a florist, an automated locker, rather than the customer's door. Two consequences make this fundamentally different to wire into PrestaShop than a plain home carrier like Colissimo:
- Checkout needs an extra piece of data. A normal carrier needs nothing beyond the delivery address. A relay carrier needs the selected relay point ID captured at checkout and stored against the order. Otherwise you have a paid order with no destination. That single requirement is the source of most "it doesn't work" tickets.
- The customer makes a choice on a third-party widget. The relay map is an external JavaScript component injected into your checkout. It has to know the delivery postcode before it can render points, which means it's sensitive to where your theme places the carrier step relative to the address step.
The business case is genuinely strong. Relay drop-off costs the carrier fewer individual stops, so relay rates run materially below home-delivery rates, and you eliminate the failed-delivery "sorry we missed you" loop entirely. But the savings only land if the widget converts, so most of this guide is about that widget.
Before you install: the Mondial Relay account and server prerequisites
You can't configure anything in PrestaShop until you hold a Mondial Relay professional contract, because the API credentials come from it:
- Merchant contract at mondialrelay.com. You'll be issued a Brand ID (Enseigne), an 8-character code, plus a private key used to sign requests, and API credentials.
- PHP SOAP extension. Mondial Relay's classic API is SOAP-based. Confirm with php -m that soap is listed; if it isn't, your host needs to enable it (typically the php-soap package). Without it, label generation throws a SOAP error on every order.
- HTTPS. The relay widget loads over HTTPS and modern browsers block mixed content, so a valid SSL certificate is non-negotiable. Which on any live PrestaShop store you already have.
- A supported PrestaShop version. The official Mondial Relay module targets recent 1.7.x and 8.x. On 1.6 you're on an older module build or a third-party carrier, verify before you commit, because the widget code differs between generations.
Installing and configuring the module
Mondial Relay publishes an official free module, available both on PrestaShop Addons (listed as "Mondial Relay Official") and from its own merchant portal. Either way, download the ZIP and upload it through Modules → Module Manager → Upload a module in your back office. After it installs, open its configuration and fill in the fields that actually matter for relay delivery:
| Setting | What it is | Why it bites if wrong |
|---|---|---|
| Brand ID / Enseigne | Your 8-character account code | API rejects every call; nothing works |
| Private key | Signs API requests | Authentication failures on widget and labels |
| Weight coefficient | Converts PrestaShop weight to the unit Mondial Relay expects | Check which unit the field expects before you touch it: Mondial Relay's shipment API commonly wants grams, while PrestaShop catalogue weight is usually kilograms. In that case the conversion is 1000, not 0.001. Get the direction wrong and you invert every weight and trigger "invalid weight" rejections |
| Services offered | The relay, XL-relay, locker and home services your contract exposes (some integrations use codes such as 24R, 24L, 24X, HOM, but these vary by module and API generation) | Each enabled service becomes a PrestaShop carrier; only switch on the ones your module and contract actually expose and that you ship |
| Widget language | FR / EN / NL / ES | Cosmetic, but a French-only map on an English store reads as broken |
The weight coefficient is the single most common silent misconfiguration. The carrier looks fine in checkout, then orders fail at the label stage. Confirm the expected unit and conversion direction on day one.
Reviewing the carriers the module creates
During configuration the module auto-creates PrestaShop carriers for each enabled service. Don't leave them at defaults, open Shipping → Carriers and review each one:
- Zones. Enable a relay carrier only for countries Mondial Relay actually serves. Showing a French relay option to a German customer is pure checkout noise. The relevant network there is different. If you genuinely ship across several Mondial Relay countries on one contract, the multi-country zone logic is the same pattern we cover in GLS multi-country shipping integration.
- Weight ranges. Relay points technically accept up to 30 kg, but shelf space means a practical ceiling nearer 20 kg. Set the carrier's weight range so oversized orders don't offer a relay that the point will refuse.
- Price ranges. This is where you decide whether relay is free over a threshold or a flat fee. That's a pricing-strategy decision, not a Mondial Relay one. We work through the trade-offs in free vs flat-rate vs calculated shipping and when free shipping eats your margin.
If carriers and zones in general are new territory, start with the platform-level mechanics in setting up carrier modules in PrestaShop and the broader shipping configuration guide, this page assumes you know where the carrier screen lives.
The relay-point selection widget. The part that makes or breaks it
When a customer chooses a Mondial Relay carrier, the module injects a JavaScript widget that renders a map of nearby points centred on their delivery postcode. They filter by type (shop, locker, post office), opening hours or distance, then pick a point with one click. Crucially, that selection has to flow back into the checkout form as the relay point ID and persist onto the order. The whole integration succeeds or fails here, so it's worth knowing the failure modes before they reach a customer.
Widget does not appear
Almost always a JavaScript conflict. Open the browser console on the checkout page. The usual culprits: a jQuery version the widget doesn't support, a Content-Security-Policy header blocking the widget's external scripts, or a theme that loads scripts asynchronously so the widget initialises before its dependency. The fix is load order. The widget's dependencies must be present before it runs.
Map area is blank
The map tiles depend on a maps provider key. If the panel renders but stays empty, the configured key is missing, expired, or lacks the right API enabled (and Google's Maps JavaScript API now requires billing to be switched on even within its free usage allowance). Re-enter a valid key in the module configuration.
No relay points for a valid address
The API returns points within a radius of the supplied postcode. A malformed or non-existent postcode returns zero results, which to the customer looks like "you don't deliver here." Validate the postcode field on your address form so a typo fails fast instead of silently emptying the map.
Widget shows in the wrong place, or the selected point isn't saved
The widget needs the delivery address known before it can show points. The default stepped PrestaShop checkout handles this in order, but if you run a one-page checkout the carrier and address sit on screen together, and the hook timing can fire the widget before the address is settled, or the selected point ID never makes it into the submitted form. The fix is almost always hook timing, not template surgery: the widget hook has to run after the address is captured and write the point ID into the order. This is the most common collision we see between relay widgets and custom checkouts. If you're running a one-page flow, that interaction is exactly the kind of compatibility detail our checkout work at mypresta.rocks is built to keep stable across theme and PrestaShop upgrades, so a relay widget keeps writing its point ID after every update instead of silently dropping it.
Generating labels
Once an order lands with a relay carrier, you generate the shipping label. The module gives you two paths depending on volume:
- In-PrestaShop, per order. On the order detail page, a Mondial Relay tab generates a label directly via the API and returns a PDF. Fine for low daily volumes where you process orders as they come.
- Mondial Relay Connect, in batches. For higher volume, Connect (connect.mondialrelay.com) imports orders in bulk, generates labels in batches and schedules pickups. The module can export order data in a Connect-compatible format.
Label formats include A4 (one per page), A5 (two per page) and 10×15 cm thermal. If you run a thermal printer such as a Zebra GK420d, pick the 10×15 cm format so you're not cutting and wasting A4.
The tracking-URL gotcha
Mondial Relay issues a tracking/shipment number, and the module should save it to the order and move the status to "Shipped" when the label is created. The frequent defect is the tracking URL on the carrier itself. It's often not set correctly, so the customer's "track my parcel" link goes nowhere. Verify it by hand: Shipping → Carriers, edit the Mondial Relay carrier, and set the tracking URL to the Mondial Relay suivi-de-colis page using @ as the placeholder PrestaShop substitutes with the real number. A working tracking link is the cheapest way to cut "where is my order?" emails. The wider playbook for that is in tracking numbers and delivery notifications.
Relay vs home delivery: framing the choice for customers
The reason to offer relay isn't only your cost, it's that a meaningful share of French and Benelux shoppers actively prefer it, so presenting it well lifts the proportion who self-select the cheaper option. We won't quote a precise market-share figure here because the credible numbers move year to year and vary by country; treat relay as a genuinely mainstream choice in these markets rather than a fringe one, and measure your own relay-vs-home split once it's live.
| Dimension | Relay point | Home delivery |
|---|---|---|
| Carrier cost | Lower, consolidated drops | Higher, individual stops |
| Failed-delivery risk | None, customer collects | "Missed you" cards, re-delivery |
| Extra checkout data | Relay point ID required | Address only |
| Customer effort | Travels to collect | Receives at door |
| Best for | FR/Benelux shoppers who prefer pickup; cost-sensitive orders | Bulky items; customers who want doorstep delivery |
Present both, show the price difference plainly at the carrier step, and let the customer choose. The relay uptake takes care of itself when it's visibly cheaper. To nudge it harder: include the chosen relay point's name, address and opening hours in the order-confirmation email (people forget where they picked), and remember Mondial Relay holds a parcel for a limited window, so a reminder a few days before that deadline prevents returns-to-sender. If relay underpins how fast customers can realistically get their order, that ties into the wider question we cover in shipping strategy for small stores.
Returns through relay points
Relay points also take returns: the customer drops the parcel at any point and it's routed back to your warehouse, far cheaper than arranging a home pickup. The catch in PrestaShop: the module doesn't generate return labels natively. The practical workflow is to create the return label on the Connect platform when a customer requests an RMA, download the PDF, and attach it to the return-authorisation email so they print, stick and drop it at any relay point.
Quick troubleshooting reference
- "SOAP error" on label generation: the PHP SOAP extension is missing, or the API is momentarily down. Confirm the extension is loaded, then retry.
- "Invalid weight": grams-vs-kilograms mismatch, check which unit the field expects and the conversion direction. If PrestaShop weights are in kg and Mondial Relay wants grams, the coefficient is 1000.
- Carrier missing from checkout: check it's enabled, assigned to the right zones, and that the order weight falls inside the carrier's weight range.
- Relay point not saved to the order: the widget isn't passing the selected point ID into the checkout form, a JavaScript/hook-timing issue, not a data one.
- Label shows the wrong sender: the sender address comes from your Mondial Relay contract, not PrestaShop, fix it on the merchant portal.
Frequently asked questions
What do I need before I can configure the module?
A Mondial Relay professional contract, which issues your Brand ID (Enseigne), an 8-character code, and a private key used to sign API requests. You also need the PHP SOAP extension enabled (check with php -m), because the classic API is SOAP-based, plus HTTPS on the store so the relay widget isn't blocked as mixed content.
The weight coefficient keeps breaking my labels. What value is right?
Check which unit the field expects before changing it. Mondial Relay's shipment API commonly wants grams while PrestaShop catalogue weight is usually kilograms, so the conversion in that case is 1000, not 0.001. Get the direction wrong and every weight inverts, producing "invalid weight" rejections at the label stage even though checkout looked fine.
The relay widget doesn't appear on checkout. Where do I look?
Open the browser console first, it's almost always a JavaScript issue: an unsupported jQuery version, a Content-Security-Policy header blocking the widget's external scripts, or a theme loading scripts asynchronously so the widget runs before its dependency. The fix is load order, not template surgery. The dependencies must be present before the widget initialises.
The customer picked a point but the order has no relay saved. Why?
The selected relay point ID isn't making it from the widget into the submitted checkout form. On the default stepped checkout the address is captured before the carrier step, so it works; on a one-page checkout the hook can fire before the address settles. It's a hook-timing problem. The widget hook has to run after the address is captured and write the point ID onto the order.
What tracking URL should the Mondial Relay carrier use?
Set it by hand under Shipping → Carriers, editing the Mondial Relay carrier, pointing the tracking URL at the Mondial Relay suivi-de-colis page with @ as the placeholder PrestaShop substitutes for the real number. This is the field most often left wrong, which sends the customer's "track my parcel" link nowhere.
Where Mondial Relay fits in your carrier mix
For a France- or Benelux-focused store, relay-point delivery is one of the highest-impact shipping options you can add: it lowers per-parcel cost, removes failed deliveries, and matches how those customers actually want to collect. The setup is an afternoon's work, and the part that earns its keep is getting the point-selection widget and the relay point ID flowing cleanly through checkout. If you also serve customers who want a national doorstep carrier alongside relay, pair it with Colissimo for France, or with DHL, DPD and UPS for wider European reach. And if Poland is on your map, the equivalent must-have pickup network there is InPost Paczkomaty, same relay logic, different country, same checkout-widget care required.