Hi,
I’m trying to ascertain the limitations of a Post Checkout Extension before beginning work on one.
On a Shopify page, am I allowed to
Also, is the layout/composition of the Post Checkout Page stable enough for me to pick two places (e.g. before and after the order summary) to render new components in? Or is the placement of extension elements fixed?
Hey @joriswpp 
, thanks for the questions. Happy to help look into this!
Just to clarify, are you building for the post‑purchase interstitial page (after payment, before Order status), or for the Thank you / Order status pages?
If it’s post‑purchase, extensions can make network requests to your own service using fetch from a web‑worker, but your server must allow CORS (for example, Access‑Control‑Allow‑Origin: *).
My understanding is that cookies are not available for post purchase functions and essentially won’t behave like first‑party storage relative to the checkout domain, so I’d recommend using the extension Storage API and your backend for persistence.
The post‑purchase page is technically a single surface that you render so, there aren’t discrete “before/after order summary” targets there. If you need to compute pricing or edit the initial purchase, use calculateChangeset/applyChangeset from the Post‑purchase API, and call done() to continue to the Order status page.
If your goal is to place content before or after the order summary, that would technically map to Checkout UI extension targets on the Thank you / Order status pages, not post‑purchase.
You could pick a precise target (for example, after all line items) from the targets catalog here: https://shopify.dev/docs/api/checkout-ui-extensions/targets, and the Thank you / Order status overview is here: About Thank you and Order status page customization.
For those UI extensions, you’d want to enable external calls by allowing network_access in your extension configuration and Partner Dashboard, and observe the CORS requirements documented here: https://shopify.dev/docs/api/checkout-ui-extensions/latest/configuration#network-access.
If you want flexible placement managed by merchants, I’d also reccommend considering block targets (for example, purchase.thank-you.block.render) so merchants can position your block in the editor.
Could you let me know which surface you’re looking at targetting and the exact spot where you want the UI to render, plus what data you need to fetch, so I can point you to the exact targets/APIs and sample code? Happy to help out further if need be and hope this helped a bit, feel free to ping me here 
Thanks for your elaborate response.
Indeed I meant the post‑purchase interstitial page, as that is the ostensible landing page after completing the purchase.
I had an outdated impression of what that page looks like (unaware of the distinction between post-purchase and thank you page) so may have to revisit my requirements.
Would you have docs/screenshots on the default (uncustomized) look of either page?
The only docs on Thank You have a 404 for the screenshot, and the UX doc for Post Purchase only shows a blank canvas for us to fill.
Hey @joriswpp no worries, happy to share, definitely odd that the Thank you page is showing a 404 error. Here’s what the extension usually looks like in that context:
For the post-purchase offer page, seeing it as blank is essentially expected, since without a Post Purchase extension, that page isn’t surfaced to the customer and is basically built by the extension on the frontend. There’s a pretty good overview of this here made by another Partner dev that I wanted to share in case it’s helpful:
Hope this helps - let me know if I can assist further/if i’m missing something here, happy to help!
Thanks again. Just to clarify:
If I don’t build a post-purchase extension, the user will land on the Thank You page right after completing payment?
That simplifies matters as I’d only need to think about the Thank You page, assuming its composition, features and limitations align with my goals.
Or is there a default post-purchase page that is used even if no post-purchase extension is installed?
As an aside, does an extension to the Thank You page support reading/storing first party cookies?
Also, can UI Extensions use the App’s own back end server rather than a service of my own?
No worries @joriswpp , you’re correct, if there isn’t a post-purchase extension running with its ShouldRender extension point telling the Shopify frontend to render the extension, the customer will land on the Thank You page as soon as payment is complete!
When it comes to your other question there, just confirming that extensions are technically “sandboxed” and don’t have access to first‑party cookies or localStorage outside of their little implementation area.
On the Thank you page though, you could use the OrderConfirmationApi to grab the order id for example and use your backend to pull for info on the order to surface into the extension using the Admin API: GraphQL Admin API reference
You’d just want to make sure you’re enabling network access for your extension:
Just wanted to share that as a possible workaround too depending on your use case. Let me know if I can clarify as always, hope this helps!
Thanks a lot for your help so far Alan!
Last question I have is: Will a post-purchase extension compete with possible other apps that use post-purchase extensions? Would different apps each add a post-purchase page to the check-out process, or would different apps’ components be combined on the post-purchase page?
Hi @joriswpp ,
Good question.
In the past, post purchase functionality was extended through script tags, so it was easy for apps to collide and override each other. Merchants also didn’t have direct control over positioning of these widgets by 3rd party apps.
Now with Customer Account Extensions (TYP/OSP) merchants have the control to drag and drop your extensions just like theme blocks into the Order Status or Thank You page.
That way the merchant can decide where your block lives on their page, and decide which apps are allowed to integrate into this page.
Extensions cannot override each other, since they’re limited to only mounting on a target, not to a DOM element directly.
So it’s a totally different paradigm, and it’s much more extendable without apps colliding.
