How to design a checkout page - ElasticFunnels.io Documentation

This guide walks through building a working checkout page in the code editor (or page builder). It follows the real runtime: the same page can serve a one-time product, a subscription, or a multi-item cart depending on what the URL - or the page’s own backend script - resolves, so most of the layout is built from conditionals that the browser evaluates against live checkout data. For exact scope keys and totals, see Checkout functionality reference and Frontend Template Engine: Checkout. For wallet setup, see Apple Pay and Google Pay.

The templates below mirror a real production checkout (checkout.ef). Every directive shown is copied from a page that renders correctly against a live merchant — not invented for the docs.

How a checkout page renders

Two passes build the page:

Server pass (CheckoutProcessor). Runs if the page has the “Is checkout page” flag on, or if the page’s backend script named a product (see Step 1b). It resolves the product, builds the checkout scope (customer, totals, subscription, bumps, coupon, wallet settings), and swaps the checkout tags - <checkout-cc-panel> becomes a gateway-specific card <div>, <checkout-wallet> becomes the wallet containers. It injects the checkout payload onto window.efScope.checkout.
Client pass (frontend template engine). In the browser, it evaluates every block marked data-frontend-template="true" against the live scope (including values only known client-side, such as whether a wallet button actually rendered), fills the card/wallet forms, and wires the submit button.

If “Is checkout page” is off and the page’s backend script sets no product, CheckoutProcessor never runs. The tags are not swapped - <checkout-cc-panel> and <checkout-wallet> reach the browser as raw, inert custom elements, and checkout.* scope is empty. The page looks broken even with a valid merchant. This is the single most common reason a checkout “doesn’t work.”

Prerequisites

Enable “Is checkout page” on the page. Open Page List → Edit Page → toggle Is checkout page on → Save. (A page that names its product in a backend script can skip this - see Step 1b.)
Assign a merchant to the domain (Settings → Domains → Edit → Merchant). The card panel is swapped for a gateway-specific form (Stripe / NMI / Authorize.Net) resolved from this merchant.
Link at least one product so the page can resolve something to sell - from ?p=<code>, a cart, or a backend script.

“Is checkout page” is an app-only page setting. It is stored on the page and toggled in the dashboard. It is not settable from the ef CLI, and ef pages create does not set it - a page pushed with the CLI still needs the toggle flipped in the app, or a setVariable("checkout_product", …) in its backend script, before checkout runs. Quiz pages that take payment must have this flag on as well as their quiz flag; the two are independent.

Step 1 — resolve the product from the URL

A single-product checkout loads its product from the p query parameter: /checkout?p=your-product-6-bottles. The runtime reads req.query.p, looks the product up for the brand, and populates the checkout scope (title, image, price, retail price, and - if the product is a subscription - the full billing cadence). So a checkout page reached this way is generic; the ?p= code decides what it sells. A plan or quantity selector is just a set of links (or a script) that point at the same page with a different p:

<!-- Plan / quantity selector: each option is the same checkout page, different ?p= -->
<a href="/checkout?p=your-product-1-week">1 week</a>
<a href="/checkout?p=your-product-4-weeks">4 weeks - most popular</a>
<a href="/checkout?p=your-product-12-weeks">12 weeks - best value</a>

If there is no p in the URL, the page falls back to what its backend script named (Step 1b), and then to cart-only mode (see Step 2). A page with none of the three cannot resolve anything to sell.

Because product resolution happens on the server, checkout.subscription and the totals are already correct on first paint — no client fetch. See Buy links for how funnel buttons build the ?p= link.

Step 1b - set the product from a backend script

A ?p= in the URL assumes the buyer arrives from somewhere else - a landing page, a funnel button, a buy link. A one-page VSL + checkout has no such link. The visitor lands on the video, watches, and scrolls down to a checkout on the same page, so nothing ever put a product code in the URL. For that shape, the page names its own product in a <script scope="backend"> block:

<script scope="backend">
setVariable("checkout_product", "your-course-code");
</script>

That single line does three things:

Resolves the product server-side, exactly as ?p= would - same title, image, price, retail price and subscription cadence in the checkout scope, correct on first paint.
Turns the page into a checkout page. You do not need the “Is checkout page” toggle. Naming a product is the flag, so the checkout tags get swapped and checkout.* is populated on a page the dashboard still lists as an ordinary one.
Pins the selection to the session, so the submit charges what the page rendered rather than whatever the browser posts back.

The rest of the guide applies unchanged. The order summary, card panel, wallets, bumps and the formless submit are all built exactly as in Steps 2-8 - only where the product came from is different.

Precedence: the script wins over `?p=`

When a page sets checkout_product, it outranks any ?p= in the URL. That is deliberate rather than restrictive, because the backend sandbox already receives the query string - a page that wants the URL to decide simply says so:

<script scope="backend">
// URL wins when present, page default otherwise.
setVariable("checkout_product", request.query.p || "your-course-code");
</script>

Because the script is ordinary JavaScript, the same hook covers anything you can compute at render: a geo-priced variant, a returning customer’s upgrade code, a split-test arm, an expired-deadline fallback.

<script scope="backend">
// Cheaper variant once the launch window closes.
var launchOver = Date.now() > Date.parse("2026-09-01T00:00:00Z");
setVariable("checkout_product", launchOver ? "your-course-standard" : "your-course-launch");
</script>

Set checkout_product or checkout_cart, never both. A product code always wins and the cart is ignored, so setting both silently sells only the single product.

A page made a checkout page only by its backend script cannot be picked as a funnel’s or merchant’s checkout page target - the Set Checkout Page node validates the stored flag, which is still off. That is usually what you want, since such a page sells its own product rather than whatever a buy link asks for. If you need it in both roles, turn the “Is checkout page” toggle on as well; the script keeps working either way.

Selling several products from one page

Two ways, depending on whether the buyer chooses. A fixed bundle - the page decides, the buyer does not. Use checkout_cart with { code, quantity } lines. The order summary renders through the is_cart branch (Step 2) and the totals are the sum of the lines:

<script scope="backend">
setVariable("checkout_cart", [
    { code: "your-course-code",   quantity: 1 },
    { code: "your-workbook-code", quantity: 2 }
]);
</script>

Repeat a code and its quantities add up rather than producing a duplicate line; a line whose code is missing or malformed is dropped without taking the rest of the bundle with it. A cart the buyer fills - the VSL offers several products and the visitor picks. Put [ADD-TO-CART=<code>] buttons in the page copy and leave checkout_product / checkout_cart unset; the checkout section below reads the cart the buttons built:

<a href="[ADD-TO-CART=your-course-code]">Add the course - $297</a>
<a href="[ADD-TO-CART=your-workbook-code]">Add the workbook - $47</a>

The buyer-filled cart lives in browser storage, so it survives a scroll but not a cleared browser. A fixed checkout_cart is resolved on the server every render and cannot be edited by the visitor at all - prefer it whenever the bundle is not the buyer’s choice.

What the buyer cannot change

Whichever of the two the page sets, the resolved codes are pinned to the session against that page’s id while it renders. On submit the runtime charges the pin, not the posted fields - so an edited form, a stale tab, or a hand-crafted POST cannot swap the product out from under a page that already showed a price. Pages that use ?p= or a buyer-filled cart pin nothing and behave exactly as they always have.

Bumps are unaffected and stack on top of any of these. Configure them as in Step 7 - from page config or the Set Checkout Bumps node - and the buyer’s selections are added to the pinned product or bundle at submit.

Step 2 — single product vs cart

The order-summary area renders one of two shapes, chosen by scope flags:

Condition	When it’s true	Data source
`is_single_product`	One product, from `?p=` or `checkout_product`	`checkout.product_image`, `checkout.product_title`, `checkout.product_price`, `checkout.retail_price`
`is_cart`	A multi-item cart is present	`<template-foreach data-each="item in cartItems">` with `[[ item.name ]]`, `[[ item.image ]]`, `[[ item.quantity ]]`, `[[ item.total ]]`, `[[ item.code ]]`

Most carts here are Shopify-style carts - multi-item carts synced from Shopify. Most direct-response checkouts are single-product (one ?p=); the is_cart branch exists so the same layout can also render a synced Shopify cart with per-line quantities and remove buttons. See Shopify Checkout. The same branch renders the two on-page multi-product shapes from Step 1b: a fixed checkout_cart bundle, and a cart the buyer fills with [ADD-TO-CART=<code>] buttons.

Both branches must be marked data-frontend-template="true" (see Step 6 below). This is the exact production markup:

<div class="dt-co-card">
  <!-- Single product (from ?p=) -->
  <template-if data-condition="is_single_product" data-frontend-template="true">
    <div class="dt-co-prod-row">
      <div class="dt-co-prod-img-wrap">
        <template-if data-condition="checkout.product_image" data-frontend-template="true">
          <img ef-src="checkout.product_image" alt="Product" />
        </template-if>
        <template-else data-frontend-template="true">
          <span class="dt-co-prod-img-ph"><!-- placeholder icon --></span>
        </template-else>
        <span class="dt-co-prod-qty">1</span>
      </div>
      <div class="dt-co-prod-info">
        <p class="dt-co-prod-name"><span ef-text="checkout.product_title">Product</span></p>
      </div>
      <div class="dt-co-prod-price">
        <span class="dt-co-prod-price-old" ef-text="checkout.retail_price"></span>
        <span ef-text="checkout.product_price"></span>
      </div>
    </div>
  </template-if>

  <!-- Shopify-style cart -->
  <template-if data-condition="is_cart" data-frontend-template="true">
    <template-foreach data-each="item in cartItems" data-frontend-template="true">
      <div class="dt-co-prod-row">
        <div class="dt-co-prod-img-wrap">
          <template-if data-condition="item.image" data-frontend-template="true">
            <img ef-src="item.image" alt="[[ item.name ]]" />
          </template-if>
          <template-else data-frontend-template="true">
            <span class="dt-co-prod-img-ph"><!-- placeholder icon --></span>
          </template-else>
          <span class="dt-co-prod-qty" ef-text="item.quantity">1</span>
        </div>
        <div class="dt-co-prod-info">
          <p class="dt-co-prod-name"><span ef-text="item.name">Product</span></p>
          <div class="dt-co-qty-ctrl">
            <button type="button" data-cart-qty-minus data-code="[[ item.code ]]" data-disable-when-one aria-label="Decrease">&minus;</button>
            <span ef-text="item.quantity">1</span>
            <button type="button" data-cart-qty-plus data-code="[[ item.code ]]" aria-label="Increase">+</button>
          </div>
          <template-if data-condition="cartItems.length > 1" data-frontend-template="true">
            <button type="button" data-cart-qty-remove data-code="[[ item.code ]]" class="dt-co-prod-remove">Remove</button>
          </template-if>
        </div>
        <div class="dt-co-prod-price">
          <span ef-text="item.total"></span>
        </div>
      </div>
    </template-foreach>
  </template-if>
</div>

Do not read cartItems[0] inside the single-product block — use the checkout.product_* keys. In single-product mode cartItems is not the source of truth.

Step 3 — subscription vs one-time (conditional)

Key idea: the same checkout page serves both one-time and subscription products, because the ?p= code decides. So every subscription-specific element must be gated — never assume a subscription. Gate on the checkout.subscription object (it is null for one-time products, so it is falsy):

<template-if data-condition="checkout.subscription"> — subscription framing (recurring heading, billing note, “save vs one-time”, “Subscribe” CTA).
<template-if data-condition="!checkout.subscription"> — one-time order framing.

<template-if data-condition="checkout.subscription" data-frontend-template="true">
  <h2>Start your subscription</h2>
</template-if>
<template-if data-condition="!checkout.subscription" data-frontend-template="true">
  <h2>Complete your one-time order</h2>
</template-if>

The billing note (four cases)

Subscription products differ in how the first charge works, so the recurring note has to cover four mutually-exclusive cases. This is the production block verbatim — it reads checkout.subscription.{intro_offer, first_charge_free, trial_days, frequency, frequency_unit} and formats money with formatPrice(...) and values with [[ … ]]:

<template-if data-condition="checkout.subscription" data-frontend-template="true">
  <span class="subscription-billing-note">
    <!-- 1. Intro offer: N-period intro, then recurring price every cycle -->
    <template-if data-condition="checkout.subscription.intro_offer" data-frontend-template="true">[[ checkout.subscription.intro_offer.period ]]-[[ checkout.subscription.intro_offer.period_unit ]] intro &middot; Then [[ formatPrice(checkout.subscription.intro_offer.recurring_price) ]] every [[ checkout.subscription.frequency ]] [[ checkout.subscription.frequency_unit == 'month' ? (checkout.subscription.frequency > 1 ? 'months' : 'month') : checkout.subscription.frequency_unit ]]</template-if>

    <!-- 2. First charge free -->
    <template-if data-condition="!checkout.subscription.intro_offer && checkout.subscription.first_charge_free" data-frontend-template="true">Try free &middot; Then billed every [[ checkout.subscription.frequency ]] [[ checkout.subscription.frequency_unit == 'month' ? (checkout.subscription.frequency > 1 ? 'months' : 'month') : checkout.subscription.frequency_unit ]]</template-if>

    <!-- 3. Trial days -->
    <template-if data-condition="!checkout.subscription.intro_offer && !checkout.subscription.first_charge_free && checkout.subscription.trial_days > 0" data-frontend-template="true">[[ checkout.subscription.trial_days ]]-day trial &middot; Then billed every [[ checkout.subscription.frequency ]] [[ checkout.subscription.frequency_unit == 'month' ? (checkout.subscription.frequency > 1 ? 'months' : 'month') : checkout.subscription.frequency_unit ]]</template-if>

    <!-- 4. Plain recurring -->
    <template-if data-condition="!checkout.subscription.intro_offer && !checkout.subscription.first_charge_free && checkout.subscription.trial_days == 0" data-frontend-template="true">Billed every [[ checkout.subscription.frequency ]] [[ checkout.subscription.frequency_unit == 'month' ? (checkout.subscription.frequency > 1 ? 'months' : 'month') : checkout.subscription.frequency_unit ]]</template-if>
  </span>
</template-if>

Case	Condition	Note shown
Intro offer	`checkout.subscription.intro_offer` truthy	`2-week intro · Then $29.00 every month`
First charge free	`first_charge_free` and no intro	`Try free · Then billed every month`
Trial days	`trial_days > 0` and no intro/free	`14-day trial · Then billed every month`
Plain recurring	none of the above	`Billed every 3 months`

checkout.subscription.intro_offer.recurring_price is the price charged after the intro ends. The frequency_unit == 'month' ? … ternary just pluralizes “month/months”; other units (day, week, year) are printed as-is. For the full subscription scope shape (price_steps, prepaid, tiers), see Frontend Template Engine: Checkout.

In cart mode subscription data lives on each line (item.is_subscription, item.subscription), not on checkout.subscription.

Step 4 — wallets (Apple Pay / Google Pay)

Place a <checkout-wallet> tag where you want the express buttons. The runtime swaps it for an ef-wallet-standalone container holding #applePay and #googlePay, and the client injects whichever wallet the device supports:

<checkout-wallet wallets="applePay,googlePay"/>

<template-if data-condition="checkout.wallet_visible" data-frontend-template="true">
  <div class="ef-wallet-divider">
    <div class="ef-wallet-divider-line"></div>
    <span class="ef-wallet-divider-text">or pay another way</span>
    <div class="ef-wallet-divider-line"></div>
  </div>
</template-if>

The wallets value is camelCase: wallets="applePay,googlePay". The value is passed through verbatim as data-wallets and matched against the payment library’s wallet identifiers (e.g. Stripe’s disableWallets), which are camelCase. Snake_case apple_pay,google_pay is wrong — it is emitted unchanged, matches nothing, and silently fails to filter wallets. wallets and force are plain attributes, not data- prefixed, and <checkout-wallet> may be self-closing.

Notes on behavior:

Buttons appear automatically when the device/browser supports a wallet — you do not render them yourself.
checkout.wallet_visible flips false → true only once a wallet button actually renders (it is promoted, never reset). Gate the “or pay another way” divider on it so the divider never shows above an empty space. Add force="true" to pre-render the native Apple Pay button on iOS and set wallet_visible immediately, avoiding a first-paint layout shift.
Billing address comes from the wallet. When a customer pays with Apple/Google Pay, the correct billing address is taken from the wallet sheet — no extra fields needed in your template.

For a wallet-first layout, put <checkout-wallet force="true" wallets="applePay,googlePay"/> at the top and disable the card panel’s own wallet tab with data-applepay="false" (next step).

Step 5 — the card panel

Drop in a single <checkout-cc-panel> tag. Do not hand-build card inputs — the runtime swaps this tag for a gateway-specific secure card form resolved from the domain’s merchant:

<checkout-cc-panel data-accepted-cards="visa,mastercard,amex,discover" data-applepay="false"></checkout-cc-panel>
<div data-checkout-message></div>

What happens:

Server-side, the tag is replaced with <div class="checkout-cc-panel" data-gateway="{stripe|nmi|authorize_net}" data-accepted-cards="…">. The gateway is resolved from the merchant assigned to the domain.
Client-side, the secure card fields for that gateway are injected (Stripe Elements, NMI CollectJS, or Authorize.Net Accept.js). A resolved merchant/gateway is required for real tokenization.
data-accepted-cards sets the accepted card brands; data-applepay="false" suppresses the panel’s built-in wallet tab (use it when you place <checkout-wallet> separately).

Attribute	Purpose
`data-accepted-cards`	Comma list of brands, e.g. `visa,mastercard,amex,discover`
`data-applepay`	`"false"` hides the panel’s own wallet tab

<checkout-cc-panel> requires an explicit closing tag. Written self-closing (<checkout-cc-panel/>) it is neither expanded nor stripped and passes through to the browser as inert markup. (Only <checkout-wallet> / <checkout-apple-pay> may self-close.) Any children you write inside the panel are discarded.

Step 6 — mark client-side blocks with `data-frontend-template="true"`

Add data-frontend-template="true" to every template-if, template-else, and template-foreach whose condition depends on data that is only known in the browser: the wallet divider, subscription blocks, order bumps, cart items, coupon state, and any bump.added / checkout.wallet_visible conditional. Why: the server template pass and the client template pass are separate. Values like checkout.wallet_visible (true only after a wallet renders), bump.added (toggled by the shopper), and coupon state (applied after an async validation) do not exist during the server pass. Marking a block data-frontend-template="true" tells the server pass to leave it alone and hands it to the client engine, which evaluates it against the live scope. Without the flag, the server tries to evaluate the condition against empty scope and the block is dropped or renders wrong.

<!-- Evaluated in the browser, against live scope -->
<template-if data-condition="checkout.wallet_visible" data-frontend-template="true"> … </template-if>
<template-foreach data-each="item in cartItems" data-frontend-template="true"> … </template-foreach>

Server-side conditionals that depend on the request (e.g. Blade-style @if(query.p == 'your-product-4-weeks')) are the opposite case - those are evaluated during the render and do not take the attribute.

Pair client-side blocks with data-ef-cloak (and the CSS [data-ef-cloak] { display: none !important; }) on anything that would flash before the engine runs. Also hide the raw template-if / template-foreach tags with display: none !important so unprocessed markup never flashes.

Step 7 — order bumps

Bumps come from checkout.bump_products — an array with per-bump code, name, description, price (formatted), price_raw, image, added, and added_message. Loop it and render an offer state (!bump.added) and an added state (bump.added). Toggling with @click="bump.added = true/false" mutates the scope and re-renders:

<template-if data-condition="checkout.bump_products.length > 0">
  <template-foreach data-each="bump in checkout.bump_products" data-frontend-template="true">
    <!-- Offer state -->
    <template-if data-condition="!bump.added" data-frontend-template="true">
      <div class="dt-co-bump">
        <div class="flex justify-between gap-2 items-start mb-1">
          <span ef-text="bump.name">Add-on</span>
          <span ef-text="bump.price"></span>
        </div>
        <div data-ef-cloak>
          <p ef-text="bump.description"></p>
          <button type="button" @click="bump.added = true" class="dt-co-add-bump">Click to add to order</button>
        </div>
      </div>
    </template-if>
    <!-- Added state -->
    <template-else data-frontend-template="true">
      <div class="dt-co-bump-applied">
        <span ef-text="bump.name">Add-on</span>
        <span ef-text="bump.price"></span>
        <span ef-text="bump.added_message != '' ? bump.added_message : 'Added to your order'">Added to your order</span>
        <button type="button" @click="bump.added = false" class="dt-co-remove-bump">Remove</button>
      </div>
    </template-else>
  </template-foreach>
</template-if>

Added bumps also feed the totals — loop them again in the price summary, filtered to bump.added:

<template-foreach data-each="bump in checkout.bump_products" data-frontend-template="true">
  <template-if data-condition="bump.added" data-frontend-template="true">
    <div class="dt-co-price-row">
      <span ef-text="bump.name"></span>
      <span ef-text="bump.price"></span>
    </div>
  </template-if>
</template-foreach>

Placing a specific bump in a specific location

The loop above renders every bump in one place, in payload order. Most real checkouts want the opposite: a small shipping-protection checkbox tucked under the shipping fields, and a large product-bundle card in the sidebar - each styled differently. There is no “get bump by code” lookup. The idiom is to loop checkout.bump_products as usual and filter inside the loop on bump.code. Because the loop renders nothing when the condition never matches, you can repeat this block as many times as you like, anywhere on the page, and each bump lands in its own slot:

<template-foreach data-each="bump in checkout.bump_products" data-frontend-template="true">
  <template-if data-condition="bump.code == 'YOUR-BUMP-CODE'" data-frontend-template="true">
    <!-- everything for this one bump goes here -->
  </template-if>
</template-foreach>

That gives three nested levels - foreach → code filter → added/not-added - and every one of them needs data-frontend-template="true". A missing flag on any level drops the block during the server pass.

Example A - compact checkbox bump, next to the shipping fields

<template-foreach data-each="bump in checkout.bump_products" data-frontend-template="true">
  <template-if data-condition="bump.code == 'BUMP-SHIPPING-PROTECTION'" data-frontend-template="true">

    <!-- Offer state -->
    <template-if data-condition="!bump.added" data-frontend-template="true">
      <div class="bump-mini bump-mini--unadded">
        <label class="bump-mini-label">
          <input type="checkbox" class="bump-mini-checkbox"
                 @change="bump.added = $event.target.checked">
          <div class="bump-mini-content">
            <div class="bump-mini-top">
              <span class="bump-mini-name" ef-text="bump.name">BUMP NAME</span>
              <span class="bump-mini-price" ef-text="bump.price">BUMP PRICE</span>
            </div>
            <div class="bump-mini-desc" ef-text="bump.description" data-ef-cloak>Bump description</div>
          </div>
        </label>
      </div>
    </template-if>

    <!-- Added state -->
    <template-else data-frontend-template="true">
      <div class="bump-mini bump-mini--added">
        <label class="bump-mini-label">
          <span class="bump-mini-check">&#10003;</span>
          <div class="bump-mini-content">
            <div class="bump-mini-top">
              <span class="bump-mini-name" ef-text="bump.name">BUMP NAME</span>
              <span class="bump-mini-price" ef-text="bump.price">BUMP PRICE</span>
            </div>
            <div class="bump-mini-desc" ef-text="bump.description" data-ef-cloak>Bump description</div>
          </div>
        </label>
        <button type="button" @click="bump.added = false" class="bump-mini-remove">Remove</button>
      </div>
    </template-else>

  </template-if>
</template-foreach>

Checkbox toggling. @change="bump.added = $event.target.checked" works because the event scope exposes $event (and $el / $target) alongside the loop variable. @change and @input take the same alias families as @click (data-ef-on:change, data-ef-on-change, data-ef-change).This example is safe without :checked because the checkbox only exists in the !bump.added branch, so it always renders unchecked. If you collapse the two states into one block instead, bind the state explicitly: <input type="checkbox" :checked="bump.added" @change="bump.added = $event.target.checked">.

Example B - rich product card, in its own container

Same filter, different bump code, different markup and placement - this one sits in a dedicated wrapper so CSS can float it beside the summary:

<div class="bump-card-wrap bump-card-wrap--desktop-left">
  <template-foreach data-each="bump in checkout.bump_products" data-frontend-template="true">
    <template-if data-condition="bump.code == 'BUMP-BUNDLE'" data-frontend-template="true">

      <template-if data-condition="!bump.added" data-frontend-template="true">
        <div class="bump-card">
          <div class="bump-card-label">
            <span>Complete Your Bundle</span>
            <span class="bump-card-price" ef-text="bump.price">$0.00</span>
          </div>
          <div class="bump-card-body">
            <img ef-src="bump.image" alt="" class="bump-card-img">
            <div class="bump-card-info">
              <div class="bump-card-heading">Add all three and save</div>
              <ul class="bump-card-claims">
                <li>1&times; First product in the bundle</li>
                <li>1&times; Second product in the bundle</li>
                <li>1&times; Third product in the bundle</li>
              </ul>
            </div>
          </div>
          <button type="button" @click="bump.added = true" class="bump-card-btn">+ Add to My Order</button>
        </div>
      </template-if>

      <template-else data-frontend-template="true">
        <div class="bump-card bump-card--added">
          <div class="bump-card-label">
            <span><span class="bump-card-check">&#10003;</span> Added to your order</span>
            <span class="bump-card-price" ef-text="bump.price">$0.00</span>
          </div>
          <!-- …same body… -->
          <button type="button" @click="bump.added = false" class="bump-card-remove">Remove</button>
        </div>
      </template-else>

    </template-if>
  </template-foreach>
</div>

The payload only carries code, name, description, price, price_raw, image, added and added_message. Anything richer - the claims list, a bespoke heading, a hero image at a specific size - is hard-coded in the template, as above. Use ef-text / ef-src for the fields that come from the bump so price, name and image stay in sync with the Set Checkout Bumps node, and hard-code only the copy the node cannot supply.

The totals loop stays unfiltered

Wherever the bump was rendered, the price summary uses the same single loop over all bumps, filtered only on bump.added. Nothing there needs to know about placement or codes:

<template-foreach data-each="bump in checkout.bump_products" data-frontend-template="true">
  <template-if data-condition="bump.added" data-frontend-template="true">
    <div class="price-breakdown-row">
      <span ef-text="bump.name">Bump</span>
      <span ef-text="bump.price">$0.00</span>
    </div>
  </template-if>
</template-foreach>

Ticking the checkbox in Example A mutates bump.added, which re-renders the block into its added state, adds the row above, and rolls the bump price into checkout.subtotal and checkout.total - one state change, three places updated, no extra wiring.

A hard-coded bump.code is a contract with the funnel’s Set Checkout Bumps node. If that node stops supplying the code - renamed product, edited node, or a split-test branch that serves a different bump set - the filter simply never matches and the block renders nothing, silently. There is no error and no empty slot to notice in review.Keep the codes in the template and the node in sync, and when you split-test bump sets, make sure every branch either supplies the codes your template targets or the template also has an unfiltered fallback loop.

Where bumps come from

checkout.bump_products is filled from three sources, which merge. A code named by more than one is offered once:

The page’s own backend script, via checkout_settings.bumps. Use this when the page should always offer the same bump. See checkout_settings order bumps.
The Set Checkout Bumps node (set_checkout_bumps) in the funnel graph, whose bumps field is an array of bump objects (title, description, price, added_message, product code). The node is only offered when the page is flagged as a checkout page.
The ?bumps= query parameter, a comma-separated list of bump product codes. This is how a /b buy link carries a bump into the checkout.

?bumps= lives only in that one URL. A visitor who opens the page directly, shares the link, or reloads after the parameter is gone sees no bump. If a page should always offer one, declare it in the backend script or the node instead of relying on the link.

Because a bump set can come from a page-event node, you can A/B test bump configurations: place a Split Test → Traffic Distribution node in front, and give each branch its own Set Checkout Bumps node. Different visitors then get different bumps against the same checkout template, and the split test measures which set converts better. See Page event nodes → Set Checkout Bumps and Split testing.

`bumps` offers, `selected_bumps` chooses

The two query parameters do different jobs, and confusing them loses the offer:

bumps is the offer list: which bumps the checkout renders at all.
selected_bumps is the shopper’s choice among them, and is what the page writes back to the URL as they tick and untick. When it is present it also decides which boxes start ticked, so an empty selected_bumps= means “everything was unticked” and survives a refresh.

Never rewrite bumps from the current selection. That deletes the offer the moment nothing is ticked, and the next reload renders no bump at all.

Step 8 — the formless submit

Checkout submission is not a form submit. The <form> in the examples is only for autofill/semantics (onsubmit="return false;"); the runtime sets its form reference to null and collects every bound field from the page wrapper instead. Submission is a click on a [data-checkout-submit] button that preventDefault()s and posts via fetch — so fields do not have to live inside the <form>, and method="POST" has no effect. Wire it with three attributes:

data-template-value="checkout.customer.{field}" on each input/select — binds it into the checkout payload (email, phone, shipping_address, shipping_city, shipping_state, shipping_zip, billing_*, …).
data-checkout-error="{field}" on an empty element — the validation adapter fills it with that field’s error message.
data-checkout-message on one element — the general status/error line for the whole submit.
data-checkout-submit on the pay button (type="button").

<form id="quiz-checkout-form" autocomplete="on" onsubmit="return false;">

  <checkout-wallet wallets="applePay,googlePay"/>

  <div class="ef-floating-label-group">
    <input type="email" name="email" data-template-value="checkout.customer.email"
           autocomplete="email" placeholder=" " required />
    <label>Email address</label>
    <div class="ef-form-error" data-checkout-error="email"></div>
  </div>

  <checkout-cc-panel data-accepted-cards="visa,mastercard,amex,discover" data-applepay="false"></checkout-cc-panel>
  <div data-checkout-message></div>

  <button type="button" data-checkout-submit class="dt-co-submit">Purchase</button>
</form>

Backend config: `checkout_settings`

Checkout options are set in a <script scope="backend"> block via setVariable("checkout_settings", { … }). This is the production block:

<script scope="backend">
setVariable("checkout_settings", {
    collect_tax: false
});
</script>

The published object is read by both the render (to build the rendered dropdowns and labels) and process-checkout (to enforce the same rules on submit). It sits alongside checkout_product / checkout_cart (Step 1b) in the same backend block: one names what the page sells, the other configures how it takes payment.

setVariable is not optional, and assigning the object is not the same thing. Backend scripts run in a sandbox, and only what you pass to setVariable leaves it. A block that just writes var checkout_settings = {...} publishes nothing. It throws no error and the page still renders, so the failure is silent: the country allowlist is not applied and declared bumps never appear. If you build the object in steps, finish with setVariable("checkout_settings", checkout_settings).

Common keys:

Setting	Purpose
`checkout_settings.collect_tax`	Toggle tax collection
`checkout_settings.countries`	Restrict the country dropdown, e.g. `['US','CA','GB','AU']`
`checkout_settings.usStates`	Restrict the US state dropdown, e.g. `['CA','TX','FL']`
`checkout_settings.bumps`	Order bumps this page always offers, e.g. `['bump-shipping-protection']`
`checkout_settings.billing_fields`	Which fields the card panel’s auto-billing block shows (`['country','zip']`); exposed as `checkout.panel_billing_fields`
`checkout_settings.abuse_protection`	Card-testing / velocity protection
`checkout_settings.wallet.recurring_description`	What recurs, shown on the Apple Pay sheet
`checkout_settings.wallet.recurring_label`	Line item label on the Apple Pay sheet
`checkout_settings.wallet.management_url`	Where the buyer manages or cancels the subscription, shown by Apple

Full semantics: Checkout functionality reference → checkout_settings.

Output bindings reference

Two ways to print scope values, used throughout the examples above:

Binding	Use	Example
`ef-text="expr"`	Set an element’s text	`<span ef-text="checkout.product_title">Product</span>`
`ef-src="expr"`	Set an `<img>` `src`	`<img ef-src="checkout.product_image" />`
`ef-alt="expr"`	Set an `<img>` `alt`	`<img ef-alt="checkout.product_title" />`
`[[ expr ]]`	Interpolate inside text/attributes	`alt="[[ item.name ]]"`, `data-code="[[ item.code ]]"`

Use [[ … ]] where you need a value inside an attribute or mixed with other text (data-code="[[ item.code ]]"); use ef-text / ef-src / ef-alt for a whole element’s text or image. formatPrice(raw) formats a raw number as currency. <template-foreach> also drives select dropdowns for country/state, each option { value, label }:

<select name="shipping_state" data-template-value="checkout.customer.shipping_state">
  <option value="">Select State</option>
  <template-foreach data-each="opt in checkout.usStates">
    <option value="[[ opt.value ]]">[[ opt.label ]]</option>
  </template-foreach>
</select>

Page builder vs code editor

Everything above is code-editor HTML. In the page builder, use the Checkout block category, which maps to the same tags/bindings:

Checkout Details — contact + shipping + billing fields
Credit Card Form — <checkout-cc-panel>
Checkout Button — <button data-checkout-submit>
Price Summary — totals section
Checkout Coupon — coupon input with apply/clear (data-apply-coupon, data-clear-coupon)
Checkout Bumps — order bumps
Single Product Summary / Cart Products — the is_single_product / is_cart blocks

For a wallet-first layout, add a <checkout-wallet force="true" wallets="applePay,googlePay"/> custom-code block above Checkout Details and set data-applepay="false" on the Credit Card Form.

Checkout functionality reference — scope keys, checkout_settings, abuse protection, submit flow
Frontend Template Engine: Checkout — checkout.* bindings, totals, subscription shape
Apple Pay and Google Pay — wallet setup
Shopify Checkout — where is_cart carts come from
Buy links — building the ?p= link
Backend scripts: actions - setVariable and the rest of the <script scope="backend"> surface used in Step 1b
Set Checkout Bumps node and Split testing — configuring / A/B-testing bumps
Checkout redirect behavior — post-checkout routing

​How a checkout page renders

​Prerequisites

​Step 1 — resolve the product from the URL

​Step 1b - set the product from a backend script

​Precedence: the script wins over ?p=

​Selling several products from one page

​What the buyer cannot change

​Step 2 — single product vs cart

​Step 3 — subscription vs one-time (conditional)

​The billing note (four cases)

​Step 4 — wallets (Apple Pay / Google Pay)

​Step 5 — the card panel

​Step 6 — mark client-side blocks with data-frontend-template="true"

​Step 7 — order bumps

​Placing a specific bump in a specific location

​Example A - compact checkbox bump, next to the shipping fields

​Example B - rich product card, in its own container

​The totals loop stays unfiltered

​Where bumps come from

​bumps offers, selected_bumps chooses

​Step 8 — the formless submit

​Backend config: checkout_settings

​Output bindings reference

​Page builder vs code editor

​Related docs

How a checkout page renders

Prerequisites

Step 1 — resolve the product from the URL

Step 1b - set the product from a backend script

Precedence: the script wins over `?p=`

Selling several products from one page

What the buyer cannot change

Step 2 — single product vs cart

Step 3 — subscription vs one-time (conditional)

The billing note (four cases)

Step 4 — wallets (Apple Pay / Google Pay)

Step 5 — the card panel

Step 6 — mark client-side blocks with `data-frontend-template="true"`

Step 7 — order bumps

Placing a specific bump in a specific location

Example A - compact checkbox bump, next to the shipping fields

Example B - rich product card, in its own container

The totals loop stays unfiltered

Where bumps come from

`bumps` offers, `selected_bumps` chooses

Step 8 — the formless submit

Backend config: `checkout_settings`

Output bindings reference

Page builder vs code editor

Related docs