The money path
Checkout, payment and the account area are rendered by the platform on every theme. This page explains why that boundary exists, because it is the single most important thing to understand about building here.
The boundary
Your theme links to /checkout. From there the platform takes over: pricing, tax, promotions, loyalty redemption, the payment provider handoff, the webhook that settles the payment, and the receipt. No theme code executes inside any of it.
Why
Pricing is not one multiplication. A single checkout may apply a promotion, redeem loyalty coins, compute inclusive or exclusive GST against the merchant’s registration status, split a partial payment, size a subscription mandate for future cycles, and reserve the allowances it just granted so two concurrent checkouts cannot both spend them.
Every one of those has a failure mode that costs someone real money. Centralising them means they are fixed once, tested once, and cannot regress theme by theme.
This is what makes themes reviewable. Because a theme structurally cannot touch payment, reviewing one is a design review. If themes could render into checkout, every submission would need a security audit — and no marketplace survives that.
What you still control
Everything up to the decision to buy, and the frame around what follows. You design the listing page, the pricing presentation, the call to action, and — through AccountShell — the chrome the account area renders inside. The transition should feel like one website, and that part is yours.