Shopify Checkout UI Extension Targets Explained

Introduction

Checkout UI extensions render at defined slots inside Shopify checkout called targets. The target you register determines three things: where your UI appears, whether it renders at all, and which APIs your code receives. Choosing the wrong one is the most common reason a working extension never shows up.

This is a complete reference for every checkout UI extension target available in API version 2026-07, organized the way Shopify organizes them. There are 31 targets in total: 24 on checkout and 7 on the Thank you page.

Two notes before the list, because both catch people out. First, checkout UI extensions for the information, shipping, and payment steps are available only to stores on a Shopify Plus plan. Thank you page targets are more broadly available. Second, the order status page is no longer part of this API — those extensions are now built with Customer Account UI extensions. If you are following an older guide that lists a purchase.order-status.* target, that guide is out of date.

Static targets vs block targets: the distinction that matters most

Every target is one of two types, and confusing them is the source of most "my extension isn't rendering" bug reports.

Static targets

Static targets render immediately before or after a specific core checkout feature — the contact form, the shipping method list, an order summary line item. Merchants activate and place them using the checkout and accounts editor.

The critical behaviour: when the core checkout feature isn't rendered, the static targets tied to it aren't rendered either. If a buyer selects store pickup, the shipping method list disappears — and so does anything registered to purchase.checkout.shipping-option-list.render-before. Same for digital-only carts and delivery address targets.

Choose static when your content is genuinely tied to that feature. A shipping delay notice belongs next to shipping methods and should vanish when they do.

Block targets

Block targets aren't tied to any section. Merchants reposition them anywhere in the flow using the checkout and accounts editor.

The critical behaviour: block extensions always render, even if the section they were placed in is hidden. An extension positioned above the shipping address still displays for a digital-only order.

Choose block when your content works independently of any one checkout feature — trust badges, promotional banners, loyalty messaging.

You can set a starting position with the default_placement property in your TOML, which controls where merchants first see your extension in the editor. During development, append a placement-reference query parameter to your dev store checkout URL to preview a block target at each supported location — for example ?placement-reference=INFORMATION1.

Configuring targets

Targets are declared in shopify.extension.toml using the extensions.targeting field. A single target can default-export the extension root directly. If you declare multiple targets, each one needs its own module with its own default export.

api_version = "2026-07"

[[extensions]]
type = "ui_extension"
name = "Checkout suite"
handle = "checkout-ui"

[[extensions.targeting]]
target = "purchase.checkout.actions.render-before"
module = "./Actions.jsx"

[[extensions.targeting]]
target = "purchase.checkout.shipping-option-item.render-after"
module = "./ShippingOptions.jsx"

Extension UIs are powered by Remote DOM, a sandboxed non-DOM rendering environment. Current builds use Polaris web components:

import '@shopify/ui-extensions/preact';
import {render} from 'preact';

export default async () => {
  render(<Extension />, document.body);
};

function Extension() {
  return <s-banner>Free shipping applied</s-banner>;
}

Older extensions use the React reactExtension pattern with @shopify/ui-extensions-react/checkout. That still works, but new builds should follow the current documented approach. Use Shopify CLI v3.85.3 or higher.

Checkout targets

Block

purchase.checkout.block.render — not tied to any section; renders where the merchant places it.

This is the most flexible and most commonly used target. Good for trust badges, promotional content, free shipping progress, and anything where merchant-controlled positioning is an advantage rather than a compromise.

Why it works: merchants who can reposition a block will test placements you would never have guessed. Handing them that control usually beats hardcoding your best guess.

Header

purchase.checkout.header.render-after — renders below the header, on every checkout page.

Persistent visibility across the whole flow. Use for announcements, promotional banners, free shipping thresholds, or progress indicators.

Information

purchase.checkout.contact.render-after — renders immediately after the contact form element.

Newsletter subscriptions, phone verification, marketing consent, contact preferences.

Why it works: the buyer has just committed their email, so they are engaged but not yet at the payment step where anxiety peaks. It is the cheapest moment in the flow to ask for one extra piece of consent.

Shipping

purchase.checkout.delivery-address.render-before — between the shipping address header and the form fields.

purchase.checkout.delivery-address.render-after — after the shipping address form.

purchase.checkout.shipping-option-list.render-before — between the shipping method header and the options.

purchase.checkout.shipping-option-list.render-after — after the shipping method options.

purchase.checkout.shipping-option-item.render-after — after the details of each shipping option.

purchase.checkout.shipping-option-item.details.render — under the shipping method within each option row.

Delivery date pickers, shipping insurance, carbon offsets, delivery instructions, per-option badges.

Note that the two shipping-option-item targets render once per option. Three shipping methods means three renders, and your component needs to key off the specific option it received rather than assume a single instance.

Why it works: shipping cost is among the most cited reasons for cart abandonment. Framing the value before the buyer sees the price list — or badging one option as the sensible default — reduces both price shock and decision paralysis.

Local pickup

purchase.checkout.pickup-location-list.render-before — before pickup location options.

purchase.checkout.pickup-location-list.render-after — after pickup location options.

purchase.checkout.pickup-location-option-item.render-after — after the details within each pickup location.

Location-specific notes, pickup time customization, inventory availability, store instructions. These render only when the buyer chooses pickup over shipping.

Pickup points (beta)

purchase.checkout.pickup-point-list.render-before

purchase.checkout.pickup-point-list.render-after

Carrier-managed pickup locations such as parcel lockers and post offices — distinct from local pickup at a merchant's own store. These are in early access and available only to custom apps built for Shopify Plus stores, with eligible fulfillment locations and eligible Shopify Shipping carriers.

Payment

purchase.checkout.payment-method-list.render-before — between the payment heading and the method list.

purchase.checkout.payment-method-list.render-after — below the list of payment methods.

Security badges, accepted payment icons, financing explanations, payment instructions.

Why it works: this is the point of maximum hesitation — the buyer is about to hand over card details. Trust signals placed here address the specific fear the buyer is holding at that exact moment, which is why the same badge converts better here than in the footer.

Order summary

purchase.checkout.cart-line-item.render-after — on every line item, inside the details under the line item properties element.

purchase.checkout.cart-line-list.render-after — after all line items.

purchase.checkout.reductions.render-before — before the discount form element.

purchase.checkout.reductions.render-after — after the discount form and discount tag elements.

Product warranties, gift wrapping, loyalty information, custom pricing detail, discount messaging.

The order summary is visible on every checkout page, so content here has the longest dwell time of anywhere in the flow. The reductions targets are the right home for discount-code messaging — explaining why a code failed, or that a cart already has the best available offer.

Navigation

purchase.checkout.actions.render-before — immediately before the action buttons within each step.

Marketing consent, gift notes, contextual cart messaging, loyalty points display.

Why it works: this sits directly above Pay now, which makes it the last thing a buyer reads before committing. It is the highest-attention slot in checkout and correspondingly the easiest to abuse — one clear line, not a block of content.

Footer

purchase.checkout.footer.render-after — below the footer, on every checkout page.

Policy links, trust signals, custom branding, consent collection, legal disclaimers.

Address autocomplete (runnable targets)

purchase.address-autocomplete.suggest — provides address autocomplete suggestions for checkout address forms.

purchase.address-autocomplete.format-suggestion — formats a suggestion provided by the target above.

These are runnable targets rather than rendering targets: they execute logic instead of drawing UI. Use them for custom address lookup services or region-specific address formats.

Thank you page targets

purchase.thank-you.block.render — merchant-positioned block on the Thank you page.

purchase.thank-you.announcement.render — dismissable announcement at the very top of the page.

purchase.thank-you.header.render-after — below the header.

purchase.thank-you.customer-information.render-after — below the customer information section.

purchase.thank-you.cart-line-item.render-after — on every line item, under the line item properties element.

purchase.thank-you.cart-line-list.render-after — after all line items.

purchase.thank-you.footer.render-after — below the footer.

Post-purchase offers, loyalty signups, referral prompts, review requests, order tracking, warranty and care information, return policy detail.

Why it works: payment is complete, so the anxiety that governs the checkout steps is simply absent. The buyer is in a positive state and there is no conversion risk in asking for something. This is why post-purchase upsells and loyalty enrollment perform far better here than anywhere in checkout proper.

Page layouts change where your extension appears

Targets are stable, but the layout the buyer sees is not — and most guides skip this entirely.

• Three-page checkout is the default. Information, shipping, and payment are separate pages, and extensions render on whichever page their target belongs to.
• One-page checkout combines all three steps plus the order summary onto a single scrollable page. Extensions render in their respective sections, but everything is visible at once, which changes how crowded your placement feels.
• Accelerated checkout via Shop Pay pre-fills buyer information and may combine or skip steps entirely — which means static targets tied to skipped steps will not render.

Test against all three. An extension that looks well-placed in three-page checkout can end up buried in one-page, and static targets can disappear completely in an accelerated flow.

Choosing the right target

Limitations worth knowing

Plus requirement

Checkout UI extensions for the information, shipping, and payment steps require Shopify Plus. Thank you page targets are available more broadly. Pickup point targets are additionally restricted to custom apps on Plus stores during early access.

Sandbox restrictions

Extensions run in a Remote DOM sandbox. They cannot access the raw DOM, cannot make arbitrary external network requests, and cannot read payment card data.

Static targets can silently not render

This is the most common source of confusion. If the core feature is absent — store pickup selected, digital-only cart, accelerated checkout skipping a step — the static target tied to it does not render. Nothing errors. If your content must always appear, use a block target.

Block targets need merchant placement

A block target will not appear until the merchant positions it in the checkout and accounts editor. Set default_placement so there is a sensible starting position.

API version alignment

Declare the correct api_version. Available targets and APIs change between versions; 2026-07 is current at the time of writing, and new targets ship with new versions.

Deploying

# Create an app
npm init @shopify/app@latest

# Generate the extension
shopify app generate extension
# Select: Checkout UI Extension

# Develop with live preview
shopify app dev

# Deploy
shopify app deploy

After deploying, open Settings → Checkout in Shopify admin and use the checkout and accounts editor to activate and position the extension.

Best practices

Match the target to the buyer's state. Each position in checkout corresponds to a different emotional moment. Contact is engagement. Shipping is cost sensitivity. Payment is trust. Thank you is goodwill. The same content performs differently depending on which of those it lands in.

Prefer block targets when you are unsure. If you have not established which placement converts, use the block target and let merchants test it rather than guessing on their behalf.

Keep extensions light. Avoid heavy external calls, keep component trees shallow, and use Shopify's own components rather than custom styling.

One extension per section. Stacking several extensions around the payment step creates clutter that undermines the trust you were trying to build.

Test on mobile, and in all three layouts. Most Shopify checkouts happen on narrow viewports, and one-page checkout changes the density of everything around your extension.

Frequently asked questions

How many checkout UI extension targets are there?

As of API version 2026-07 there are 31: 24 on checkout and 7 on the Thank you page. Two of the checkout targets are runnable rather than rendering targets.

What is the difference between a static target and a block target?

Static targets are anchored to a specific core checkout feature and do not render when that feature is absent. Block targets are merchant-positionable and always render regardless of which checkout features are present.

Why isn't my extension rendering?

The two most common causes: you used a static target whose core checkout feature isn't present in that scenario, or you used a block target the merchant hasn't yet positioned in the checkout and accounts editor.

Can I use checkout UI extensions without Shopify Plus?

Not for the information, shipping, or payment steps — those require Plus. Thank you page targets are available more broadly.

What happened to the order status page target?

The order status page is no longer covered by the checkout UI extensions API. Those extensions are now built with Customer Account UI extensions. Guides listing a purchase.order-status.* target are out of date.

How many targets can one extension declare?

There is no strict limit. Declare each in shopify.extension.toml under extensions.targeting. With more than one target, each needs its own module with its own default export.

Do checkout UI extensions work with Shop Pay?

Yes, but accelerated checkout may combine or skip steps, so static targets tied to a skipped step will not render. Test the accelerated flow specifically.

Where is the authoritative target list?

Shopify's developer documentation at shopify.dev, under the checkout UI extensions targets reference. Select your API version, since the list changes between versions.