What should a Scan-Pay-Go receipt show?

It should clearly confirm that payment completed, identify the relevant basket or transaction, show the time and store context, and provide whatever code staff need for the retailer's configured validation process.

Should every Scan-Pay-Go customer be checked at the exit?

There is no universal rule. The retailer should choose a lawful and proportionate policy, explain it before the exit, train staff to apply it consistently and provide a calm path for ordinary mistakes and technical failures.

How should staff handle a missed item during validation?

Treat it first as an exception to resolve. Explain what was found, let the shopper confirm or correct the basket, complete any required payment and escalate only when the facts and store policy justify it.

What happens if mobile payment fails?

The customer should receive a clear failure state and a supported fallback, such as restoring the cart for cashier or compatible checkout completion. Staff should be able to distinguish an unpaid cart from a completed transaction.

How can retailers test Scan-Pay-Go before launch?

Run small, large and exception-heavy baskets through scanning, payment, receipt proof, staff validation and recovery. Include removed items, duplicate scans, restricted products, price changes, weak connectivity and payment failure.

Does Scan-Pay-Go prevent retail loss?

No checkout method eliminates loss. Good validation, product data, staff training and exception handling can improve control, but outcomes depend on the retailer's design, configuration and operation.

How does EzyCarto support Scan-Pay-Go validation?

EzyCarto's public product scope includes shopper-built carts, retailer-configured validation and approval, supported in-app payment, staff checks, QR cashier handoff and compatible checkout handoff. Availability depends on retailer configuration, region, plan and supported payment paths.

Scan-Pay-Go Exit Validation: A Practical Retail Test

Scan-Pay-Go should remove checkout friction, not move it to the store exit. Use this practical test for payment proof, receipt checks, staff intervention and exception recovery before rollout.

A checkout designed to remove a queue can create a different kind of friction at the door.

The shopper has scanned the basket, followed the app, paid and reached the exit. Then a staff member is unsure which screen proves payment, what should be checked or what to do when the item count looks wrong.

Convenience can turn into suspicion in seconds.

One Scan & Go customer described being stopped after payment, asked to count a large basket and subjected to a full receipt check while staff appeared uncertain about the process. The customer's conclusion was blunt: using the feature made them feel "treated like a shoplifter."

That experience is not an argument against mobile self-checkout. It is an argument for designing the exit as carefully as the scan and payment journey.

The right question before launch is not only, "Can the app take payment?"

It is:

"Can a genuine customer complete the journey, prove payment and recover from an ordinary exception without confusion or humiliation?"

The transaction does not end at the payment screen

Retailers often map the digital path in detail:

1. Find the store.

2. Scan products.

3. Build the cart.

4. Apply the available payment or checkout path.

5. Confirm payment.

The physical store journey continues after step five.

The shopper still needs to know:

which exit or lane to use
whether a receipt check is normal
what screen, barcode or receipt proves payment
whether shopping bags can be packed before or after validation
what happens when staff cannot verify the transaction
where to go if the app, payment or product record fails

Staff need the same clarity from the other side. If that operational layer is missing, every exception becomes an improvised judgment in public.

Separate four different problems

Not every incomplete or uncertain basket means the same thing. A fair validation process separates at least four situations.

1. Accidental missed scans

A shopper may overlook a product, scan the wrong barcode, select the wrong loose item or believe a scan succeeded when it did not.

University of Leicester's June 2026 summary of a study involving 39 retailers reports that self-checkout loss has several causes, including honest mistakes, awkward items, unfamiliar interfaces and difficult barcodes. It reports missed scans in 1% to 4.8% of transactions across the participating data, with an average reported cost of EUR2.50 per incident.

Source:

https://le.ac.uk/news/2026/june/retail-loss-self-checkout

This research covers self-checkout broadly, not every Scan-Pay-Go implementation. Its practical lesson still matters: an apparent mismatch can be a process or usability failure, not proof of intent.

2. Payment uncertainty

A cart may exist while payment is pending, declined, abandoned or completed through a different handoff.

The system and the staff process should make these states visibly different. "We cannot confirm this payment yet" is a factual status. It should not become "this customer has not paid" until the evidence supports that conclusion.

3. Deliberate loss

Retailers need proportionate controls for intentional non-scanning, substitution and walkaways. Those controls should be designed, documented and reviewed. They should not depend on a staff member inventing a policy at the exit.

4. Staff communication failure

Even accurate technology can produce a bad experience when staff do not know:

which lane supports Scan-Pay-Go
how to validate a receipt
how many items to check
when to request a full review
who can approve an exception
how to explain the process without making an accusation

Training is part of the checkout design.

Write an exit contract

An exit contract is a simple operating agreement between the retailer, the shopper and the staff member.

It answers four questions before anyone reaches the door.

What confirms completion?

Define the exact proof of a completed transaction. It might include a digital receipt, transaction reference, time, store, basket details or a validation code, depending on the retailer's supported configuration.

The shopper should not need to guess which screen matters. Staff should not need to interpret a collection of app screens under pressure.

What may staff inspect?

State whether checks are universal, random, risk-based or triggered by an exception. Define what the staff member compares and what the customer is asked to do.

The policy should be lawful, proportionate and consistently applied. A customer should not discover the rules only after payment.

What does the customer see?

Use plain instructions at each transition:

Payment complete.
Keep this receipt open for the exit check.
Please use the Scan-Pay-Go lane.
A staff member needs to confirm part of this basket.
Payment was not completed. Your cart can be restored at the cashier.

Clear status language reduces argument because it tells both people what is happening.

What happens when validation fails?

Define the next safe action. Do not leave a customer standing at an exit while several staff members debate the process.

A failed check might require:

rescanning one product
paying for an omitted item
checking a product substitution
restoring the cart at a cashier
confirming a delayed payment status
manager approval for a genuine discrepancy

The recovery path should preserve evidence and dignity.

Test the awkward baskets, not only the perfect one

A clean demonstration cart proves very little. Real stores contain exceptions.

Before rollout, test at least three basket types.

Small basket

Use two or three ordinary products. Confirm that scanning, payment, receipt proof and exit validation are obvious without staff coaching.

Large basket

Use enough products to make visual checking difficult. Include similar packaging, more than one quantity of the same item and reusable bags. Confirm that staff can validate without asking the shopper to reconstruct the entire purchase in public.

Exception-heavy basket

Include controlled examples such as:

an item removed after scanning
the same barcode scanned twice
a price change during the visit
a product with an unreadable barcode
an age-restricted item
a weighted or lookup item where supported
weak connectivity
a declined or interrupted payment
a cart handed to a cashier or compatible checkout

For each case, record what the shopper sees, what staff see, who can resolve it and whether the transaction history explains the outcome.

Give staff a script, not just a rule

"Check suspicious baskets" is not an operating procedure.

A useful staff script begins with facts and a next step:

"This basket needs a quick validation before you leave. I will compare the receipt with these items. If something was missed or the payment status has not updated, we can correct it here."

The wording matters. It describes a process without assigning motive.

Staff also need an escalation boundary. A frontline employee should know when they can correct a simple exception, when a manager is needed and when the retailer's security policy applies.

Review the resulting exception records for patterns:

one barcode repeatedly fails
one product is regularly selected incorrectly
payment confirmation is slow at a particular location
customers misunderstand the same screen
staff apply the check differently by shift

This turns validation into operational learning instead of repeated confrontation.

Measure the exit, not only adoption

App downloads and Scan-Pay-Go starts are incomplete measures.

Track the full journey:

carts started
carts reaching payment
payments completed
customers requiring staff help
validation checks completed
corrections made without escalation
carts handed to cashier or compatible checkout
abandoned journeys
time spent resolving exceptions
complaints or feedback linked to the exit process

A high intervention rate is not automatically proof of attempted loss. It may reveal weak product data, confusing status messages, poor connectivity or inconsistent staff practice.

The purpose of measurement is to improve the process, not to find a more technical way to distrust customers.

Where EzyCarto fits

EzyCarto's current Scan-Pay-Go experience allows shoppers at participating retailers to scan supported products and build a live cart. The checkout path depends on the retailer's configuration and may include supported in-app payment, QR cashier handoff or compatible self-checkout handoff.

The public product scope also includes retailer-configured validation and approval, receipt checking and staff checks.

Scan-Pay-Go product page:

https://ezycarto.com/scan-pay-go

EzyCarto POS can support staff-built carts, barcode scanning, compatible QR cart restoration, receipts and connected sales records.

EzyCarto POS product page:

https://ezycarto.com/solutions/ezycarto-pos

Those capabilities provide building blocks. They do not guarantee lower loss or a good customer experience by themselves. The retailer still needs to choose the policy, configure the supported journey, train staff and test exceptions in the real store.

Run the exit test before rollout

Take one real product set and map it from first scan to final exit.

Confirm:

[ ] the shopper knows which products and barcodes are supported
[ ] removed and duplicate items produce an understandable cart
[ ] the enabled payment or handoff path is clear
[ ] completed and incomplete payment states look different
[ ] the receipt or validation proof is obvious
[ ] staff know which lane and screen to use
[ ] checks have a defined scope and consistent script
[ ] an ordinary mistake has a calm correction path
[ ] failed mobile checkout can move to a supported cashier or compatible terminal
[ ] restricted items and approvals have an owner
[ ] exceptions create a useful record for later review
[ ] customers can give feedback after a difficult journey

Then test the same path with a large basket and an exception-heavy basket.

Related guides:

https://ezycarto.com/blog/retail-technology-needs-operator-proof-before-rollout

https://ezycarto.com/solutions/ezycarto-checkout

The aim is not to remove every check.

It is to make each check understandable, proportionate and recoverable.

That is the real Scan-Pay-Go exit test.

The Scan-Pay-Go Exit Test: Validation Without Turning Convenience Into Suspicion

Key takeaways