Thank You Page — Setup Plan — Sessions Cannabis

1What’s already built

A single branded order-confirmation (“thank you”) page that works for every store — nothing to build per store, no separate URL to hand back and forth.

Live now at demo.sessions.ca/order-completed — becomes sessions.ca/order-completed at launch.
Shows the order number and a live status timeline — Order received → Preparing → Ready for pickup.
Reads the order number and status from the link the customer arrives back on. One shared page, full Sessions branding.

Open the live page →

2The current checkout process, end-to-end

This is exactly what happens when a customer buys on the new site. It matters because it explains the one thing we can’t control.

STEP 1

Browse & add to cart

On our site. Catalog + prices come from the Dutchie API.

Our code

STEP 2

Build the Dutchie cart

Our worker calls the Dutchie API: CreateCheckout → AddItem, which returns a redirect URL into Dutchie’s checkout.

Our code + Dutchie API

STEP 3

Pay & place order

The customer is now on Dutchie’s hosted checkout page, on Dutchie’s domain. They pay and place the order here.

Dutchie’s page

STEP 4

Return to thank-you page

Dutchie’s checkout redirects the customer to the URL we put on the checkout link via ?r= (Dutchie-confirmed Jul 7). We choose the destination.

We set it (?r=)

STEP 5

Branded confirmation

Customer lands back on our /order-completed page with the order details.

Our code

The order completes on Dutchie’s page, on Dutchie’s domain — Dutchie’s checkout fires the redirect, not our code. But we control where it goes: Dutchie confirmed (Jul 7) we can append ?r=https://sessions.ca/order-completed to the checkout URL and their checkout will honour it. So the redirect is self-serve from our end — no Dutchie ticket required for it.

3The honest part: what we can and cannot control

No sugar-coating — here’s the exact split. The page is fully ours. The trigger that returns the customer to it is Dutchie’s.

✓ We fully control (via our code / the API)

The entire thank-you page — design, branding, copy, one shared page for all stores.
Reading the order number & status from the return link and showing them.
Optionally pulling the live order status via the Dutchie API by order ID, so the page updates dynamically.
Where the customer is sent after payment — we append ?r=<our-page> to the checkout URL and Dutchie honours it. Confirmed by Dutchie, Jul 7.
The cart, catalog and pricing up to the checkout hand-off.

✕ We cannot control (it’s Dutchie’s)

The checkout/payment page itself — it runs on Dutchie’s domain.
The moment the redirect fires — Dutchie’s checkout fires it, not our code (we only hand it the destination).
Editing the Admin “Default Return URL” field — superuser-only, so Dutchie sets that one on request.

Correction (Jul 7, from Dutchie): we can control the destination from our end — by adding a ?r= return parameter to the checkout URL. The order still completes on Dutchie’s page; we just hand that page the URL to bounce back to. The earlier “only Dutchie can set it” applies only to the Admin default field, not the per-checkout redirect.

4Old site (Mike) vs new site (us)

Important: Mike did not avoid this via API either. On the old site he emailed Dutchie a thank-you URL per store — the same mechanism. Only the top and bottom rows changed; the checkout and the redirect are identical.

Step	Old — Mike (WordPress + WP CannaSync)	New — us (Dutchie API cart + hosted checkout)	Same?
Catalog / menu	WP CannaSync pulls the Dutchie catalog into WordPress	We pull it via the Dutchie API / our worker	changed
Cart	WordPress / CannaSync cart	Our cart → `CreateCheckout` + `AddItem`	changed
Checkout & payment	Dutchie hosted checkout	Dutchie hosted checkout	same
Who places the order	Dutchie, on Dutchie’s page	Dutchie, on Dutchie’s page	same
Return redirect	Dutchie redirects to the per-store URL Mike emailed them	We set it ourselves via the `?r=` param on the checkout URL (or a one-time Admin default)	improved
Thank-you page	WP CannaSync page, one per store	Our branded page, one shared for all stores + optional live status via API	improved

5Owning the whole checkout (context only — not needed here)

The redirect is now solved (section 6). This section is only about the bigger question of owning the entire checkout — taking payment and placing the order ourselves in a fully custom (headless) checkout so the customer never leaves our site. We do not need this for the thank-you page.

That is a much bigger build: our own payment processing, ID / age verification at checkout, and the compliance and order-submission liability that Dutchie currently carries. And it points the wrong way — multiple industry sources report Dutchie is sunsetting its Plus headless API in 2026 (roughly a 6-month deprecation runway). Building more on headless is the wrong bet. This is worth a direct question to your Dutchie account manager, as it affects more than just this page. Treat the sunset as reported, not yet confirmed by Dutchie in writing.

6The exact parameter — confirmed by Dutchie (Jul 7)

Dutchie (Kheresa Yeno, Implementation Strategist) confirmed exactly how the redirect works for our Plus setup. Two ways, and the exact parameter is r:

Option 1 — ?r= on the checkout URL · we control it

Append ?r=<return-url> to the checkout URL; Dutchie redirects the customer there after checkout.
Dutchie’s example: …/checkouts/(dispensaryId)/(checkoutId)?r=https://google.com
For us: ?r=https://sessions.ca/order-completed. Added in our own code — no Dutchie ticket needed.

Option 2 — Plus Default Return URL · Dutchie sets it

A default in Dutchie Admin (e.g. https://sessions.ca/order-completed) so no query param is needed.
That field is superuser-only — email apisupport@dutchie.com to set it.
The ?r= param from Option 1 overrides this default when present.

Dutchie also said the redirect is already slated to land on a confirmation page on our domain (Option 2). Worth confirming with apisupport what URL that default currently points to and aligning it to /order-completed. Scheduling note from Dutchie: no go-lives Jul 9–10 (“Oil Day”).

7Plan A — Test on demo now (zero risk to live stores)

Prove one full purchase-to-confirmation flow before launch, without touching any live store, using a throwaway / non-live test dispensary.

Do now · safe

Test flow on a non-live dispensary

Pick a test dispensary
Use a throwaway / not-yet-open dispensary ID — never a live store.
Wire the redirect (our side — no ticket)
Append ?r=https://demo.sessions.ca/order-completed to the checkout URL in the demo build — the ?r= method Dutchie confirmed. No Dutchie email needed. (Optionally also ask apisupport@dutchie.com to set the Admin default.)
Place one real end-to-end test order
Check out on that test store and let it complete on Dutchie.
Confirm the redirect + capture the parameters
You land on the branded page; we read the exact order-number and status keys off the return link and lock them in.
Sign off
Then schedule the go-live flip (Plan B).

Guardrail: only the test dispensary points at the demo URL — never a live store, so no real customer is sent to the demo build.

8Plan B — Go live on sessions.ca (at launch)

Once the site is live on sessions.ca, point the redirect at the production page. This is the one production, customer-facing lever — Sophie + Darryl sign-off.

At launch · approval

Point the redirect at the production page

Confirm the production page is live
Verify https://sessions.ca/order-completed loads.
Email Dutchie to set the redirect
Set the Post-Checkout Redirect URL to https://sessions.ca/order-completed.
Enterprise-wide or per store?
Ask Dutchie whether it can be set once for all dispensaries or must be per store. If per store, send the full store list / dispensary IDs.
Verify one real order
Place one live order and confirm the branded page + order number + status.
Bake into new-store onboarding
Then: dispensary ID → store goes live → the confirmation page is already wired.

Timing: flip at launch, or run Plan A on a throwaway dispensary first so we’ve watched one full order go through before touching production.

9What we need from Darryl

Set the redirect (or give access): can you set the Post-Checkout Redirect URL with Dutchie, or grant access so I can?
Enterprise vs per store: confirm with Dutchie whether it’s one enterprise setting or one per store.
Test first? okay to run Plan A on a throwaway / non-live test dispensary before launch?

Happy to jump on a quick call and set it together.

10Redirect URL cheat-sheet

Environment	Redirect URL to give Dutchie	When	Who sets it
Demo / test throwaway dispensary only	`https://demo.sessions.ca/order-completed`	Now (safe)	Dutchie API Support, on our email
Production all live stores	`https://sessions.ca/order-completed`	At launch	Dutchie API Support (Sophie + Darryl sign-off)

Dutchie appends the order details to whichever URL is set (order number + status). Exact key names are confirmed by Dutchie or captured in the Plan A test — see section 6.