Introduced Content-Security-Policy header configuration for the Storefront frontend app. See Security Guide for configuration details.
ContentService is now being used to access content details in a centralized location, such as using the service to fetch the default theme colors for the site.
PaymentTransactionService was introduced in v1.4.0 to begin the separation of business logic regarding payments from Carts and Orders.
One additional change in v1.4.2 building upon that is the migration of
CustomerPayment data, service, and endpoints from the
CustomerService to the
PaymentTransactionService. As such, the front-end components were updated to use
PaymentTransactionService saved payment data rather than using
CustomerService customer payment data.
Other changes include:
Updated components to use
Updated Passthrough, Paypal, Checkout.com, and Stripe payment forms to use the
PaymentTransactionService saved payment approach
Updated components that use
PaymentAccount to use
Updated My Account Payments to use
We also added a
PaymentsContext to store the state of payments related to the current cart
Enhanced Payment and SavedPayment ownership validation by:
moving the saved payment ownership validation from the endpoint-level (
CustomerPaymentManagementEndpoint) to service-level (
adding two fields to
owningUserId, to indicate the owner of the payments
adding validation to ensure that anonymous customer cannot access payments that belong to a customer
savePaymentForFutureUse to support owning user types other than customer (i.e. account)
Another change seen in v1.4.2 is the integration of Checkout.com as another method of payment upon checkout. In particular, aside from adjusting to the changes to payment method objects due to the
PaymentTransactionService migration & adding the usage of the
PaymentMethodEndpoint upon checkout to lay the groundwork for the Checkout.com payment method, there was a particular focus on supporting 3DS transaction requests and executions.
We also feature Checkout.com data in the My Account Saved Payments section, by making use of Checkout.com’s Frames components. The Frames interaction produces a short-lived (15 min), single-use token that can be exchanged for a multi-use token via the Payment Instrument API. The returned
source.id is the multi-use token & should be stored in the saved payment’s
paymentMethodProperties, which can then be used to display data in the Saved Payments section.
In order to qualify which users can access what type of data catalogs,
AccessPolicy domains were introduced in Tenant Services and DataTracking, which has fields for rules and users. The rules fields function as inclusion and exclusion filters used on
CatalogRefs for catalog inheritance, while the users fields will allow the requests to target Customers, Accounts, or Customer Segments.
Part of implementing basic Catalog Access Policies is passing the Customer access token, which contains pertinent information about the currently authenticated Customer who is making the Catalog request. v1.4.2 ensures that the Customer access tokens are being passed when the Search and Search Suggestions requests are made.
Fixed: Error for non-SSR pages with undefined gateway host in Content Services client
Fixed: Preview on site not working initially on pages with SSR enabled due to caching (Products, Categories, Customer Segments)
Fixed: Payment token used in test mode for passthrough transactions is not being populated
Fixed: Error when updating a cart item whose product no longer exists
Fixed: Added null check for product or variant referenced by bundle item
Fixed: CSR Anonymous Transfer Cart Token URL empty upon generation
Fixed: Checkout.com payment form render issue