Native account price lists: verify the association and the storefront
Use distinctive fictional prices to follow an account price-list association from configuration into an authenticated product page and cart.
In this guide
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.cs defines an authenticated probe contract and concrete assertions for two fictional account price lists. VerifyAsync checks identity, currency, and unit price separately in the product and cart results. Implement the probe using separate authorized fixture sessions rather than trusting its account argument as permission.
Create the fixture price lists and associate them under Customers > Accounts > Price Management. Znode's account price-list documentation describes association precedence. Set any inherited or competing lists deliberately, then map the actual product and cart responses into PriceObservation so the same assertion identifies the failing stage.
Pricing/AccountPriceProbe.cs csharp
using System;
using System.Collections.Generic;
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)
{
var expected = new Dictionary<string, decimal> {
{ "ALPHA", 41.25m }, { "BETA", 67.50m }
};
foreach (var pair in expected)
{
var product = await probe.ReadProductAsync(pair.Key, "SAMPLE-VALVE-01", cancellationToken);
var cart = await probe.ReadCartAsync(pair.Key, "SAMPLE-VALVE-01", cancellationToken);
foreach (var result in new[] { product, cart })
if (result == null || result.AccountCode != pair.Key ||
result.Sku != "SAMPLE-VALVE-01" || result.Currency != "USD" ||
result.UnitPrice != pair.Value)
throw new InvalidOperationException("Account price readback differs.");
}
}
}
}
// Implement the probe with separate authorized fixture sessions.
// The account argument chooses a test session, never grants account permission.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
Once the relationship is understood, keep the small account-price matrix as a regression fixture. Ensure it can be provisioned with supported APIs, read back exactly, and rerun without unnecessary changes. Preserve administrator-owned values outside the fixture's scope.
This approach gives the team a short path from 'the buyer sees the wrong price' to a specific failing boundary. It also avoids treating account pricing as a single configuration checkbox. Correct behavior requires the right relationship, the right buying context, and the right calculation to remain connected all the way to purchase.
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.