# Move your integration to boltapp.com > Bolt is moving its services from bolt.com to boltapp.com. Review the breaking changes, then upgrade your cart platform plugin and update anything on your side that names a bolt.com host. Source: https://help.boltapp.com/platforms/boltapp-domain-migration {/* AUTHOR NOTES (not rendered). Evidence gathered 2026-09-18 from the plugin repositories and the Bolt backend. Except for Adobe Commerce 3.0.0 and the SFCC targets (managed 26.6.0, embedded 23.6.1), the version numbers in each platform's "Plugin versions in use and their boltapp.com patch" table are PLACEHOLDERS (WooCommerce 2.23.0). Replace them with the confirmed releases, then delete this block. - Adobe Commerce / Magento 2: 3.0.0 released 2026-09-22 (bolt-magento2 #2002, tag 3.0.0, on Packagist) is the first release with boltapp.com hosts. CONFIRMED, not a placeholder. Merchant guidance (per product owner 2026-09-22): Git patch ONLY, no Composer path on the page. The 13 versions in the table are the versions live in production over the 90 days to 2026-09-22 (M2 fleet readiness data, 95 divisions). Patch files verified on origin/master at patches/boltapp-domains/bolt-magento2--boltapp-domains.patch for all 13 versions (README there also documents dev-boltapp-domains/ Composer branches, intentionally not shown to merchants). The new csp_whitelist.xml ships both bolt.com and boltapp.com hosts. Integration endpoint (etc/integration/config.xml) also moved to boltapp.com, so the Magento integration may need re-authorizing. - WooCommerce: wordpress.org "Bolt Checkout for WooCommerce" is 2.22.1, updated 2026-07-23. Not yet verified that 2.22.1 contains the boltapp.com hosts. BLOCKED until confirmed. - SFCC managed (bolt-demandware-managed): target per product owner (2026-09-22) is 26.6.0, tag bolt-sfcc-managed-26.6.0. As of that date the tag is NOT yet published; latest published tag is bolt-sfcc-managed-25.1.0 and the boltapp.com work sits on branch ISS-23491-ntapaswi-bolt_domain_update. Confirm the tag exists before publishing. - SFCC embedded (bolt-demandware-embedded): target per product owner (2026-09-22) is 23.6.1, tag release-23.6.1. As of that date the tag is NOT yet published; latest published tag is release-23.5.1. Confirm the tag exists before publishing. - SFCC legacy (bolt-demandware, SiteGenesis + SFRA 21.4.x): boltapp.com hosts on the same unreleased branch. Deprecated repo. - BigCommerce marketplace app: Bolt-hosted. Bolt's Script Manager now installs connect.boltapp.com/track.js for new installs; existing stores keep the old script tag until Bolt re-runs the install. Bolt-side sweep required. The separate "Bolt Checkout for BigCommerce" WordPress plugin (1.0.0, 2019) is hardcoded to bolt.com and has no update. - Shopify: Bolt-hosted; theme snippet already documented with c.boltapp.com. - Datadog inventory for the per-platform "Plugin versions in use" tables (APM spans, env:production, attributes @bolt.plugin_version + @bolt.merchant.division_platform, header X-Bolt-Plugin-Version). This org retains spans for 30 days only (2026-08-19 to 2026-09-18); logs do not carry the field and the plugin_version metric tag is blocked for cardinality, so six months is not available from Datadog. Requests / merchants: magento2 2.27.8 34381/33, 2.27.7 1144/2, 2.27.1 310/5, 2.24.0 257/2, 2.27.3 178/1, 2.27.4 3/1, v2.2.0 23/1, v2.0.5 1/1 magento (label variant) 2.27.8 4398/5, 2.9.0 1967/1 (Magento 1 plugin) woo_commerce 2.22.1 5254/10, 2.18.0 5288/2, 2.16.0 2540/2, 2.20.0 2493/1, 2.21.2.storeitcold 58/1, 2.21.1 21/2 other labels: drupal 2.27.8, shopify 2.27.4, tipser 2.22.1, netsuite v2.0.5 / v2.2.0, big_commerce v2.0.5, volusion 1.0.7 SFCC cartridges do not send the header, so they never appear; their rows come from cartridge releases. The WooCommerce "Patch release with boltapp.com" column is PLACEHOLDER data (2.22.2, 2.21.3). - PR #1935 review (SanthoshCharanBolt, approved 2026-09-22) addressed here: dual iss acceptance (SSOHelper accepts bolt.com, api.bolt.com, boltapp.com, api.boltapp.com); processor webhook URL row; Google Pay console origin; Magento 1 warning; /v1/merchant auth nit reworded to avoid naming a header. NOT addressed: the screenshot comment on the "Remove custom URL overrides" step (github.com/user-attachments/assets/4e37f5ac-20fe-4449-bbd9-566b262afb94 is not fetchable without a browser session) and the note that X-Bolt-Source-Version reaches a few merchants (storm to hail internal header, not merchant-facing). Ask the reviewer about both. Evidence for the custom-override wording: etc/adminhtml/system.xml sets showInDefault/Website/Store = 0 on custom_api, custom_merchant_dash, custom_cdn, custom_account in 2.27.8 and on master; view/adminhtml/web/js/validation.js still tests /bolt\.me$/ while Helper/Config.php::validateCustomUrl was widened to bolt(app)?\.(me|com). - Magento 1: BoltApp/bolt-magento1 last pushed 2023-07-13, last tag 2.10.0, zero boltapp.com references. Datadog still sees one Magento 1 store on plugin 2.9.0. - Backend facts: bolt.com and boltapp.com are dual-served with no published sunset date. Merchant callback URLs are unaffected. Outbound User-Agent on Bolt calls changed to "Bolt - https://www.boltapp.com" on 2026-07-21. SSO / OpenID issuer stays https://api.bolt.com on purpose. Bolt's egress IP allowlist is unchanged. */} ## Overview [#overview] Bolt is moving its services from `bolt.com` to `boltapp.com`. Every Bolt host your store talks to gets a `boltapp.com` twin: `api.boltapp.com`, `connect.boltapp.com`, `account.boltapp.com`, and `merchant.boltapp.com`, with the same `-sandbox` variants as before. The [Environments](/api-reference/environments) page lists the current sandbox and production URLs. During the transition both domains serve traffic, so nothing breaks the day you read this. When Bolt retires `bolt.com`, anything still pointing at the old hosts stops working. Older Bolt plugins have the `bolt.com` hosts built in, so the fix for most stores is a plugin upgrade. We have not announced the date `bolt.com` stops serving. Upgrade now to the version listed for your platform under [Choose your platform](#choose-your-platform) so your store is ready when it is. ## What is changing [#what-is-changing] | Area | Before | After | What breaks if you do nothing | | -------------------------------------------------- | ----------------------------------------------------- | ---------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------- | | Bolt API your plugin calls | `api.bolt.com`, `api-sandbox.bolt.com` | `api.boltapp.com`, `api-sandbox.boltapp.com` | Order creation, authorization, refunds, and every other server call from the plugin fail once `bolt.com` is retired. | | Checkout scripts on your storefront | `connect.bolt.com/track.js`, `connect.js`, `embed.js` | `connect.boltapp.com/...` | The Bolt button and checkout modal stop loading. | | Shopper accounts | `account.bolt.com` | `account.boltapp.com` | Shopper login, one-click checkout, and SSO Commerce stop working. | | Merchant Dashboard | `merchant.bolt.com` | [merchant.boltapp.com](https://merchant.boltapp.com) | Bookmarks and links in older plugin admin screens stop resolving. | | Emails from Bolt | `@bolt.com` senders | `@boltapp.com` senders | Mail rules that only allow `@bolt.com` drop Bolt notifications. | | User-Agent on calls Bolt makes to your store | `Bolt - https://www.bolt.com` | `Bolt - https://www.boltapp.com` | Firewall or bot rules that match the old string block Bolt's webhook and shipping calls. | | Webhook URL you registered in your payment gateway | Bolt webhook URL on a `bolt.com` host | The same URL on a `boltapp.com` host | Bolt stops receiving transaction updates from your processor. | ## What is not changing [#what-is-not-changing] * **Your API keys, signing secret, and publishable keys.** Upgrading does not change your credentials. Keep the same values in the plugin. * **Your callback URLs.** The webhook, shipping, tax, and create-order URLs under **Administration > API > Merchant Callbacks** are on your domain, so they stay as they are. * **Bolt's outbound IP addresses.** If you allowlist Bolt's IPs for callbacks or a payment processor, that list is the same. See the processor setup pages under [Payment processors](/integrations/payment-processors). * **Your SSO signing keys, audience, and shopper claims.** Only the `iss` claim varies by domain, and code that validates it needs to accept both. See [Changes that affect every store](#changes-that-affect-every-store). * **Your Trusted Domains.** The storefront domains you registered with Bolt are your own domains and need no change. ## Changes that affect every store [#changes-that-affect-every-store] Work through these regardless of platform. Do them before the plugin upgrade so the new hosts are reachable the moment the plugin switches. If your storefront sends a `Content-Security-Policy` header, you must add the `boltapp.com` hosts next to the existing `bolt.com` entries. A policy that only names `bolt.com` blocks the upgraded plugin's scripts and API calls. Keep both domains until Bolt confirms `bolt.com` is retired. | Directive | Add | | ------------- | ---------------------------------------------------------------------------------------------------------- | | `script-src` | `connect.boltapp.com`, `connect-sandbox.boltapp.com`, `account.boltapp.com`, `account-sandbox.boltapp.com` | | `frame-src` | `connect.boltapp.com`, `connect-sandbox.boltapp.com`, `account.boltapp.com`, `account-sandbox.boltapp.com` | | `connect-src` | `api.boltapp.com`, `api-sandbox.boltapp.com`, `connect.boltapp.com`, `connect-sandbox.boltapp.com` | | `img-src` | `img.boltapp.com`, `img-sandbox.boltapp.com`, `assets.boltapp.com` | A wildcard `*.boltapp.com` entry in each directive is a simpler alternative and is what Bolt's Salesforce Composable guide uses. **Expected result:** the browser console shows no CSP violations for `boltapp.com` after the plugin upgrade. If your servers restrict outbound HTTPS, allow `api.boltapp.com` and `api-sandbox.boltapp.com` alongside the current `api.bolt.com` hosts. **Expected result:** `curl -I https://api.boltapp.com` from your web server returns an HTTP response instead of a timeout. If a WAF or bot rule identifies Bolt by its User-Agent, match on `Bolt - https://www.boltapp.com` as well as the old value. Bolt's IP addresses have not changed, so IP-based rules need no edit. **Expected result:** the webhook and shipping calls Bolt makes to your store keep returning 2xx in your server logs. If your code checks the `iss` claim on Bolt SSO or OpenID Connect tokens, accept all four values for as long as both domains serve traffic: ```text title="Accepted iss values" https://bolt.com https://api.bolt.com https://boltapp.com https://api.boltapp.com ``` Bolt's own plugins do this; the Magento 2 patch widens the check the same way. Apply the same rule to any regular expression or allowlist that matches Bolt URLs so a `boltapp.com` host is not rejected. **Expected result:** a shopper signs in with Bolt and your code accepts the token no matter which domain issued it. If you registered a Bolt webhook URL in your payment processor's dashboard, that URL is a Bolt host and it moves with the migration. Open **Settings > Payments > Manage** your processor in the [Merchant Dashboard](https://merchant.boltapp.com), copy the webhook URL shown there, and paste it into your processor's webhook configuration. The setup page for your processor under [Payment processors](/integrations/payment-processors) shows where each one keeps that setting. **Expected result:** a test event from your processor reaches Bolt, and the transaction status updates in the Merchant Dashboard. This applies only if you registered your own Google Pay merchant ID rather than using Bolt's. The Google Pay console lists the websites allowed to show the Google Pay button, and checkout served from `connect.boltapp.com` is a different origin from `connect.bolt.com`. Add `connect.boltapp.com` to your integration in the [Google Pay and Wallet Console](https://pay.google.com/business/console), and keep the existing `connect.bolt.com` entry until Bolt retires it. **Expected result:** the Google Pay button renders in Bolt checkout served from `connect.boltapp.com`. Allow `@boltapp.com` senders in any mail rule that currently allows only `@bolt.com`. Update saved links to the Merchant Dashboard to [merchant.boltapp.com](https://merchant.boltapp.com) and [merchant-sandbox.boltapp.com](https://merchant-sandbox.boltapp.com). ## Choose your platform [#choose-your-platform] Work through [Changes that affect every store](#changes-that-affect-every-store) first. Then follow the section for your platform. Each one lists the versions in use, what carries `boltapp.com`, and the steps to get there. * [Adobe Commerce and Magento 2](#adobe-commerce-and-magento-2) * [BigCommerce](#bigcommerce) * [Salesforce Commerce Cloud](#salesforce-commerce-cloud) * [WooCommerce](#woocommerce) * [Shopify](#shopify) * [SAP Commerce Cloud, Solidus, and Volusion](#sap-commerce-cloud-solidus-and-volusion) * [Direct API and custom carts](#direct-api-and-custom-carts) ### Adobe Commerce and Magento 2 [#adobe-commerce-and-magento-2] The `boltpay/bolt-magento2` plugin has the Bolt hosts compiled into `Helper/Config.php`. Every release up to and including 2.27.8 points at `bolt.com`. Version 3.0.0 and later already point at `boltapp.com` and need no change. For every earlier version, Bolt publishes a Git patch in the [patches/boltapp-domains](https://github.com/BoltApp/bolt-magento2/tree/master/patches/boltapp-domains) folder of the plugin repository. Each patch applies to exactly one plugin version, changes only the Bolt hosts, and leaves your customizations in place. The patch adds the `boltapp.com` hosts to `csp_whitelist.xml` next to the existing `bolt.com` entries and accepts SSO tokens from both domains, so the plugin keeps working on either domain during the transition. **Plugin versions in use and their boltapp.com patch** Find the version you run today, then use the patch file listed next to it. A patch only applies to its own version; applying the wrong one fails rather than half-applying. | Version in use | Patch file | | -------------- | -------------------------------------------- | | 2.27.8 | `bolt-magento2-2.27.8-boltapp-domains.patch` | | 2.27.7 | `bolt-magento2-2.27.7-boltapp-domains.patch` | | 2.27.5 | `bolt-magento2-2.27.5-boltapp-domains.patch` | | 2.27.4 | `bolt-magento2-2.27.4-boltapp-domains.patch` | | 2.27.3 | `bolt-magento2-2.27.3-boltapp-domains.patch` | | 2.27.2 | `bolt-magento2-2.27.2-boltapp-domains.patch` | | 2.27.1 | `bolt-magento2-2.27.1-boltapp-domains.patch` | | 2.26.4 | `bolt-magento2-2.26.4-boltapp-domains.patch` | | 2.26.1 | `bolt-magento2-2.26.1-boltapp-domains.patch` | | 2.25.2 | `bolt-magento2-2.25.2-boltapp-domains.patch` | | 2.24.1 | `bolt-magento2-2.24.1-boltapp-domains.patch` | | 2.24.0 | `bolt-magento2-2.24.0-boltapp-domains.patch` | | 2.13.0 | `bolt-magento2-2.13.0-boltapp-domains.patch` | If your version is not in the table, upgrade to 3.0.0. From your Magento root: ```bash title="Terminal" composer show boltpay/bolt-magento2 | grep versions ``` You can also read it in **Stores > Configuration > Sales > Payment Methods > Bolt Pay**. If you installed the plugin manually under `app/code/Bolt/Boltpay`, read the version from `composer.json` in that folder. Clone the plugin repository, or download the single file you need. Replace `VERSION` with the version from the previous step: ```bash title="Terminal" curl -fLO https://raw.githubusercontent.com/BoltApp/bolt-magento2/master/patches/boltapp-domains/bolt-magento2-VERSION-boltapp-domains.patch ``` **Expected result:** the `.patch` file is in your working directory and its first lines name your plugin version. Go to the root of your installed copy of the plugin, dry run the patch, then apply it: ```bash title="Terminal" # Composer installs: vendor/boltpay/bolt-magento2 # Manual installs: app/code/Bolt/Boltpay cd /path/to/magento/vendor/boltpay/bolt-magento2 git apply --check /path/to/bolt-magento2-VERSION-boltapp-domains.patch git apply /path/to/bolt-magento2-VERSION-boltapp-domains.patch ``` `git apply` works even when the plugin directory is not a Git repository. Without Git, use `patch -p1 < FILE` instead. If the dry run reports a conflict, a customization overlaps the host constants; resolve it by hand in `Helper/Config.php` using the patch as a guide. **Expected result:** the dry run prints nothing, and `Helper/Config.php` names `api.boltapp.com` after the patch. From your Magento root: ```bash title="Terminal" php bin/magento setup:upgrade php bin/magento setup:di:compile php bin/magento setup:static-content:deploy php bin/magento cache:clean php bin/magento cache:flush ``` **Expected result:** the storefront renders the Bolt button, and the browser network tab shows calls to `connect.boltapp.com`. If Composer installed the plugin, the next `composer install` or `composer update` replaces everything under `vendor/` and removes the patch. Add [cweagans/composer-patches](https://github.com/cweagans/composer-patches) to your project and declare the patch file under `extra.patches` in your root `composer.json` so it is reapplied on every install. If the plugin lives under `app/code/Bolt/Boltpay`, commit the patched files to your own repository. The patch points the Magento integration record at `api.boltapp.com`. Open **Stores > Configuration > Sales > Payment Methods > Bolt Pay > Advanced Options** and choose **Create and send API keys to Bolt** again so Magento re-authorizes the connection. **Expected result:** the integration under **System > Integrations** shows **Active**, and a sandbox test order syncs back to Magento. If a developer previously set `payment/boltpay/custom_api`, `custom_cdn`, `custom_account`, or `custom_merchant_dash` to a `bolt.com` host, clear them or point them at the `boltapp.com` equivalent: ```bash title="Terminal" php bin/magento config:show payment/boltpay/custom_api php bin/magento config:set payment/boltpay/custom_api "" ``` Most stores never set these, and the admin form hides the fields, so read them from the command line rather than looking for them in the UI. Note that the admin form's own validation still only accepts `bolt.me` URLs, so set any replacement value with `bin/magento config:set` instead of typing it into the admin. Place a sandbox order with a [test card](/getting-started/test-cards) and confirm it appears in the sandbox Merchant Dashboard. Then apply the same patch in production during a low-traffic window and place a low-value live order. If you maintain your own `csp_whitelist.xml`, add the `boltapp.com` hosts from the table above. The patched plugin policy already includes both domains. The [Adobe Commerce setup guide](/platforms/adobe) covers the full configuration if you need to reinstall. **Magento 1 is not covered.** The separate `bolt-magento1` plugin ended at 2.10.0 and is no longer maintained, so there is no `boltapp.com` release and no patch for it. If your store still runs Bolt on Magento 1, [contact Bolt support](/support) before the cutover to plan a move to a supported platform. ### BigCommerce [#bigcommerce] Bolt runs the BigCommerce app itself, so there is no plugin package to upgrade. Two things on your side can still reference `bolt.com`. **Plugin versions in use and their boltapp.com patch** Bolt hosts the BigCommerce app, so there is no plugin version to track. The only versioned Bolt code on your side is the script tags in your theme. | Component | Version | Action | | ---------------------------------------------- | ------------------------------- | ----------------------------------------------- | | Bolt app (BigCommerce App Marketplace) | Always current, managed by Bolt | None. | | Theme script tags (`connect-bigcommerce.js`) | Whatever your theme references | Point them at `connect.boltapp.com`, see below. | | Bolt Checkout for BigCommerce WordPress plugin | 1.0.0 | No update exists. Contact Bolt. | Bolt installs `track.js` into your store through the BigCommerce Script Manager. New installs already point at `connect.boltapp.com`. Stores installed before the migration keep the old script until Bolt re-installs it. Bolt runs this update for all stores; you do not need to act, but you can confirm the host under **Storefront > Script Manager**. **Expected result:** the Bolt script entry in Script Manager references `connect.boltapp.com`. If you followed the [BigCommerce installation guide](/platforms/bigcommerce-full) and pasted a `connect-bigcommerce.js` tag into your Cornerstone theme files, open **Storefront > My Themes > Advanced > Edit Theme Files** and change any `src` that reads `connect.bolt.com` or `connect-sandbox.bolt.com` to the `boltapp.com` host: ```html title="Theme template" ``` Leave `track.js` alone. Bolt installs and updates that tag through Script Manager, as described in the previous step. Check `cart.html`, `product.html`, the mini-cart template, and the **Footer Scripts** section. **Expected result:** the Bolt button renders on the cart page and the browser's network tab shows the scripts loading from `connect.boltapp.com`. If you run BigCommerce on WordPress with the **Bolt Checkout for BigCommerce** WordPress plugin, that plugin is version 1.0.0 from 2019 and has `bolt.com` built in with no update available. [Contact Bolt support](/support) before the cutover to plan a replacement. ### Salesforce Commerce Cloud [#salesforce-commerce-cloud] Every Bolt cartridge has the hosts compiled into cartridge code. Site preferences only select the environment, and the `bolt.http` service has no URL in its credential, so the only way to move a Salesforce Commerce Cloud (SFCC) storefront is to deploy an updated cartridge. Metadata imports and service definitions do not need to change. **Plugin versions in use and their boltapp.com patch** The cartridges do not report their version to Bolt, so these rows come from the cartridge releases rather than from traffic. Read the version from `package.json` in the cartridge or from **Administration > Site Development > Code Deployment**. | Integration | Repository | Release line in use | Version with boltapp.com | Release tag | Action | | ------------------------------- | -------------------------- | ------------------- | ------------------------ | -------------------------- | ------------------------------------------------------------- | | SFRA V2 (managed checkout) | `bolt-demandware-managed` | 25.1.x and older | 26.6.0 | `bolt-sfcc-managed-26.6.0` | Deploy 26.6.0. | | Embeddable Checkout | `bolt-demandware-embedded` | 23.5.x and older | 23.6.1 | `release-23.6.1` | Deploy 23.6.1. | | Legacy SiteGenesis or SFRA 21.x | `bolt-demandware` | 21.4.x | None planned | Move to SFRA V2 | This repository is deprecated. Contact Bolt to plan the move. | Fetch the tags from the repository for your integration, check out the release tag from the table, install dependencies, and build. Do not pull the head of the default branch; it may contain unreleased changes. For managed checkout (`bolt-demandware-managed`): ```bash title="Terminal" git clone https://github.com/BoltApp/bolt-demandware-managed.git cd bolt-demandware-managed git fetch --tags git checkout bolt-sfcc-managed-26.6.0 npm install npm run build ``` For Embeddable Checkout (`bolt-demandware-embedded`): ```bash title="Terminal" git clone https://github.com/BoltApp/bolt-demandware-embedded.git cd bolt-demandware-embedded git fetch --tags git checkout release-23.6.1 npm install npm run build ``` If you already have a clone, skip the `git clone` and `cd` lines and run the rest from the repository root. If you carry custom changes on top of the Bolt cartridge, create a branch from the release tag and reapply your changes there. **Expected result:** `git describe --tags` prints the release tag, the build completes, and the cartridge folders contain the compiled client scripts. Point `dw.json` at your sandbox, upload, then activate the new code version in **Administration > Site Development > Code Deployment**: ```bash title="Terminal" npm run upload:all ``` If you upload under a new code version name, re-import the Bolt metadata and re-add the cartridges to the cartridge path as described in the [SFCC setup guide](/platforms/salesforce). **Expected result:** **Administration > Operations > Service Status** shows `bolt.http` healthy and the Bolt button renders on the cart page. Script tags are rendered into cached pages, so a storefront can keep serving the old `connect.bolt.com` tag after activation. Invalidate the page cache under **Administration > Sites > Manage Sites > your site > Cache**. **Expected result:** view-source on the cart page shows `connect.boltapp.com` in the Bolt script tags. For a Composable Storefront, update the `helmet` directives in `app/ssr.js` so every directive that lists `*.bolt.com` also lists `*.boltapp.com`, as shown in the [Composable Storefront guide](/platforms/salesforce/sfcc-sfra-v2/sfcc-composable/). For an SFRA storefront, update any CSP configured at your CDN or in `httpHeadersConf.json`. Deploy the same code version through your normal release process, activate it, invalidate the cache, and place a low-value order. ### WooCommerce [#woocommerce] The **Bolt Checkout for WooCommerce** plugin is distributed through the WordPress plugin directory. Upgrading to 2.23.0 or newer is the whole fix, with one caveat for the companion extension plugin. **Plugin versions in use and their boltapp.com patch** Bolt saw these release lines calling its production API between 2026-08-19 and 2026-09-18. Find the line you run today, then install either its patch release or the minimum version. Check your version under **WP Admin > Plugins**. | Release line in use | Patch release with boltapp.com | Minimum version | Action | | ------------------- | ------------------------------ | --------------- | ------------------------------------ | | 2.22.x | 2.22.2 | 2.23.0 | Upgrade to 2.22.2 or move to 2.23.0. | | 2.21.x | 2.21.3 | 2.23.0 | Upgrade to 2.21.3 or move to 2.23.0. | | 2.20.x and older | None planned | 2.23.0 | Move to 2.23.0. | In **WP Admin > Plugins**, find **Bolt Checkout for WooCommerce** and note the version. Anything below 2.23.0 needs the update. The current release is listed on the plugin's directory page at [wordpress.org](https://wordpress.org/plugins/bolt-checkout-woocommerce/). In **WP Admin > Dashboard > Updates**, select **Bolt Checkout for WooCommerce** and choose **Update Plugins**. If your host disables updates, download the current release from the plugin directory and install it under **Plugins > Add New > Upload Plugin**. **Expected result:** the plugin row shows the new version, and Bolt still appears as a payment gateway under **WooCommerce > Settings > Payments**. If your store also runs a **WooCommerce Bolt Checkout Extensions** plugin built for your store, install the matching new build. Running a new core plugin with an old extension plugin breaks checkout features. Delete the old extension plugin, install the new one, and activate it. Toggle **Bolt Sandbox Mode** on, place an order with a [test card](/getting-started/test-cards), then turn sandbox mode off and repeat the update on production. ### Shopify [#shopify] Bolt hosts the Shopify integration, so there is no app package to upgrade. Check the snippet you pasted into your theme. **Plugin versions in use and their boltapp.com patch** Bolt hosts the Shopify integration, so there is no plugin version to track. | Component | Version | Action | | -------------------------------------- | ------------------------------- | ------------------------------------------------- | | Bolt Checkout Everywhere app | Always current, managed by Bolt | None. | | Theme snippet in `layout/theme.liquid` | Whatever your theme references | Confirm it loads from `c.boltapp.com`, see below. | Open `layout/theme.liquid` and find the Bolt `` and ` ``` If either still reads `bolt.com`, change it to `boltapp.com`. **Expected result:** the Bolt button renders and opens checkout on a `.c.boltapp.com` host. ### SAP Commerce Cloud, Solidus, and Volusion [#sap-commerce-cloud-solidus-and-volusion] These integrations are delivered by your Bolt customer success manager rather than through a public package registry. **Plugin versions in use and their boltapp.com patch** These integrations are not published to a package registry, so Bolt does not track a release line for them. | Platform | Release line in use | Patch release with boltapp.com | Action | | ------------------ | --------------------------- | ------------------------------ | ---------------------------------------------------------- | | SAP Commerce Cloud | Build delivered by Bolt | Next build from Bolt | Request the current `boltbackoffice` and `boltocc` build. | | Solidus | Bolt gems in your `Gemfile` | Next gem release | Update the gems and run `bundle update`. | | Volusion | Files in `vspfiles` | Next file set from Bolt | Request the current plugin files and edit the script tags. | * **SAP Commerce Cloud (hybris):** request the current `boltbackoffice` and `boltocc` extension build from Bolt, deploy it through your normal hybris release process, and update any `bolt.com` host in your Spartacus environment configuration. See [Set up Bolt on SAP Commerce Cloud](/platforms/sap). * **Solidus:** update the Bolt gems in your `Gemfile` to the current release and run `bundle update`, then check any initializer that sets a Bolt API host. See [Set up Bolt on Solidus](/platforms/solidus). * **Volusion:** the plugin lives in your store's `vspfiles` folder and the script tags are in your template. Request the current plugin files from Bolt, upload them over sFTP, and edit the `track.js` and `connect.js` tags in your template so they load from `connect.boltapp.com` or `connect-sandbox.boltapp.com`. See [Set up Bolt on Volusion](/platforms/volusion). ### Direct API and custom carts [#direct-api-and-custom-carts] If you call the Bolt API directly, you control every host, so no plugin upgrade applies. **Plugin versions in use and their boltapp.com patch** Not applicable. You call the Bolt API directly, so there is no Bolt plugin or release line on your side. The hosts you need to change are listed in the steps below. Set your API base URL to `https://api.boltapp.com` for production and `https://api-sandbox.boltapp.com` for sandbox. If you use the environment variable pattern from the [Environments](/api-reference/environments) page, update `BOLT_API_BASE_URL`. **Expected result:** a call your integration already makes, such as creating an order token, succeeds against the new host and returns the same data as before. Update the `track.js` and `connect.js` tags described in the [Direct API guide](/platforms/direct-api) so they load from `connect.boltapp.com` or `connect-sandbox.boltapp.com`. If you verify Bolt SSO or OpenID Connect tokens, accept the `iss` values for both domains as listed in [Changes that affect every store](#changes-that-affect-every-store). Fetch signing keys from the discovery document on your API base URL rather than a hardcoded JWKS URL so they follow the host change automatically. ## Verify the migration [#verify-the-migration] After upgrading, confirm each of these on your live store: 1. The browser's network tab shows Bolt scripts loading from `connect.boltapp.com`, with no CSP errors in the console. 2. A low-value order completes and appears under **Transactions** in the [Merchant Dashboard](https://merchant.boltapp.com). 3. Your server logs show the order webhook from Bolt arriving with a 2xx response. 4. A shopper can log in with a Bolt account, if you use SSO Commerce or one-click checkout. ## If something goes wrong [#if-something-goes-wrong] Roll back to the previous plugin version, then [contact Bolt support](/support) with your merchant ID, platform, and the plugin versions you moved between. Because `bolt.com` still serves traffic during the transition, rolling back restores checkout immediately.