Native account price lists: verify the association and the storefront
Use two fictional accounts with distinct prices to verify that both product and cart reads honor the intended account price list.
In this guide
- Account association
- Applicable price row
- Signed buying context
- Product page
- Cart calculation
The configuration looks right, but the buyer sees another price
An administrator associates a price list with an account and sees the expected record in Admin. A buyer signs in and still sees the ordinary store price. The association exists, but that alone does not prove the current buying context or storefront calculation uses it.
Work outward from a small fixture. Two accounts, one product, and two deliberately different prices are more informative than a large production catalog with similar discounts. The goal is to make each layer's selected account and price source observable without exposing real customer agreements.
Choose values that reveal the wrong path
Use fictional account codes and prices that are easy to distinguish. For example, one account can have a unit price of 41.25 and another 67.50, while the store price is different again. Avoid zero prices because they may interact with unrelated validation or presentation rules.
Resolve account, product, and price-list IDs by stable business key. Record the IDs returned by the target environment, but do not copy them into a portable fixture. Confirm the product variant and unit of measure being purchased. A correct parent-product price does not necessarily establish the selected variant's result.
Check account prices across product and cart
AccountPriceProbe defines two PriceObservation expectations for SAMPLE-VALVE-01: account ALPHA at USD 41.25 and account BETA at USD 67.50. The named AccountCode, Sku, Currency, and UnitPrice properties make the expected commercial result visible in one place.
Implement IAuthenticatedPriceProbe with a separately authorized fixture session for each account. Its methods read the product and cart price and map both responses into PriceObservation. The account argument selects the fixture session; it does not grant access to that account. Configure the price-list associations through Customers > Accounts > Price Management and set competing or inherited lists deliberately.
Pricing/AccountPriceProbe.cs csharp
using System;
using System.Threading;
using System.Threading.Tasks;
namespace Gcg.DeveloperExamples.Pricing
{
public sealed class PriceObservation
{
public string AccountCode { get; set; }
public string Sku { get; set; }
public string Currency { get; set; }
public decimal UnitPrice { get; set; }
}
public interface IAuthenticatedPriceProbe
{
Task<PriceObservation> ReadProductAsync(string fixtureAccount, string sku,
CancellationToken cancellationToken);
Task<PriceObservation> ReadCartAsync(string fixtureAccount, string sku,
CancellationToken cancellationToken);
}
public static class AccountPriceProbe
{
public static async Task VerifyAsync(IAuthenticatedPriceProbe probe,
CancellationToken cancellationToken)
{
if (probe == null)
throw new ArgumentNullException(nameof(probe));
PriceObservation[] expectations =
{
new PriceObservation
{
AccountCode = "ALPHA", Sku = "SAMPLE-VALVE-01",
Currency = "USD", UnitPrice = 41.25m
},
new PriceObservation
{
AccountCode = "BETA", Sku = "SAMPLE-VALVE-01",
Currency = "USD", UnitPrice = 67.50m
}
};
foreach (PriceObservation expected in expectations)
{
PriceObservation product = await probe.ReadProductAsync(
expected.AccountCode, expected.Sku, cancellationToken);
PriceObservation cart = await probe.ReadCartAsync(
expected.AccountCode, expected.Sku, cancellationToken);
foreach (PriceObservation actual in new[] { product, cart })
{
if (actual == null || actual.AccountCode != expected.AccountCode ||
actual.Sku != expected.Sku || actual.Currency != expected.Currency ||
actual.UnitPrice != expected.UnitPrice)
throw new InvalidOperationException("Account price readback differs from its expectation.");
}
}
}
}
}
// Implement the probe with separate authorized fixture sessions.
// The account argument chooses a test session, never grants account permission.
VerifyAsync reads both stages for each account and checks all four properties. ALPHA's product price can be correct while its cart still returns BETA's price; that case fails. In the fixture adapter's test output, identify which read produced the mismatch so the next investigation starts at product or cart with the expected context.
Use a fresh authenticated journey
Sign in as a fixture user whose account relationship is known. Inspect the active buying context, then open the product page and add the product to the cart. Repeat with the second account in a separate or clean session. Do not infer the session's account solely from an account name displayed in navigation.
Switching accounts within one browser is an important additional test. Relevant cached prices and cart projections must be invalidated or reloaded under the new context. A correct native association cannot compensate for a storefront that continues sending the previous account's context or displaying its cached response.
Change one variable at a time
Vary quantity, effective date, currency, and applicable association precedence independently. Temporarily remove one fixture association and confirm the documented fallback. Reintroduce it and repeat the readback. Keep fallback behavior visible so an apparently plausible number does not conceal a failed account lookup.
Check product detail, cart, and order calculation as separate stages. If they disagree, capture sanitized context and source information at each boundary. Do not copy a price directly into the cart to make the screens match; that bypasses the question of which system should calculate the authoritative value.
- Use synthetic agreements and user identities.
- Distinguish a missing row from an unavailable pricing dependency.
- Verify configurable variants and add-ons with their own fixtures.
- Record which integration stages were actually exercised.
Turn the investigation into a reusable fixture
Keep this small two-account matrix as a regression fixture after resolving the issue. Provision it by stable codes, preserve unrelated administrator values, and verify that an unchanged rerun performs no unnecessary writes.
Use distinct prices so accidental account sharing remains obvious. Repeat the product and cart checks after account switching or price-list changes, then add final order-calculation coverage when the changed feature reaches checkout.
References and further reading
Independent guidance from GCG. Znode is a trademark of its owner. Examples use fictional data and are not official platform documentation. Suggest a correction.