Website v21.0.14 to v21.0.15 - 26 August 2026

These two patch releases are mostly about payments. CyberSource now accepts a wider set of card networks out of the box, and ACH bank fields appear reliably on payment forms that start hidden and are revealed later. On the fix side, subscription renewals that involved a card surcharge were losing the subscription line from the order, renewal payments taken in Salesforce or at the POS were creating duplicate subscriptions, and switching an Authorize.Net subscription to ACH saved nothing and kept charging the card. There are also fixes for Stripe wallet payments on pay-balance links, Square payments in the POS, and resending a POS receipt by email.

Breaking changes and cautions

:::warning CyberSource now offers more card networks by default

The default set of card networks offered on a CyberSource card form widens from Visa, Mastercard, and American Express to also include Discover, Diners Club, and JCB. The list was only ever a filter in the customer’s browser, so it prevented Discover holders from paying at stores whose CyberSource account supported Discover perfectly well.

The list does not control what your CyberSource account actually accepts. If your account is not enabled for one of the newly added networks, a customer can now select that card and the payment is declined at authorization rather than blocked at entry. To keep the narrower list, set allowed_card_networks in the CyberSource payment provider’s API options. See CyberSource payment provider. [WEB-9379] :::

Enhancements

CyberSource accepts Discover, Diners Club, and JCB out of the box

Customers paying with Discover at a CyberSource store previously hit a validation error at checkout and could not buy anything, even when the merchant’s CyberSource account supported the card. The accepted networks now default to Visa, Mastercard, American Express, Discover, Diners Club, and JCB, and CyberSource itself decides what to approve. Stores that set allowed_card_networks explicitly keep whatever list they configured. [WEB-9379]

ACH bank fields now appear on payment forms that are revealed after loading

On NMI and StoreConnect Pay, the bank account fields failed to appear when the payment form started hidden and was revealed later, which is what happens on the subscription page’s update payment details flow. The fields are now built when the form is genuinely visible, and the store retries until they appear, so a customer who switches to ACH after the page has loaded gets a working form. See NMI payment provider. [WEB-8810]

Upgrades no longer lock large tables while database indexes build

Upgrades that added a database index locked the affected table for the duration, which showed up as slowness or unavailability on stores with large tables. Indexes now build alongside normal traffic on the upgrade path, so a release that adds one is no longer disruptive. [SYS-8719]

Deprecated fields

No fields are removed or deprecated in these releases.

Fixed bugs

Subscription renewals with a card surcharge lost the subscription line

When an evergreen subscription renewed against a payment provider that adds a card surcharge, the customer was charged the correct full amount but the resulting order contained only the surcharge line. The subscription product itself was missing, and nothing errored or failed to sync, so the problem was invisible until someone looked at the order. Renewal orders now recognize the surcharge as an adjustment rather than treating it as evidence that the order had already been filled in, and the subscription line is created as expected. [WEB-9367]

Paying a renewal order from Salesforce or the POS created duplicate subscriptions

Recording a payment against a renewal order in Salesforce, or taking it at the POS, created a brand new subscription for every subscription product line on the order, so a renewal with three subscription lines produced three duplicate subscriptions that had to be canceled by hand. On this release line the payment link already refuses renewal orders, so it was not affected. Renewal orders now renew the existing subscription and never create new ones on any payment path. Payment still applies to the correct existing subscription. [WEB-9378]

Switching an Authorize.Net subscription to ACH kept charging the card

A member switching a subscription from the Authorize.Net credit card provider to the ACH provider saw a success message, but the bank details never reached Authorize.Net and renewals carried on charging the card. Both providers can share one Authorize.Net merchant account and therefore one customer profile, and the switch was discarding the stored profile and trying to create a duplicate, which Authorize.Net rejected. The existing profile is now found first and the bank account added to it as the default payment method. The same lookup applies at checkout, so an existing card customer paying by ACH is added to their own profile rather than a second one, and a genuine profile collision now fails visibly instead of reporting success. See Authorize.Net ACH payment provider. [WEB-9676]

Updating payment details on an Authorize.Net subscription rejected every submission

On the subscription’s update payment details page, some subscriptions, typically ones migrated from another system, produced the error “Please provide mandatory field to library” on every attempt. The card fields were rendering empty because the page could not find a contact email on the original order, and the failure was swallowed silently. The page now falls back to the subscription’s own contact, and the card fields render correctly. [WEB-9375]

Stripe wallet payments on a pay-balance link recorded no payment

A customer paying an outstanding balance through a payment link with Apple Pay, Google Pay, Link, or PayPal was charged successfully in Stripe, but no payment record was ever created and nothing was logged. Stripe was returning the customer to the cart checkout page, which bounced them for having an empty cart before the payment could be confirmed. Wallet payments now return to the correct page. The same gap is closed for Afterpay and Windcave, the 3D Secure return trip no longer depends on session data that a cross-site redirect can drop, and a failed confirmation is now reported rather than passing silently. [WEB-9372]

Resending a POS receipt by email disrupted the order

Emailing a receipt for a completed POS order pushed the order’s checkout step from complete to finalized and back again. Any Salesforce Flow keyed on the completed step fired a second time, and the receipt email itself was intermittently lost because the email template did not match while the order was briefly in the finalized state. Resending a receipt for an already-completed order now sends the email without touching the order. [POS-9376]

Square payments in the POS could keep polling after cancellation

Canceling a Square payment in the POS did not reliably stop the terminal being polled, and a stale poll could resume against the payment that had just been canceled. Several error paths also failed silently in the browser instead of showing the operator a notification, and leaving the payment screen left the poll running. Cancellation now stops polling immediately, leaving the screen now cleans up properly, and error and offline conditions show a notification. See Square payment provider. [POS-9374]

Product pages ran a heavier stock query than needed

Checking whether a product could be purchased queried stock locations twice and loaded more data than the check needed, adding avoidable work to every product page view. The query is now issued once. [WEB-9306]

Shared Success reported the wrong channel for payments

Payment records sent for Shared Success reporting copied the channel from the order, which describes how the order was created rather than how the payment was taken. A payment now reports its own origin, so POS payments and POS pay-by-link report as pos, API payments and refunds report as api, and website, subscription, automatic renewal, pay-balance, and Salesforce-recorded payments report as online. [SYS-9584]