PrestaShop pickup point not showing: the real causes

A bug that costs you orders directly

When a PrestaShop pickup point fails to appear, the customer does not ring you: they abandon the basket. It is one of the most expensive bugs in the checkout, and one of the most common. Across the call-out history of a specialist French agency, delivery modules account for several hundred tickets, dominated by Colissimo and Mondial Relay, with spikes that track version upgrades.

The good news: the causes come down to a small number of scenarios, and an isolation method will settle it in fifteen minutes.

Step 1: the map is blank or never loads

The selection widget appears but stays white, or spins forever. Open the browser console, Console tab then Network: the error is nearly always explicit.

Expired Google Maps key or quota exceeded. Typical message: RefererNotAllowedMapError or OverQuotaMapError. The key has to be valid, attached to a project with billing enabled, and allow the store's domain as a referer. This is by far the most common cause.

JavaScript conflict with the theme. Test by switching temporarily to the Classic theme. If the map comes back, the problem is a library loaded twice by your theme, typically jQuery.

CCC breaks the loading. Under Advanced Parameters > Performance, the "Combine, Compress and Cache" options bundle JavaScript files together. Carrier widgets often load their scripts asynchronously and cope badly with that bundling. Turn CCC off, clear the cache, test again. If the map comes back, you know where to look.

Mixed content. A widget called over HTTP on an HTTPS page is blocked silently by the browser. Message: Mixed Content.

Step 2: the carrier does not appear in the checkout at all

Here the problem is not the widget but the logic that decides which carriers are available. Check in this order:

1. Zone and country. The customer's delivery country has to belong to a zone linked to the carrier. An unticked zone makes the carrier invisible without a single message.
2. Customer groups. In the carrier's tab, the permitted groups must include the customer's own, "Visitor" included if you accept guest checkout.
3. Weight and price ranges. The classic one: the last range stops below the actual basket. A 12 kg basket on a grid that stops at 10 kg makes the carrier disappear. Check the out-of-range behaviour you have selected as well.
4. Soft-deleted carrier. In the database, ps_carrier.deleted = 1 hides the carrier. This happens after a carrier is edited, since PrestaShop creates a new row and archives the old one.
5. Product availability. A product configured with specific carriers restricts the choice for the whole basket.

A useful query to see clearly:

SELECT id_carrier, name, active, deleted, id_reference
FROM ps_carrier ORDER BY id_reference, id_carrier;

Step 3: the label will not generate

The customer has picked their collection point, but the shipment fails in the back office.

• Expired credentials or contract. Carrier modules store a username, a password and often a contract number. A change of commercial contract invalidates the credentials with no warning.
• Address rejected. Carrier address formats are strict. Colissimo truncates beyond a certain line length, and accented or special characters in address1 trigger rejections. Addresses pasted in from another site are the worst offenders.
• Zero weight. A product with no weight set breaks the calculation at some carriers. Check that no active product has a weight of zero.

Step 4: the shipping costs make no sense

Two causes dominate:

• Overlapping ranges. A grid of 0-1 kg then 1-5 kg creates an ambiguity at exactly 1 kg. Use bounds that do not overlap.
• Free shipping threshold set wrongly. The free delivery threshold is set in the shipping preferences, and applies before or after discount depending on your configuration. A badly placed threshold gives away free delivery more often than you intended.

The fifteen-minute isolation method

One rule only: change one setting at a time. In order: Classic theme, then CCC off, then non-essential modules disabled. The first change that restores normal behaviour names the culprit.

Document every test. On a checkout, going back without knowing what you changed costs more than the original bug.

If the fault appeared after a version upgrade, the cause is probably broader: see our article on modules broken by an update.

Checkout broken?

We handle carrier and checkout bugs as emergency work. Free diagnosis, reply within 1 hour — see PrestaShop emergency support.