Testing SFCC Checkout with Playwright: Scenarios That Catch Regressions

A Playwright test can reach the checkout page and still miss a wrong order total. The harder question for a Salesforce Commerce Cloud team is whether changes to basket state, customer identity, shipping, promotions, and payment produce the right result all the way through order placement.

Our existing SFCC Playwright tutorial explains how to set up a suite and supply representative SFCC product data. This article assumes that foundation. It describes which checkout behaviors deserve assertions and how to keep those tests dependable. It is not a second Playwright installation guide.

Give every scenario a controlled starting state

Create test data in a non-production SFCC environment and use only the payment provider's sanctioned test paths. A scenario should declare the product and variant, inventory state, shopper identity, currency, shipping destination, promotion, and expected outcome. Avoid pulling an arbitrary live product and assuming its price or stock will remain stable.

Isolate accounts and baskets where tests could interfere with one another. If a test creates an order, give it a distinguishable test identifier and an agreed cleanup or reconciliation process. Do not use real card data, production customer records, or screenshots containing personal information.

Assert at the state changes that can alter money

A small release-blocking suite can cover these journeys:

• Anonymous purchase: add a product, change quantity, select shipping, complete a permitted test payment, and check confirmation against the returned order.
• Promotion eligibility: start with an ineligible basket, add the qualifying item, verify the adjustment and total, then remove the qualifier and verify that the adjustment disappears.
• Returning customer: sign in using a dedicated test account, verify the basket and address behavior, then check the supported purchase path.
• Failed payment: exercise an approved decline or validation case, confirm the shopper sees a recoverable error, and verify that the site does not present a successful order.

Assert basket line items, adjustments, shipping, tax, and total after each meaningful mutation. Where an API read helps validate state, Playwright supports API requests in the same test workflow. Use accessible, user-facing locators and auto-retrying assertions for the UI as Playwright recommends; avoid selectors tied to generated CSS classes or fixed pauses that merely make a flaky test slower.

A passing browser flow does not prove all backend calculations are right. In Tevpro's SCAPI promotion example, eligibility can change when basket items are removed. The checkout suite should test that transition, while a lower-level integration test can identify which calculation rule failed.

A checkout scenario matrix worth maintaining

The release gate should be small, but each case needs an expected observable result. Use this matrix as a starting point, then substitute your own promotion, tax, fulfillment, and payment rules.

• Baseline basket: add one in-stock item. Check SKU, quantity, currency, unit price, merchandise subtotal, and whether the selected locale or market matches the fixture.
• Quantity and inventory: increase quantity within available stock, then try an unavailable quantity. Check the returned basket and customer-facing error; do not accept a stale total after the rejected change.
• Dependent promotion: add the qualifying product, confirm the discount and final total, then remove the qualifier. Confirm the discount disappears after recalculation, including when the shopper navigates away and returns to checkout.
• Shipping and tax: change the address or shipping method in a test market where that changes the quote. Check the chosen service, shipping charge, tax, and final total. Avoid hard-coding a tax amount unless the test fixture controls the rule.
• Payment and order: use the provider's test success and decline cases. For success, verify one order with the expected total and no duplicate submission. For decline, verify a recoverable error and that no successful order is reported. Confirm the outcome using an authorized test-order lookup, not only the confirmation page.

Keep expected money values in versioned test fixtures. A test that computes its expected total by repeating the storefront's own calculation can reproduce the same bug and still pass. Reconcile expected values with an independently approved rule or a controlled known-good basket when the fixture changes.

Example: prove a discount disappears when eligibility changes

The following Playwright example is intentionally bound to an **illustrative** storefront. Replace the routes, accessible names, test IDs, and expected values with your actual non-production fixture. It tests one business rule; it does not configure OCAPI credentials or duplicate the existing setup tutorial.

import { test, expect } from '@playwright/test';

test('removing a qualifying item removes its discount', async ({ page }) => {
  await page.goto('/test-catalog'); // Replace with a controlled test route.
  await page.getByRole('button', { name: 'Add qualifying product' }).click();
  await page.getByRole('button', { name: 'Add accessory' }).click();
  await page.getByRole('link', { name: 'Cart' }).click();

  await expect(page.getByTestId('promotion-adjustment'))
    .toHaveText('-$10.00'); // Known-good value from this fixture.
  await page.getByRole('button', { name: 'Remove qualifying product' }).click();
  await expect(page.getByTestId('promotion-adjustment')).toHaveCount(0);
  await expect(page.getByTestId('basket-total'))
    .toHaveText('$50.00'); // Includes the controlled basket's charges.
});

The value of this test is the transition, not the sample selectors. If your storefront shows a different promotion structure, assert the returned adjustment and total through its supported API or order view as well. Playwright's API request context can verify a postcondition from a browser test; use an isolated context when sharing browser cookies would change the test.

Diagnose failures without leaking shopper data

An E2E failure should identify the first incorrect transition: item addition, discount recalculation, shipping quote, payment authorization, or order creation. Save a sanitized basket or test-order identifier and the expected versus actual amount. Playwright traces can expose DOM snapshots, screenshots, and network details, so restrict access and retention. For signed-in tests, Playwright also warns that stored authentication state can contain impersonation-capable cookies; keep it out of source control and avoid one shared account across parallel workers that mutate server state.

For promotion failures, run the same basket mutations against the API path the storefront uses. If the API total is wrong, inspect SFCC calculation and hooks. If the API total is right but the UI is wrong, inspect client state and rendering. This split makes a failing test useful to the owner who must fix it.

Split release blockers from the scenario matrix

Do not run every market, tax address, coupon combination, and payment method in every pull request. Keep a small, stable checkout path as a release gate. Run a broader matrix on a schedule or before a commerce release, selecting cases from actual business rules and incident history.

When a test fails, capture the scenario name, environment, basket or test-order identifier, and sanitized request or response evidence where permitted. Preserve Playwright traces under an access policy; do not make them a back door for customer or payment data. Triage whether the failure came from storefront behavior, SFCC calculation, a connected service, or test data before changing assertions.

What the suite should tell a release owner

A useful checkout report says which journey failed, what changed, whether money or order state is affected, and who owns the next diagnostic step. A green screenshot of a thank-you page is not enough. The goal is evidence that the supported purchase paths still behave correctly after a change, with clear boundaries for cases that have not been tested.

If checkout changes are creating release anxiety, Tevpro's SFCC team can help select the smallest reliable test set and map failures to the right layer.