BigCommerce Payments order summary no longer counts shipping tax twice
On stores that show prices with tax, the order summary in the PayPal window no longer counts the tax on shipping twice or shows the difference as a discount.
- Shipping tax: when the shopper picks a shipping address or shipping option in the PayPal window, the tax line no longer includes the tax that is already in the shipping amount. Previously, PayPal showed that amount again as a discount, labeled with the coupon name or “Voucher 1”.
- Stores that show prices without tax: the order summary does not change.
The amount charged to the shopper does not change.
BigCommerce Payments waits for PayPal approval instead of declining
We’re beginning to roll out a fix for BigCommerce Payments declining a payment that was submitted before the shopper approved it at PayPal. Over the coming weeks, every store will get the fix.
- The order waits for approval: when PayPal reports that the shopper hasn’t approved the PayPal order yet, the order stays Incomplete and its payment waits for that approval. Previously, the payment was marked declined.
- Stock stays held: the order keeps its stock while it waits. Previously, the decline released the stock.
- A later payment completes the order: once the shopper approves at PayPal, the next payment for the same order completes it. An order the shopper never approves releases its stock when it is abandoned, like other orders that wait on the shopper.
- Store log: the store log records a notice instead of an error for these attempts.
- Orders API: while the order waits, its V2
payment_statusisadditional action requiredinstead ofdeclined, and the attempt’s transaction has statusadditional_action_requiredinstead oferror. - Which payment methods: the fix applies to methods the shopper approves at PayPal, such as PayPal, Pay Later, Venmo and bank payment methods, when the payment request names an existing PayPal order. Card payments, Apple Pay, Google Pay, Fastlane and stored payment methods are unchanged: PayPal’s refusal stays a decline.
- Payments API: the HTTP response to a payment request doesn’t change. A payment submitted before approval still returns error
30102, “The payment was declined.”; only how the order records the attempt changes.
Conversational Search
Conversational Search upgrades BigCommerce’s native storefront search so shoppers can search in natural language and still find relevant products, even when their words don’t appear in your product data.
- Hybrid search: Combines meaning-based matching with keyword matching, so SKUs, product names, and brands keep working while descriptive queries return relevant results.
- No catalog changes: BigCommerce generates embeddings for your catalog in the background. You don’t need to rewrite product copy.
- Fewer zero-result searches: Stores see up to 70% fewer searches that return no results.
- Free on paid plans: Available at no additional cost. Opt in or out at any time under Settings › Search.
For details, see Conversational Search.
Product attribute filter fix for searchProducts
We’ve fixed a bug in the Storefront GraphQL API where searchProducts could leave out products that match every filter in filters.productAttributes. The fix is now live for all stores.
- Affected requests:
site.search.searchProductsqueries that usefilters.productAttributes, where a product’s matching values are on different variants, or are stored as custom fields rather than variant options (or the reverse). - Each attribute matches on its own: with the fix, a product is returned when every selected attribute value appears either as an option value on any of its variants or as a custom field value. This matches faceted search results on Stencil storefronts.
- More products in some results: affected queries can return products they previously left out. Unaffected queries return the same results.
- No request changes: you don’t need to change your
searchProductsqueries.
For details, see Search and filtering with product attributes.
Enabled payment methods in the GraphQL Storefront API
The site.paymentMethods field is now available in the GraphQL Storefront API. It lists the payment methods enabled for the store, the current channel, and the shopper’s currency. Each payment method returns an entityId and a display name. The field does not require a customer JWT.
Use it with stored payment instruments to query the payment method name.
Site.paymentMethods and PaymentMethod.capabilities fields are no longer marked as alpha and are now safe to use in production.
For details, see the Payment Methods guide and Get payment method names for stored payment instruments in the Customers guide.
Control storefront visibility of product custom fields
Product custom fields now have a Visible on storefront toggle, so merchants can choose which custom fields shoppers see and which ones stay internal.
- Visibility toggle: set each custom field as visible to shoppers on the storefront or as internal-only.
- Where to set it: the toggle is available on the add and edit product pages in the control panel.
- API support: the Catalog API doesn’t support this setting yet. API support is coming next.
Product Merchandiser app: fix for choosing a plan after a subscription has ended
In the Product Merchandiser app, merchants whose subscription had ended could not choose a new plan. Choose Plan now starts a new subscription.
- What was wrong: After a merchant cancelled their plan and the paid period ran out, selecting Choose Plan on the Account page failed with a Stripe error.
- What’s fixed: Choose Plan now starts a new subscription for the merchant, billed to the payment method on file.
- Who is affected: Merchants of the Product Merchandiser app whose earlier subscription had ended. Merchants with an active subscription, or a cancelled one still inside its paid period, see no change.
- What does not change: Plans and pricing are unchanged. This fix applies only to the Product Merchandiser app, not to BigCommerce platform billing or the BigCommerce APIs.