Shipping, Taxes, Payments and Checkout Settings

Shipping has a vocabulary of its own that the admin and the API use with slightly different names.

Source: Admin GraphQL API: DeliveryProfile

Shipping is configured in Settings, Shipping and delivery. Each store has a General profile that applies to all products; all existing and new products are added to it, and a product or variant that is not in a custom profile uses the General rates. A store can create up to 99 custom profiles when different products need different rates, for example fragile products that need a more expensive service. A product or variant belongs to exactly one profile at a time: adding it to a second profile removes it from the first, and removing a variant from a custom profile returns it to the General profile (the API field variantsToDissociate is documented the same way).

When a profile is created, every location that can fulfill online orders is added to it in one location group, so that all those locations share the same zones and rates. A location can be moved into its own location group to give it different zones and rates, removed from a group (shown under "Not fulfilling from"), or added to an existing group. If the last location of a group is removed, the group’s zones and rates are deleted. Locations that are deactivated are labeled Inactive: rates can be added to them, but they are not used at checkout until the location is activated. A location created after a profile is added to every profile as not fulfilling. Some apps that manage fulfillment, such as on-demand printing apps, are added to the profile as locations automatically and can change the setup.

A new store gets default rates created from the store location, domestic and international, and the Help Center warns that these frequently include a free shipping rate; they should be reviewed before the store accepts orders. Staff or collaborators need the Products and Manage settings permissions to work with shipping profiles.

Within a zone, a rate has one of four types:

Any rate can be made free by leaving the price empty or entering 0, and the "Offer free shipping" option adds a minimum order amount above which the rate costs nothing. Flat rates can show a transit time (a suggested value or a custom range such as 3-5 days) that feeds the delivery estimate at checkout. Flat rates in local currencies exist only for stores that use Shopify Payments: a rate set per market currency is shown as set, whereas automatic conversion of a EUR rate shows a converted amount (the Help Center gives roughly 120 SEK for a 10 EUR rate); separate zones per region give fixed prices instead of converted ones.

Source: Shopify Help Center: Setting up shipping zones and rates

Carts whose items sit in different profiles or ship from different locations get a single combined rate. The rules, as documented, are these:

The consequence is that the way profiles and rate names are organized changes what the buyer pays, and the Help Center states that a combined rate can lead to higher shipping costs. Two Pocket Coffee consequences: the Standard rate in the Spanish zone and the same-named Standard rate in a second profile for the Starter kit would be added together unless the profiles are deliberately named and priced as one rate, and the shop should keep every variant of the same parcel in one profile.

Source: Shopify Help Center: Calculating shipping rates from different shipping profiles

When all app or carrier calculated rates of a shipment fail and no other eligible rate exists, backup rates are shown so that checkout does not stall. They apply to the whole store by default and need no setup, only when at least one app or carrier-calculated rate exists. Shopify-supported carriers provide them where available (USPS, Canada Post, Evri, Chronopost, Poste Italiane and Correos in the listed countries), country-specific rates built from historical data cover the other zones, and legacy custom backup rates by order value or weight still work. Flat rates for the same destinations are always shown when eligible, so they can be chosen even while calculated rates work. A product without a weight is treated as weight 0 when backup rates are chosen, which can produce wrong prices. Since 2025-05-22 a 3xx or 4xx response from a carrier also triggers backup rates instead of a hard failure.

Source: Shopify Help Center: Backup shipping rates

The Admin API reaches the same objects. The mutation below creates a profile for the beans with two Spanish rates that cover the order amount below and above 40 EUR, and an EU rate limited to 5 kg. The two Spanish rates are separate method definitions because a rate in the admin has either order amount conditions or weight conditions; the 5 kg parcel limit is enforced by the EU weight range and, for Spain, by splitting orders operationally. The variables use placeholder ids.

Source: Admin GraphQL API: deliveryProfileCreate

The document and the variables were validated against the 2026-10 Admin schema (types, enum values and required fields); the mutation was not sent to a store. The fields of DeliveryProfileInput that matter:

Inside a location group, locationsToAdd, locationsToRemove (up to 250 each per request) and locations (move to this group) manage locations, and zonesToCreate and zonesToUpdate manage zones (the documentation recommends at most 5 per request). A zone takes countries (each with code, provinces, includeAllProvinces or restOfWorld) and methodDefinitionsToCreate. A method definition has name, description, active, a rateDefinition with the price, or a participant for a carrier or app rate, and priceConditionsToCreate or weightConditionsToCreate whose operator is GREATER_THAN_OR_EQUAL_TO or LESS_THAN_OR_EQUAL_TO. A condition is either a money amount or a weight with the unit KILOGRAMS, GRAMS, POUNDS or OUNCES.

Source: Admin GraphQL API: DeliveryProfileInput

Reading a profile back returns its structure and the current rates. Rates are a union, so the query asks for rateProvider with fragments for a plain rate and for a carrier or app participant, and for the conditions.

Source: Admin GraphQL API: deliveryProfile

version increases on each change and locationsWithoutRatesCount is the quickest way to find a location that fulfills orders but has no rates. Adding and removing variants later is an update:

Source: Admin GraphQL API: deliveryProfileUpdate

Two changes to the shape of these objects are published and affect integrations that read merchant-managed profiles. Starting with the unstable API version, a shipping option can contain several tiered rates, and DeliveryMethodDefinition.rateGroups and DeliveryRateDefinition.conditions are meant to replace the legacy rateProvider and methodConditions fields that the examples above use; the legacy fields are scheduled for deprecation and become obsolete when merchants use multiple tiered rates. The 2026-10 schema validated for this page still contains only the legacy fields. Apps that write merchant-managed profiles have to move to the new write input (rateGroupsToCreate, rateGroupsToUpdate, freeConditions, currencyCode), whereas apps that read and write profiles that they own need no action.

Source: Shopify developer changelog: New APIs to read and write shipping options in delivery profile

Rates only work if the variants carry the right data. The variant’s inventory item holds requiresShipping, the weight (measurement.weight), the country of origin and the harmonized system code that customs and duty calculations use. The mutation sets them for a Pocket Coffee bean variant; 090121 is the six-digit heading for roasted coffee that is not decaffeinated.

Source: Admin GraphQL API: productVariantsBulkUpdate

The same mutation sets taxable, which the tax section below uses. The deprecated taxCode field of the same input is discussed there.

A carrier service is an endpoint that Shopify calls for rates at checkout. It is registered with carrierServiceCreate (scope write_shipping).

Source: Admin GraphQL API: carrierServiceCreate

The requirements and behaviors of the callback are:

A minimal callback for Pocket Coffee that offers an Express rate (12.90 EUR) inside Spain for parcels up to 5 kg:

Source: Admin REST API: CarrierService (rate request and response format)

The callback was started locally and called with three sample requests built from the documented request format. A Spanish destination with two 250 g bags returned the rate ("total_price":"1290", status 200). A German destination and a Spanish cart of 8 kg both returned {"rates":[]} with status 200, and a request body that is not JSON returned 400, which Shopify turns into backup rates. The REST page documents the wire format; the REST Admin API itself is legacy since 2024-10-01 and new public apps must use GraphQL since 2025-04-01, so registration goes through the GraphQL mutation above.

Besides shipping, a store can offer other delivery methods:

Source: Shopify Help Center: Setting up local delivery for online orders

Source: Shopify Help Center: Split shipping in Shopify Checkout

Shopify is replacing merchant-owned delivery profiles, location groups and zones with shipping options attached to each market. A market has options (flat, order-value, weight or carrier-calculated), and inside one option the rate can vary by product and location conditions. Product conditions are all products or collections (rates are no longer assigned to single variants, so a group of variants needs a collection), and location conditions pick the fulfillment locations. When several rates in the same option match a cart, only the highest matching rate is charged instead of the sum, and when several options match, the option prices are added. The upgrade combines rates with the same name into one option, turns the former product groupings into unpublished collections with the prefix [Shipping], can create sub-region markets to keep the former zone coverage, and keeps split shipping on. Staff need the Markets permission to manage it because existing roles do not receive it automatically.

The timeline (the dates are targets and may shift) is: feature preview from 2026-07-01 (selected when a development store is created), merchant rollout beginning on 2026-10-01 for stores whose apps are compatible, and all merchants on market-driven shipping by 2027-07-01. Until then the Help Center page for shipping options by market is labeled early access and only for certain stores, and a store keeps its profile-based setup until it is upgraded; a merchant can opt out during a window after the upgrade.

For apps the rule is simple. App-owned profiles keep working with deliveryProfileCreate and deliveryProfileUpdate and can now use coversAllItems. The merchant-owned profile fields and mutations (deliveryProfile, deliveryProfiles, deliveryProfilesCount, deliveryProfileLocationGroup, deliveryProfileLocationGroups, deliveryProfileCreate, deliveryProfileUpdate, deliveryProfileRemove) no longer represent the live merchant configuration on a shop that uses the new model: reads may return a stale snapshot and writes can succeed without changing anything. Readers should switch to Contextual Product Feeds (for sales channels) or read Market.delivery, writers should become app-profile integrations or write with marketCreate and marketUpdate, and the model of a shop is detected with ShopFeatures.marketDrivenShipping. Apps that ship from their own locations (fulfillment networks, print on demand) fit app-owned profiles; carrier-rate apps for the merchant’s own locations need the Markets API because, before the shop is upgraded, the merchant’s rates take precedence at a location that appears in both profiles.

Source: Shopify developer docs: Upgrade your app for market-driven shipping

The document validates against the 2026-10 schema (MarketUpdateInput.delivery.shipping with optionDefinitionsToCreate, a flat-rate option with rateGroups, freeDeliveryMinimumValue and transit times in seconds). It requires read_markets and write_markets; isEnabled: false removes shipping for a market, a null Market.delivery.shipping means the market inherits from its parent, and removeShipping: true in MarketDeliveryConfigurationsUpdateInput removes a market’s own configuration. Carrier-calculated options exist as DeliveryCarrierCalculatedOptionDefinition and the other types are DeliveryValueBasedOptionDefinition and DeliveryWeightBasedOptionDefinition.

Source: Shopify developer changelog: Market-driven shipping Admin API

A Delivery Customization Function changes the options that exist at checkout without changing the stored rates. It can hide an option, rename it and move it to another position; the target is cart.delivery-options.transform.run. The carrier name is prepended automatically when a carrier-calculated option is renamed (UPS Standard can become UPS Standard Shipping, but never just Standard Shipping), and reordering must not push a more expensive option above the cheapest one as the default. Shopify caches delivery options during checkout and may reuse function results. Since 2026-09-15 on API version 2026-10 a delivery option exposes metafields to the function input, so a delivery option generator and a customization function can exchange structured data instead of parsing titles. The CLI template is created with shopify app generate extension --template delivery_customization --flavor vanilla-js --name pocket-coffee-delivery; that command needs a logged-in organization and was not run. The extension below was created from the template files instead (the schema and structure of functions-delivery-customization-js in Shopify’s extension templates repository).

The Pocket Coffee rule: show the Express option only to destinations in a configurable list of countries (Spain by default) and call the Standard option "Standard (Coffee Club)" for customers with the tag Coffee Club. The tag test uses an aliased hasAnyTag field in the input query.

Source: Shopify developer docs: Rename a delivery option

Source: Shopify developer docs: Rename a delivery option

The build and the two runs used Shopify CLI 5.0.0 and the bundled function runner, with no store. The extension has a package.json with the codegen section and @shopify/shopify_function 2.0.1, the entry src/index.js re-exports the function, and command = "" makes the CLI use its JavaScript builder.

Source: Shopify CLI: app function run

The build printed Building GraphQL types, Bundling JS function, Running javy and pocket-coffee-app built!, and wrote a Wasm module of 2,368 bytes. The input for a Spanish member (Express stays because ES is in the list) and the function output:

Source: Shopify CLI: app function run

The run took 218,476 instructions. For a guest in Germany with no configuration metafield (the default list is ["ES"]) the output hides the Express option and leaves Standard alone, in 205,107 instructions:

Source: Shopify Functions: Delivery Customization API

Three things were learned from the run. The --input path must be absolute because the CLI resolves a relative path against the extension directory. The extension needs the codegen key in its package.json or the type generation step fails. And the function runner prints resource limits (input 125 KB, output 19.53 KB, 11 million instructions) next to the measured benchmark, so the margin is visible; these runs used about 2 percent of the instruction limit.

The function is attached to a store with deliveryCustomizationCreate (scope write_delivery_customizations) using the function handle from the descriptor; configuration travels in a metafield in the app-reserved namespace $app:pocket-coffee-delivery, key function-configuration, which the input query reads with jsonValue.

Source: Admin GraphQL API: deliveryCustomizationCreate

Merchants see the same customization under Settings, Shipping and delivery, Delivery customizations, where they add it and activate it; customizations also apply to draft order checkouts but are not visible while the draft order is being built in the admin. Public apps with Functions work on every plan, custom apps with Functions need Plus.

The Storefront API exposes the delivery groups and options of a cart, in the context of a country and language. The queries were validated against the 2026-10 Storefront schema.

Source: Storefront API: cartSelectedDeliveryOptionsUpdate

A cart only has delivery groups once it has a delivery address, and the options of a group already include the effect of delivery customization Functions. The Storefront CartCost tax and duty fields (totalTaxAmount, totalDutyAmount and their estimated flags) are deprecated since 2025-01-01 and tax and duty amounts are no longer available there, so a headless storefront should show tax notes without computing them (see the tax section).

In a Liquid theme, a snippet can state the tax and shipping assumptions under the cart total. cart.taxes_included, cart.duties_included, cart.requires_shipping, cart.items_subtotal_price, localization.country, shop.address.country_code and shop.shipping_policy are Liquid objects, and the free shipping threshold is passed in by the caller in the minor units of the presentment currency instead of being computed from a base price, which keeps it correct when a market changes the currency.

Source: Shopify Liquid reference: cart

Source: Shopify Liquid reference: payment_type_svg_tag

Source: Shopify Liquid reference: cart

The three files and the locale keys were added to a copy of the Skeleton theme created with shopify theme init, and shopify theme check reported 42 files inspected with no offenses found. Before the section referenced the two snippets, Theme Check reported them as OrphanedSnippet warnings, and a deliberate typo (payment_type_svg_tags) was caught as an UnknownFilter error, so the checker covers filter names as well as syntax. Theme Check does not render the theme; the output on a real storefront was not observed.

Tax is the merchant’s responsibility. Shopify calculates and, with Shopify Tax and automated filing, can file, but it does not remit or file taxes otherwise, and the Help Center repeats on every tax page that merchants should confirm rates with a tax professional. The tax service available depends on the store location:

Source: Shopify Help Center: Taxes

Shopify Tax calculates with tax registrations and product categories, uses rooftop accuracy in the United States, and for the EU and UK adds proportional shipping tax by product category, tax liability insights and VAT invoices. The feature differences that matter for a European store:

Source: Shopify Help Center: Choose a tax service

Mixing services in the same region is discouraged: using Manual Tax together with Basic Tax or Shopify Tax in the EU and the UK can prevent duties from being collected correctly. Manual Tax does not offer the automatic calculations, rooftop accuracy, Managed Markets, tax holidays, liability insights, advanced reports, B2B or customer exemptions or VAT invoices.

Shopify Tax is free until a sales threshold and then charges a percentage fee on orders from regions where collection is activated. The fee is billed with the Shopify subscription, never to buyers. The rules depend on when the store was created:

Source: Shopify Help Center: Shopify Tax pricing

The sales that count toward the threshold include online, other channels, Shopify POS, Shop, gift cards, sales with non-taxable products and every payment gateway. The fee also applies to orders where no tax was charged because of product exemptions, but not to orders from regions where tax collection is off and not to imported orders.

By default prices are shown without tax and tax is added at checkout: a 100 USD product at 15 percent shows 100 USD and 115 USD at checkout. Two settings change the display only, never the calculation. "Include sales tax in product price and shipping rate" in Settings, Taxes and duties shows tax-inclusive prices everywhere, and per-market tax-inclusive pricing shows inclusive prices to customers in markets that expect them (for example the UK) and exclusive prices in others. With inclusion the tax is computed as the rate times the price divided by one plus the rate, shown as a line item, while the subtotal and total stay equal to the listed price. For a Pocket Coffee 250 g bag at 8.90 EUR and an illustrative 10 percent rate (the rate is only an example, not a statement about the coffee VAT rate in Spain):

When a store sells in several tax-inclusive regions, the home tax rate (from the store address) is removed from the listed price before the destination rate is applied: a 100 listed price at 10 percent home tax has a product part of 90.91, which is charged as 90.91 where no tax is due and as 109.09 where 20 percent applies. A customer marked tax exempt still pays the full listed price when prices include tax. Tax inclusion by customer location is not supported for stores that use third-party post-purchase upsell apps. In the theme, cart.taxes_included and shop.taxes_included tell the storefront which wording to show, and the Admin API exposes Shop.taxesIncluded, Shop.taxShipping and, per order, taxesIncluded, estimatedTaxes and taxLines.

Source: Shopify Help Center: Include taxes in product prices

Source: Admin GraphQL API: customerAddTaxExemptions

The validation against the 2026-10 schema confirmed the enum value, and a deliberately wrong value (NOT_A_RULE) was rejected with Value "NOT_A_RULE" does not exist in "TaxExemption" enum.

Source: Shopify Help Center: Tax overrides and exemptions

A third-party tax app replaces Shopify’s tax service for the store; the two cannot be active together. It needs an account at the provider and complete location addresses, keeps tax-inclusive pricing, the taxable flag, customer non-taxable settings and duties collection active, and falls back to the settings in the admin when the app is unavailable. Imported historical orders are sent to the provider unless they carry the tag import or imported. Shopify’s Tax Platform for building tax calculation apps is available by invitation only to selected tax software companies: the taxAppConfigure mutation (scope write_taxes, restricted to tax calculation apps) marks the app ready, the tax_calculation extension template defines the calculation endpoint, and requests and the tax_summaries/create webhook have received fields over time (merchant business entity since 2026-04-01, customer and company metafields, cart line properties, global IDs on 2026-10-01). ProductVariant.taxCode is deprecated since 2025-10 because the Avalara AvaTax app it served is discontinued; it applies only to stores that had that app. A change in 2026-10 recalculates taxes when the shipping address of an order is updated.

Source: Shopify developer docs: Tax Partner Apps

Order-level tax data is read from the Admin API; amounts come as money bags with shop and presentment values.

Source: Admin GraphQL API: Order

The same operation shows the shipping line with its own tax lines and the transactions of the order, which the payments section uses.

Customers pay with the methods activated in Settings, Payments, Payment providers. A store can use Shopify Payments, a third-party provider or both, and add PayPal, Amazon Pay, Apple Pay, Google Pay, Shop Pay, manual methods and others. Three facts constrain the choice: Shopify Payments exists only in a list of countries (Spain is one of them), stores that sell subscription products need Shopify Payments as the primary gateway, and customers in Finland get no payment method preselected to comply with regulation.

Shopify Payments is the integrated processor. It needs two-step authentication on the account, accepts the major methods as soon as the store exists, and charges no third-party transaction fee on orders processed through Shopify Payments, Shop Pay and Shop Pay Installments or on manual methods such as cash on delivery and bank transfer; PayPal is exempt from the fee when Shopify Payments is the primary provider. It offers test mode, payouts with a schedule, a store currency setting for display and payout currencies, and "managed payment methods", which activate local methods by region (for example Bancontact for Belgium or BLIK for Poland) and personalize their order at checkout; that feature requires Shopify Network Intelligence to be activated in the customer privacy settings.

Source: Shopify Help Center: Shopify Payments

A third-party provider is either direct (the buyer pays on the store) or external (the buyer pays on a page hosted elsewhere). More than 100 card providers are available, and a provider can be the only card processor or can run alongside Shopify Payments. Third-party transaction fees apply to every transaction processed through third-party and alternate gateways, even when Shopify Payments is activated. Using Shopify Payments next to one direct third-party provider is available on request: the provider remains the primary processor for cards, Shopify Payments handles Shop Pay and local payment methods that the provider does not offer and can recover failed card payments. Wallets are routed to the provider that offers them, and the recovery applies only to credit and debit cards (not to wallets, local methods or recurring subscription charges). Fees there are the third-party fee for the provider, the standard Shopify Payments rate plus a 1.25 percent premium for Shopify Payments transactions and the same for recovered payments; Shopify Capital eligibility counts both providers, Shopify Protect covers only Shopify Payments transactions, and multi-entity stores can use only Shopify Payments as a direct provider. The feature is in early access for Plus stores with a contract.

Source: Shopify Help Center: Using Shopify Payments with a third-party provider

Manual payment methods (cash on delivery, bank deposit, money order, custom) create unpaid orders that the merchant marks as paid after receiving the money; there are no transaction fees. Custom manual methods have a name, additional details and payment instructions; the names Bank Deposit, Cash, Cash on Delivery (COD), custom, External Credit, External Debit, Gift Card, Money Order and Store Credit are reserved. In the API orderMarkAsPaid (scope write_orders and the mark_orders_as_paid permission) performs the same action.

Source: Shopify Help Center: Manual payment methods

The pricing page is localized by IP address; the EUR figures below are what it showed when fetched from Spain on 2026-10-27 and should be verified in the shop’s own admin before being used for decisions.

Source: Shopify: Pricing

Klarna was listed at 4.99% plus 0.35 EUR (3.99% on Plus), and iDEAL and Bancontact at 2.4, 2.1, 1.8 and 1.5 percent plus 0.25 EUR across the four plans. Shopify’s variable platform fee for Plus stores with standard setups is not published as a percentage.

A card payment is authorized (checked and held) and then captured (charged) within the provider’s authorization period. The store setting in Settings, Payments, Payment capture chooses when:

Capture settings apply to online store orders only, not to POS. Providers that do not support manual capture capture automatically, and combining a Shopify capture setting with an app that also captures can conflict. The Admin API reads the same state in Order.transactions (kind, status, gateway, manuallyCapturable, authorizationExpiresAt) and captures with orderCapture, which takes the order id, the parent authorization transaction id, the amount, the currency and finalCapture.

Source: Admin GraphQL API: orderCapture

orderCapture needs write_orders (or the marketplace or buyer membership variants) and the user permission to capture payments for orders. Other operations on the same transactions are transactionVoid and the refund mutations. Chargebacks on Shopify Payments are deducted from the next payout and Shopify is not liable for them; the Admin API reads disputes and payouts with shopifyPaymentsAccount.

Source: Shopify Help Center: Payment authorization and capture

Source: Admin GraphQL API: shopifyPaymentsAccount

This read-only query returns, in one request, the shop’s currency settings, the checkout-relevant tax flags, whether the shop is on market-driven shipping, the supported digital wallets, and the Shopify Payments account state, payout interval (DAILY, WEEKLY, MONTHLY or MANUAL) and balances. shopifyPaymentsAccount returns nothing useful for a store that does not use Shopify Payments.

Third-party gateways that integrate with Shopify checkout are payments extensions built on the Payments Platform. They can be built only by approved Payments Partners (custom payments extensions are limited to eligible Plus merchants), and a public listing requires meeting the published criteria. The five types are:

The supported operations are charge, refund, authorize, capture and void, and the methods include cards, buy now pay later and installments, bank transfers, cryptocurrency, cash and ATM and wallets (with limitations). The lifecycle: a merchant installs the app, configures it, the app marks itself ready through the Payments Apps API, the merchant activates it and deactivates the legacy gateway to avoid duplicates. The Payments Apps API endpoint is https://{shop_domain}/payments_apps/api/2026-10/graphql.json, requires an approved partner and resolves, pends or rejects payment sessions and rejects or resolves captures, refunds and voids. The scopes write_payment_gateways and write_payment_sessions are granted automatically through the extension and are omitted from the first deployment of shopify.app.toml.

An offsite extension descriptor for Pocket Coffee (placeholder URLs on a reserved domain), validated with shopify app build:

Source: Shopify developer docs: Extensions for payments

The build accepted this descriptor, and changing supports_3ds to the string "yes" made shopify app build fail with Validation error ... Invalid input, so the offline build checks the types of the fields. It does not check that the payment session URLs work, that Shopify has approved the partner or that the provider can process a payment; none of that was exercised.

A Payment Customization Function changes the methods shown in checkout: hide, rename, reorder, set payment terms and, for B2B, add a review requirement. The target is cart.payment-methods.transform.run. The documented limits are: at most 25 active payment customization functions per store; the function input always lists all payment methods, but operations on restricted methods have no effect; hiding by placement (the Express section versus the payment section) works only on Plus and elsewhere the whole method is hidden; wallets and the native gift card field cannot be renamed (names that are logos, such as Shop Pay, Apple Pay and Google Pay), wallets can be removed from the Express section but not reordered; Point of Sale does not run payment customizations; in Shop Pay they apply only to the native gift card field; payment terms apply to the single order, exist only on Plus, cannot be set on accelerated checkouts, and a D2C checkout with payment terms shows only deferred options. In the United States and Canada, stores below Plus can customize only non-card methods.

The Pocket Coffee rule: hide the cash on delivery method when the cart total is above a limit stored in a metafield (100 EUR by default). Payment method ids are opaque, so the function matches by name.

Source: Shopify developer docs: About functions in payments

Source: Shopify developer docs: About functions in payments

For a 149.50 EUR cart and a limit of 100 the function output hides the cash on delivery method (211,350 instructions; the Wasm module is 2,042 bytes):

Source: Shopify CLI: app function run

For a 32.70 EUR cart with no configuration metafield the output is {"operations": []} (158,468 instructions). Both runs used shopify app function run --export cart-payment-methods-transform-run and no store. The function is registered with paymentCustomizationCreate (scope write_payment_customizations), and merchants activate it under Settings, Payments, Payment customizations. The PaymentCustomizationInput fields are functionHandle, title, enabled and metafields.

Source: Admin GraphQL API: paymentCustomizationCreate

There is no real-money test on a development store: dev stores are always password protected, cannot be transferred and do not support real transactions, so tests use one of three gateways.

Test orders and simulated transactions do not appear in payouts or reports. Customers cannot place live orders while a payment provider is in test mode, and shipping labels bought for test orders are charged, so test orders must not be fulfilled. B2B tests need customer accounts and a test company with a location.

Source: Shopify Help Center: Activating a payment gateway in test mode

Source: Shopify Help Center: Testing Shopify Payments

Checkout settings live under Settings, Checkout and take up to 30 seconds to appear in the checkout. The main groups are:

Source: Shopify Help Center: Editing the checkout form options

Source: Shopify Help Center: Setting up tipping options for online orders

Source: Shopify Help Center: Set up address collection preferences

Source: Shopify Help Center: Set up order processing and archiving

Appearance and apps are edited in the checkout and accounts editor (Settings, Checkout, Configurations), separate from the theme editor. It sets branding for checkout, Thank you and Order status, customer accounts pages and sign-in, installs apps and switches the layout between one-page checkout (the default) and three-page checkout. Customizations survive a layout switch, although the header differs and a background image may need to become a color. Configurations can be active or draft, and checkout and accounts pages can be adapted per market, which requires the Advanced or Plus plan. Apps that customize the Thank you and Order status pages and all customer accounts pages work on every paid plan, whereas apps for the information, shipping and payment steps and access to the Checkout Branding API are Plus only. On the Thank you and Order status pages checkout.liquid and additional scripts were sunset on 2025-08-28 and script tags on those pages ended on 2025-08-28 for Plus and 2026-08-26 for the other plans; checkout.liquid is unsupported on the information, shipping and payment steps; Shopify Scripts stopped executing on 2026-06-30.

The Admin API for branding and configuration is checkoutAndAccountsConfigurations and checkoutAndAccountsConfigurationUpdate. It requires write_checkout_and_accounts_configurations (or the approval-gated write_checkout_settings), the user permission manage_checkout_settings, access to the editor, and for overrides the Markets permissions. The older checkoutBrandingUpsert, checkoutBranding, checkoutProfile and checkoutProfiles operations are deprecated in the 2026-10 schema in favor of the new ones.

Source: Admin GraphQL API: checkoutAndAccountsConfigurations

Source: Admin GraphQL API: checkoutAndAccountsConfigurationUpdate

Both documents were validated against the 2026-10 schema; the update sets the three corner radius tokens and centers the checkout header with a divider. The changelog also lists a unified branding Checkout and Accounts Configuration API (2026-05-13). The deep treatment of UI extensions, Functions and the checkout.liquid sunset is in the checkout extensibility page of this subsection.

A cart permalink builds a checkout from a URL: the store domain, /cart/, then one or more variant_id:quantity pairs separated by commas, followed by optional query parameters for line item properties, pre-filled checkout fields, a sales channel attribution, discounts, tracking, the locale, payment=shop_pay for a Shop Pay checkout, and storefront=true to land on the cart page instead of the checkout. The same link creates a new checkout for each customer. For Pocket Coffee (the domain and variant ids are placeholders):

Source: Shopify Help Center: Cart permalinks

Bot protection (Plus, activated through Plus support) is a fairness control for flash sales: it can protect up to 500 individual products or all products of the Online Store channel (not collections), one event at a time for at most 60 minutes, with a reCAPTCHA or hCaptcha challenge, and an active event cannot be edited, only deactivated. It does not address payment fraud. Fraud analysis on orders, chargeback monitoring programs and the add-to-cart limit are the other checkout-side safeguards.

Source: Shopify Help Center: Protecting your store from selling to bots