Shopify TroubleshootingClient under NDA

Paid Booking Flow Restored on Shopify

An appointment app that reserved slots but never reached checkout, traced to one unwired booking button

By Lotfi Otmanine

Client
Aesthetics clinic, Shopify store (anonymized)
Engagement
Fixed-scope diagnosis and fix on a live store, delivered
Stack
ShopifySesamiShopify Ajax Cart APIJavaScriptHTML / CSSChrome DevToolsPlaywrightPython

Key result

13/13

paid-flow tests passed

01

Context

A Shopify store selling a paid consultation through Sesami, a Shopify appointment-booking app. Two symptoms were reported. With the app's Instant Booking setting on, appointments were booked without any payment. With it off, the calendar opened and a time could be chosen, then nothing happened: no cart, no checkout. The brief asked for the standard paid flow with Instant Booking off, with no workaround around checkout, no payment setting change and no new paid app.

The work ran on the live production store, read-only first, with console and network evidence for every step and every change approved before it was made and logged with its before value and its rollback. The first round of evidence pointed to a configuration cause and a working flow, yet the client kept seeing the stop. The real cause only appeared once testing moved from the product page to the page customers actually booked from.

02

The Challenge

  • Instant Booking skipping payment looked like a defect but is documented app behavior, so the real question was why the paid path failed without it.
  • On the product page the reported stop did not reproduce in desktop Chrome, Edge, Android Chrome or iPhone Safari, while the client still saw it.
  • Every candidate fix sat outside the theme: app settings, product settings and page content apply to the live store on save, so a theme duplicate offered no safe copy to test in.
  • Repeated automated page loads drew HTTP 429 rate limiting from Shopify on the test connection, so browser runs had to be paced.

03

Scope and Approach

Research and read-only audit

Sesami's help center and developer docs read before login, turned into a stage-by-stage map from slot selection to paid order: events, hidden fields, cart requests, checkout. Then a read-only review of orders, abandoned checkouts, product, app settings and theme blocks. It found Instant Booking on with order creation, which explained the unpaid booking orders.

Paid flow verified on the product page

Instant Booking switched off in an approved window and the flow traced in the console and network tab: reservation, automatic add to cart, redirect to checkout. A discount code agreed with the client allowed a real order without a charge, after checkout had shown the full price and a required payment step. Abandoned checkouts left only an expiring hold. Instant Booking was then left off.

Finding the page customers used

The client still saw the stop, on iPhone and on Edge. Fresh runs in Edge and iPhone Safari passed on the product page, and that was reported as not reproduced rather than explained away. It then emerged that customers booked from a separate landing page with its own booking button. On that page, with Instant Booking off, the reported stop reproduced.

Fix proven, applied and retested

The fix was proven in the test browser first, with nothing changed on the store, then applied to the page content after approval, with a full backup of the page and a checksum. A dead legacy script reference that returned 404 was removed, and a pre-existing mobile sideways scroll on the same page was fixed separately. The live page was retested to checkout in Chrome, Edge and Android Chrome.

04

Architecture flow

Landing page
booking button
Slot chosen
reservation held
Cart form found?
needs a submit button
yes
Add to cart
date, time, token
no
Flow stops
reservation only
Shopify checkout
payment required
Paid order
line item properties
Booking confirmed
assigned resource

05

Technical Deep Dive

A button that reserves but never sells

On the landing page the booking button was a hand-placed app tag in the page content, carrying only styling options: no variant, no auto add to cart, no skip cart, and no product form on the page. After Confirm the reservation succeeded, the booking fields filled hidden inputs that belonged to no form, and no cart request followed. Sesami documents such a snippet as self-contained only for Instant Booking: the page only seemed to work while payment was being skipped.

Why the obvious fix was not enough

Adding the three missing options in the test browser made the app fire its add-to-cart event, then log that form data was not found. Reading the app's storefront script showed why: it looks for a form posting to the cart, near the button or anywhere on the page, and accepts it only if it contains a submit button. A hidden form without one is ignored. A hidden cart form with a hidden submit button, plus the three options, reached checkout.

Keeping side findings separate

A booking whose hold had expired stayed in the cart without locking checkout, so a returning visitor could reach checkout with two sessions, one for a slot no longer held. It was recorded as app behavior and left unchanged, not folded into the root cause. The 429 responses were logged as a test artifact on the test connection, not a store fault.

06

Engineering Decisions

Not reproduced is a finding, not a fix

When the client still saw the stop after the first round, the passing Edge and iPhone Safari results were reported as not reproduced, with the questions needed to close the gap, before any further change. Nothing on the store was altered on the strength of a guess.

Prove in the browser before touching the store

The landing page fix was first injected only into the test browser, against the live page. Only once that run reached checkout was the change proposed for approval, then pasted live with a full page backup and a one-line rollback, because page content has no theme duplicate to protect it.

Use the app's own integration

The fix stays inside Sesami's documented integration: a cart form the app can find, plus its own add-to-cart and skip-cart options. No custom checkout bypass, no theme edit, no payment setting change, no new app, and Instant Booking stays off.

07

Results

  • Root cause found and fixed live: the landing page booking button now adds the booking to the cart and opens checkout with its date and time, with payment required.
  • Live landing page retested to checkout after the fix in desktop Chrome, Edge, Android Chrome and iPhone Safari, and the fix accepted by the client.
  • 13 of 13 paid-flow tests passed on the product page with Instant Booking off: payment required, order and booking created with an assigned resource, abandoned and cancelled checkouts releasing the slot.
  • Instant Booking left off for good, closing the path that booked appointments without payment.
  • Change confined to page content, with a full backup and rollback; a dead legacy script removed and a pre-existing mobile sideways scroll fixed on the same page.

Have a site that needs this kind of care?

Tell me what is breaking or what you need built. I will reply with how I would approach it and what I would check first.

Custom quote within 24 hours

Chat on WhatsApp