Skip to content

Post-purchase actions inside the sheet (Sign out, Track order) navigate the checkout WebView to an unauthenticated storefront page, with no way for the host app to intercept #516

Description

@sreehariv-code

What area is the issue related to?

Checkout Sheet Kit

What platform does the issue affect?

All platforms

What version of @shopify/checkout-sheet-kit are you using?

3.8.3

Do you have reproducible example code?

Checkout URL comes from the Storefront API cart (cart.checkoutUrl), and the sheet is presented with the standard API:

import {ShopifyCheckoutSheet} from '@shopify/checkout-sheet-kit';

const shopifyCheckout = new ShopifyCheckoutSheet({});

// checkoutUrl = cart.checkoutUrl from the Storefront API cart mutations
shopifyCheckout.present(checkoutUrl);

// The only lifecycle signals we receive are these — neither of them fires
// when the shopper taps "Sign out" or "Track order" inside the sheet:
shopifyCheckout.addEventListener('completed', event => {/* order finished */});
shopifyCheckout.addEventListener('close', () => {/* sheet dismissed */});

Nothing custom is done to the sheet — no configuration beyond defaults, no attempt to modify its WebView.

Steps to Reproduce

  1. Present the checkout sheet with a Storefront API cart.checkoutUrl.
  2. Complete an order (Bogus Gateway is fine) so the Thank You page renders inside the sheet.
  3. On the Thank You page, tap Track order (it targets /account#orders).
  4. Observe where the shopper ends up — the navigation happens inside the sheet's own WebView.
  5. Repeat for the second case: while the checkout sheet is open, tap Sign out.

Expected Behavior

Either of the following would be correct, and we would be happy with the second:

  1. These destinations should be reachable in a usable state — i.e. the shopper who taps "Track order" sees their order, rather than an unauthenticated storefront page.

  2. Failing that, the SDK should hand the navigation back to the host app so it can complete the action properly. Concretely: an opt-in configuration flag that stops the sheet navigating away from the checkout/Thank-You-Page origin, plus an event carrying the target URL and (ideally) a semantic hint for the action, e.g.

const shopifyCheckout = new ShopifyCheckoutSheet({
  interceptExternalNavigation: true, // opt-in; default behaviour unchanged
});

shopifyCheckout.addEventListener('navigationRequest', event => {
  // event.url    -> 'https://<shop>/account#orders'
  // event.source -> 'checkout' | 'thank_you_page'
  // event.action -> 'sign_out' | 'track_order' | ...
  shopifyCheckout.dismiss();
  openInAppWebView(withMultipassToken(event.url)); // shopper stays signed in, stays in the app
});

Please make this declarative (a config flag) rather than a return false-style preventDefault — the RN bridge is asynchronous, so a synchronous veto cannot be honoured race-free.

A narrower version would also unblock us: a dedicated Thank-You-Page action event, or a configuration option to hide the Sign out / Track order affordances so host apps can surface their own.

Actual Behavior

Both actions navigate the sheet's own WebView to the storefront, where there is no customer session:

  • Track order (/account#orders) → the shopper lands on the storefront home with a login sheet, inside the still-open checkout sheet. They never reach their order.
  • Sign out → same outcome: storefront home + login sheet, inside the checkout sheet.

The shopper is left in a dead end — inside a checkout sheet, on an unauthenticated storefront page, with no route back into the app other than closing the sheet.

The host app cannot fix this, because there is no supported seam:

  • No navigation or URL event is emitted, so the link tap is invisible to JS.
  • No JS injection into the sheet's WebView, so the links cannot be rewritten.
  • The sheet is a native dialog/controller, so React Native's own navigation and back handling never see the interaction.
  • The only signals available are the completed lifecycle event and the checkout_completed Web Pixel — both report that the order finished, not that the shopper subsequently tapped something.

Note: we are aware onURLChange was requested in #171 and closed as not planned. This is deliberately not a request for a general URL-change firehose — only for the moment the sheet is about to leave the checkout/TYP origin, which is precisely where it currently hands the shopper an experience it cannot complete.

Storefront domain

Reproducible on any Checkout Extensibility store (confirmed with Bogus Gateway in test mode) — the Sign out and Track order affordances are standard checkout/Thank-You-Page UI, not store-specific customisations.

Screenshots/Videos/Log output

No response

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions