Changelog

All stores move to the current checkout settings page

We are beginning to move the remaining stores that still use the legacy checkout settings page to the current one. If your store uses the legacy page, you may see the current checkout settings page under Settings > Checkout over the coming weeks.

• No setup required: Stores move automatically. Your storefront checkout keeps working as before.
• Access to newer checkout features: The current page is where you turn on features such as Enhanced Checkout and B2B checkout, which the legacy page does not offer.

Failed refunds reported once

When a refund fails and can’t be completed, the control panel now reports the failure once. Before this fix, a scheduled refund status check reported the same failure again.

• Order timeline: the order no longer shows a second Refund failed event for the same failed refund.
• Dashboard notification: the refund failure notification keeps its original reason. It no longer changes to “The payment provider encountered an error when processing refund.”
• Decline message: the refund keeps its original decline message. The same replacement text no longer overwrites it.

I sell to settings in the Admin GraphQL API

You can now read and change the countries, subdivisions, and postcodes that a store sells to, for the whole store or for each storefront channel, with the Admin GraphQL API.

• store.iSellTo query: returns the global list, or one entry for each channel in context.channelIds. A channel without its own list returns data: null and uses the global list.
• iSellTo.update mutation: replaces the whole list of the global level or of each channel you pass. A list holds country codes (ISO 3166-1 alpha-2), subdivision codes for each country, and postcodes for each country.
• iSellTo.delete mutation: removes the list of each channel you pass, so the channel uses the global list again.
• Limits: one request accepts at most 15 channel IDs. Each postcode has a maximum of 20 bytes in UTF-8.
• Writes to several channels: the mutations write the channels one by one. When a write fails, the channels before it keep the change. Both mutations are idempotent, so you can send the request again.

For schema details, see the Admin GraphQL API reference:

• store.iSellTo query
• iSellTo.update mutation
• iSellTo.delete mutation
• ISellTo object

PayPal Commerce Platform order details sent to PayPal

We are beginning to roll out a fix to the order details that PayPal Commerce Platform sends to PayPal, so you may notice changes to how orders appear in PayPal over the coming weeks.

• Line items for every payment method: orders paid by card, PayPal, Pay Later, and the other PayPal Commerce Platform methods include their line items with per-item tax, as Pay Upon Invoice orders already did. Previously, some orders were sent without line items or an amount breakdown, such as orders paid partly with a gift certificate.
• Fractional-cent discounts: orders with a discount that does not divide evenly into cents, such as a percentage discount on shipping, keep their full amount breakdown instead of losing it to a one-cent rounding difference. The same applies to one-yen differences on orders in Japanese yen.
• Shipping tax shown with shipping: tax charged on shipping appears in the shipping amount instead of in the tax total.
• Prices entered with tax: on stores that enter prices with tax, line items show the price before tax, with the tax listed separately.

The amount charged to the shopper does not change.

Cascading price lists are now generally available

Cascading price lists have moved out of open beta and are now generally available to all stores.

• Layer fallback pricing: use the layers field on a price list to define up to five fallback price lists. When a price record is not found in the primary list, each layer is checked in order before resolving to the catalog price.
• Control panel: the Price list fallback panel and the Prices entered setting in the price list editor no longer show a Beta label.
• Existing endpoints: set layers on the create and update Price Lists API endpoints. No new endpoints are introduced.

For details, see the Cascading price lists guide.

Cursor pagination for best-reviewed product listings no longer skips or repeats products

Paging through a category’s or a brand’s products sorted by BEST_REVIEWED in the Storefront GraphQL API no longer skips products or repeats products from an earlier page.

• Affected queries: Category.products and Brand.products with sortBy: BEST_REVIEWED, when you page with the after or before argument.
• Cursors follow the sort order: the cursor for each product now matches the value the listing is sorted by, so the next or previous page starts where the current page ends.
• No schema changes: arguments, fields, the sort order, and the rating values in the response are unchanged.
• Restart pagination from older cursors: a cursor returned before the fix can still skip or repeat products. If your storefront stores or caches cursors for these listings, request the first page again and page forward from the new cursors.

For details, see Pagination in the GraphQL Storefront API overview, or the site query reference for schema details.

Storefront GraphQL filters on brand pages now match the brand’s products

We are beginning to roll out a fix to the product filters that storefront GraphQL returns for a brand page. You may notice changes in this area over the coming weeks.

On a store where the Brand filter is turned off in the store’s filter settings, the other filters on a brand page, such as color, size, and product attributes, used to list values and counts for the whole catalogue. The products on the page were already limited to the brand, so the filters offered options that led to no results. With the fix, those filters list only the values, and the product counts, of the products that belong to the brand.

• Values match the brand: a filter such as color lists only the values used by the brand’s products.
• Counts match the brand: the product count next to each value is calculated over the brand’s products instead of the whole catalogue.
• No change when the Brand filter is on: stores that already show the Brand filter get the same results as before.
• No change to the response: the filters keep the same fields and structure; only the values and counts they contain change.

For details, see Faceted and Textual Search with the GraphQL Storefront API.

Delete stored Orbital instruments that no longer exist at the provider

We are beginning to roll out a fix for deleting a stored Orbital payment instrument that Orbital no longer has on record. You may notice fewer failed deletions over the coming weeks.

• Deletion succeeds: when Orbital reports that the customer profile doesn’t exist or that the customer reference number is invalid, BigCommerce removes the stored instrument instead of returning an error.
• Clearer errors: when Orbital returns an error for a customer profile request without a message, the response includes Orbital’s profile status message.
• No setup changes: you don’t need to change your Orbital settings.

For details, see the stored instruments guide.

Product image uploads now save description, sort order, and thumbnail

We’re beginning to roll out a fix so uploading a product image file with multipart/form-data saves the description, sort_order, and is_thumbnail fields sent alongside image_file.

The rollout is progressive and starts on October 8, 2026.

• Saves image metadata on file uploads: these fields were previously ignored on multipart/form-data requests and only applied when you created the image from image_url with application/json. Both request types now behave the same.
• Validates the uploaded fields: a non-numeric sort_order or an is_thumbnail value that isn’t a boolean now returns a validation error, matching the application/json request, instead of being ignored.
• Progressive rollout: the change is enabled for a growing share of stores over time, so not every store sees it on the same day. Until the change reaches a store, multipart/form-data requests behave as before: the fields are ignored and not validated. Both changes arrive together, so a store never gets saving without validation or the reverse.

For request details, see Create a product image.

Clearer error when a shopper can’t remove a saved payment method

When a shopper removes a saved payment method from the Payment Methods page of their storefront account and the payment gateway rejects the request, the storefront now shows an error message instead of failing with an unhandled error.

• Error message: the shopper sees “There was an error removing your payment method. Please try again.” on the storefront error page.
• Customizable text: you can change the message by overriding the PaymentMethodDeleteError language string in your theme.
• No setup changes: you don’t need to change your theme or payment settings.

We are beginning to roll this out. You may notice this change in the coming weeks.

For details, see the Payments overview.