Move your integration to boltapp.com

Allow boltapp.com in your Content Security Policy

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.

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.

Update outbound firewall rules

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.

Update inbound rules that inspect Bolt's requests

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.

Accept both bolt.com and boltapp.com where you validate Bolt tokens or URLs

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:

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.

Re-copy the Bolt webhook URL into your payment gateway

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, copy the webhook URL shown there, and paste it into your processor's webhook configuration. The setup page for your processor under 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.

Add boltapp.com to your Google Pay merchant profile

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, 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.

Update mail filters and bookmarks

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 and merchant-sandbox.boltapp.com.

Check your current version

From your Magento root:

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.

Download the patch for your version

Clone the plugin repository, or download the single file you need. Replace VERSION with the version from the previous step:

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.

Apply the patch in a staging environment first

Go to the root of your installed copy of the plugin, dry run the patch, then apply it:

# 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.

Recompile and flush caches

From your Magento root:

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.

Keep the patch from being overwritten

If Composer installed the plugin, the next composer install or composer update replaces everything under vendor/ and removes the patch. Add 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.

Reconnect the Bolt integration

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.

Remove custom URL overrides

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:

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.

Verify and repeat in production

Place a sandbox order with a test card 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.

Let Bolt refresh the tracking script

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.

Update the scripts you added to your theme

If you followed the BigCommerce installation guide 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:

<script src="https://connect.boltapp.com/connect-bigcommerce.js" ...></script>

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.

Pull the release tag and build the cartridge

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):

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):

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.

Upload to a sandbox instance and activate the code version

Point dw.json at your sandbox, upload, then activate the new code version in Administration > Site Development > Code Deployment:

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.

Expected result: Administration > Operations > Service Status shows bolt.http healthy and the Bolt button renders on the cart page.

Invalidate the page cache

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.

Update the storefront CSP

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. For an SFRA storefront, update any CSP configured at your CDN or in httpHeadersConf.json.

Repeat on staging and production

Deploy the same code version through your normal release process, activate it, invalidate the cache, and place a low-value order.

Check the installed version

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.

Update the plugin on a staging site

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.

Update the Bolt Extension plugin at the same time

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.

Verify and repeat in production

Toggle Bolt Sandbox Mode on, place an order with a test card, then turn sandbox mode off and repeat the update on production.

Check the global scripts in your theme

Open layout/theme.liquid and find the Bolt <link> and <script> tags from the Shopify installation guide. Confirm they load from c.boltapp.com and that data-checkout-link-host ends in .c.boltapp.com:

<link rel="stylesheet" href="https://c.boltapp.com/shopify/bolt-button.css">
<script
  src="https://c.boltapp.com/shopify/bolt-button.js?v="
  data-publishable-key="{PUBLISHABLE_KEY}"
  data-checkout-link-host="{HOST}.c.boltapp.com"
  data-merchant-id="{MERCHANT_ID}"
  defer="defer">
</script>

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.

Change the API base URL

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 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.

Change the script tags on your storefront

Update the track.js and connect.js tags described in the Direct API guide so they load from connect.boltapp.com or connect-sandbox.boltapp.com.

Accept the token issuer for both domains

If you verify Bolt SSO or OpenID Connect tokens, accept the iss values for both domains as listed in 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.