Lockers and Pickup Points in Israel: Building Automatic Point Selection at Checkout

Pickup-point selection at checkout looks like a UI component, but it is mostly a data problem: where the point list comes from, how you confirm the chosen point is still active, and what the order must store so the shipment can actually be dispatched. In Israel every carrier runs its own separate network of points.

What a pickup point actually represents in your data model

A pickup point is an alternative delivery destination, so it deserves the same seriousness as an address. Five minimum fields:

• The point identifier at the carrier. This is the only field that is actually transmitted.
• The point name as shown to the customer, for the order screen and the confirmation email.
• The full address as displayed, so you can explain later what they saw.
• The carrier operating the point, because a point belongs to a network rather than to the world.
• The selection timestamp, so you know which state of the network the customer chose against.

Without an identifier, dispatch falls back to string matching - the same failure point that recurs in automating shipping labels in Israel, where a correct label depends on a single value that was never stored properly.

Where does the point list come from, and how fast does it go stale?

There is no single national registry of pickup points in Israel. Each network is run separately by its operator: E-Post is operated by HFD, the Cheetah Shops network by Cheetah, and Israel Post runs its own delivery-centre network, to which e-commerce parcels are distributed under its Click2post service.

That leaves three practical ways to get a list, each with a cost:

• Through the delivery platform or plugin. It shows the points of the carrier you are connected to. Least work, least control.
• From the carrier itself, after opening an account. You receive the list in whatever format the carrier provides. This is a commercial route before it is a technical one.
• A manual list you maintain. Workable only for a small, fixed network, and it goes stale invisibly. It is the worst option for a national network.

The deciding question is not how you obtain the list. It is how often it refreshes, and what happens to a record that has disappeared from it.

Physical limits that decide whether to show the option at all

The first row is the check most stores skip. Offering a locker for a parcel that physically does not fit produces a shipment that fails after the customer has already paid.

The four failure modes of a point-selection screen

• Search by city name only. A customer in a suburb will never find the point in the next town. Search has to work by proximity to an address, not by name.
• A list with no opening hours. The customer picks a point that is closed whenever they can get there, and complains to the store.
• Selection lost on the way back from payment. A customer who steps back in checkout loses the choice, re-picks, and sometimes does not pick at all.
• The same list for every shipping method. If the chosen carrier does not serve that point, it must not be displayed. Filtering by carrier is a precondition, not an enhancement.

The foundation for all of this is laid earlier, when building an online store and deciding which fields the order carries at all.

What do you do when a point closes between order and dispatch?

This is normal, not exceptional. The point was chosen on Monday, the shipment is dispatched on Wednesday, and the point is no longer on the list.

The flow that works:

1. Dispatch fails or returns an error, and the order moves to a "pending point selection" status.
2. The customer is contacted with a link to choose again, not a generic delay notice.
3. The new choice is stored as an additional event, preserving the history of both selections.
4. Dispatch is retried only after a new choice exists.

What you must not do is auto-select the nearest point. A customer who chose a point near work and gets a parcel near home has not been helped, they have been surprised.

Validating the point before the order is accepted

Most stores have no such check, which is why it is worth spelling out:

• The point exists in the current list for the chosen carrier.
• The point accepts this shipment type, including cash on delivery where relevant.
• The order's dimensions and weight fit the network's limits.
• A valid mobile number exists on the order.
• The point identifier is persisted with the order and not only in the browser session.

All five run before the order is accepted, not at dispatch time. The difference is practical: an order rejected before payment is a question to the customer, while an order rejected after payment is a support ticket and sometimes a refund. The cost of the check is the same either way; the cost of the failure is not.

What to have ready before building point selection

• A decision on which networks you genuinely support, and which carrier serves each.
• A source for the point list and an agreed refresh frequency.
• A clear policy for a customer who does not collect in time.
• Size and weight limits that hide the option when it is not applicable.
• A support screen showing which point was chosen, when, and the shipment's current status.

Sources

• e-post - automated lockers and pickup points
• Israel Post - e-commerce services for business customers
• Ship OS - supported courier companies