Will you place a real order?

No. By default the journey stops at the payment page; the confirmation step only runs when `payment_mode` is a test mode declared by the merchant **and** the caller asks for it. The test account is identifiable (`paniercheck+…`) so your teams recognise it.

Can I compare a small screen with a large one?

Not yet: the platform selector has no screen-size filter. The comparison cannot be enforced, only observed.

What about the 4G of the Boutique+ plan?

It is explicitly refused (`unsupported_network`) as long as no device exposes the `sim` capability to the platform. Advertising 4G while serving Wi-Fi would be a lie the merchant would spot on the first run.

Do runs already happen on a real device?

Not yet: platform detection, journeys, the funnel, alerts and the worker are built and tested offline, but the first real run on a Redmi and a demo store is still to be done.

Are my stores isolated per customer?

Not in phase 1: the `stores` table has no owner column, so the screen lists the stores of the instance. Attaching a store to a key is a schema change, still to be decided.

On real phones

Your mobile checkout journey, tested down to payment

Open, search, product page, cart, sign-in, delivery, payment, confirmation: PanierCheck replays the journey on real Android devices and tells you which step breaks, on which device and which network.

Start for free See pricing Discuss your project

No credit card to start. Secure payment through Stripe when you change plan.

Each bar is the share of runs that reach the step. The red step is the loss: 27 points evaporate between delivery and payment. Dashed is a conditional step. The first real run is still to be measured.

Step 7 of 8: this is where it breaks.

Step by step

The funnel, measured rather than guessed

Success rate and duration over 24 h, 7 d and 30 d for every step. You see which one drops, since when, and on which device — not merely that something is wrong.

1 openthe home page renders, cookie banner dismissed 100 % 1.8 s
2 searchthe results show at least one product 100 % 2.4 s
3 product pagea price and an add-to-cart button are present 99 % 2.1 s
4 cartthe cart holds at least one item 96 % 2.6 s
5 sign-inthe test account is signed in, or guest checkout offered 92 % 6.3 s
6 deliveryaddress and shipping accepted, total displayed 88 % 5.1 s
7 payment“Pay” button not found (assert pay_now) — screenshot, video and console errors attached 61 % —
8 confirmationthe test order is confirmed by an order number (test mode required) — —

Bars are the share of runs that reach the step. Conditional steps (guest checkout, confirmation in test mode) are counted separately, never as a failure. Sample report: no real run has been measured yet.

What it does

Concretely

Four platforms recognised

Shopify, PrestaShop, WooCommerce, Magento: the platform is recognised from the URL, the headers and the HTML, and a pre-filled journey with the known selectors is proposed. The selectors stay editable.

The funnel, step by step

Success rate and duration over 24 h, 7 d and 30 d, for every step of the funnel. You see at once which step drops, and since when.

Where it breaks, exactly

The step, the device, the network, the screenshot, the video and the captured console or network error. A merchant understands the report without a developer.

Regressions detected

Every run is compared with the previous one: a step that drops triggers an alert, through the kit channels (email, Slack, signed webhook). One alert for a broken funnel, one for an unavailable payment.

The weekly report, white-labelled

Published behind a secret link (`GET /report/:token`), with the agency name and colour: the merchant receives a report under their own brand, with no API key to handle.

Never a real payment

The journey stops at the payment page. The confirmation step only runs when the merchant has declared a test mode (Stripe/PayPal or a test card) and the caller explicitly asks for it.

The evidence

What you get when a step breaks

The step, the device, the network, the screenshot, the video, and the console or network error exactly as it came out. A merchant understands the report without a developer.

ShopifyPrestaShopWooCommerceMagento

The run stops at the payment page: no real payment is made, and the confirmation step only runs when the merchant has declared a test mode.

Failedrun 4 812

Step7 / 8 — payment page displayed

DeviceRedmi 12 · MIUI 14 · Wi-Fi

Selectorassert pay_now → not found

ConsoleUncaught TypeError: Cannot read properties of null

Evidencecapture.png · video.mp4 (12 s) · logcat.txt

VerdictBroken funnel — step 7, 1 device out of 2

In all honesty

What we do not do

A product that hides its limits wastes everybody's time. Here are ours, today.

No real run on a real device has been measured yet: detection, journeys, the funnel, alerts and the worker are built and tested, but the first run on a Redmi and a demo store is still to be done.
4G is explicitly refused (`unsupported_network`) as long as no device exposes the `sim` capability: the plan advertising it is not sellable today.
No screen-size filter on the platform side: the "small screen vs large screen" comparison cannot be enforced, only observed.
Never a real payment: the journey stops at the payment page, unless a merchant-declared test mode is explicitly requested.
Purging Chrome data without uninstalling APKs (the `device` job) does not exist yet: PanierCheck uses `reset: after` in the meantime, which uninstalls third-party packages.
The multi-screen setup wizard and the agency space are not built: white-labelling is limited to the report name and colour.
The `stores` table has no owner column: the screen lists the stores of the instance (single-tenant in phase 1).
Stripe is not wired up: the billing page says so and the payment route answers 503.

Try it on a real phone

Create an account, take a key, run your first test. It is free to start.

Create an account Compare plans Discuss your project