Click-through journeys
A starting page and steps — click, fill in —, replayed in a real browser up to the payment page, without ever paying.
Updated on 5 October 2026
On this page
Available on the Pro and Pro Plus plans.
A classic payment journey requests addresses in order. But a real funnel isn't walked by typing addresses: you pick a colour, click “Add to cart”, open the cart, click “Checkout”. A click-through journey does exactly that, in a real browser, and tells you which step stopped working.
What PostShip does
The steps
A click-through journey is a starting page on your site and 1 to 8 steps, in order:
- Click a button or a link, named by the text it shows — “Add to cart”, “Checkout”, “Black”. It's what a visitor sees, and it survives an HTML redesign. If the text isn't enough (a button with no text, an icon), give a CSS selector as a fallback:
#add,button.cart. - Fill in a field, named by its label, its placeholder or its
nameattribute — “Email”, “Postcode” —, with the value to type. Drop-down lists take the option with that text; checkboxes get ticked.
PostShip opens the starting page in Chromium, performs the steps one after the other like a visitor, and records each page they lead to: what it shows, whether it crashes, whether a script or stylesheet of your site answers with an error.
Stopping at the payment page
As soon as a payment page shows up, the journey stops there, without doing anything on it: Stripe Checkout, PayPal, the Shopify checkout, Lemon Squeezy, Paddle, Mollie, or any page with a card field (Stripe Elements, Adyen, Braintree, Square…). PostShip never pays. Steps planned after that page aren't replayed; the screen marks them “After payment, not replayed”.
By default, the journey must end on a payment page: if it finishes its steps without seeing one, it breaks at the last step. Untick it if your journey ends elsewhere (a “thank you” page, a quote form).
What PostShip never fills in
No card, security code, expiry or IBAN field, and no password. The refusal happens twice: when saving, on the label and the value (a run of 12 to 19 digits looks like a card number and isn't accepted), then in the browser, on the element found (type="password", autocomplete="cc-…"). PostShip logs into nothing and keeps no secret.
What it leaves on your side
A click-through journey that goes as far as Stripe Checkout or the Shopify checkout opens a payment session, like a customer who hesitates: it's never paid and expires on its own. No order, no payment. But it shows: in Stripe, among incomplete sessions; in Shopify, among abandoned checkouts — and if a step filled in an email address, the shop may send its cart reminder there. So fill in an address of your own, or one that receives nothing (test@example.com), never a customer's.
When it runs
Every 10 minutes outside deploys, and on every production deploy (T+0, T+2, T+8). The browser is shared and serves one page at a time: an 8-step journey keeps it busy for half a minute. When it's busy, the run is postponed, never counted as a failure. Previews don't replay the steps.
The starting page first goes through the usual HTTP check, with the price text if you give one. If it already breaks there, the steps aren't replayed.
Set up
Project → Monitoring → Journeys → “New journey” → “Clicks”:
- The starting page and the steps: the starting address, on the project's domain, then the steps. “Add a step” adds one; “Add a CSS selector” opens a step's fallback.
- Where the journey must end: the “The journey must end on a payment page” box (ticked by default) and, optionally, the price text on the starting page.
- “Monitor this journey”.
An example for a shop: start https://shop.com/product/lamp, then Click “Black”, Click “Add to cart”, Click “View cart”, Click “Checkout”.
What triggers an alert
The journey breaks at the first step that doesn't pass. The sentence says which one and where:
| Situation | Sentence |
|---|---|
| The button no longer exists | The “Add to cart” button can't be found on /product/lamp. |
| The button stays greyed out | The “Checkout” button is disabled on /cart. |
| The button doesn't react | The “Checkout” button doesn't respond to the click on /cart. |
| The field is gone | The “Email” field can't be found on /cart. |
| The next page errors | After “Checkout”, the page answers 500. |
| No payment page | The journey ends without reaching a payment page. |
A page that renders blank, crashes (“Application error”) or where a script of your site no longer loads also breaks the step, as in an address journey. The following steps are “not requested”, never green. The alert goes out on your channels like a payment page's, and a failing journey costs 40 points of the Ship Score.
If your host's firewall puts a bot challenge in front of the browser, the run isn't a failure: see Allow PostShip in your firewall.
Limits and plans
A click-through journey counts as a payment journey: 2 per project with Pro, 10 with Pro Plus. It isn't available on Discover, whose journey stays an address journey.
Troubleshooting
The button is there, but PostShip can't find it
The text must be the one the page shows at the moment of the step. A button that only appears on hover, or in a closed menu, first needs a click on whatever opens it. A button without text (an icon) is named with a CSS selector.
A cookie banner covers the button
PostShip clicks the element itself when a banner covers it: the journey passes. If your banner blocks the whole page until it's closed, add a first step Click “Reject all”.