Check identity and currency before fixing missing credit

An account page can show credit while checkout offers none. Start with the account model, signed-in identity and checkout currency before asking a designer to add a manual balance field. A new field can disguise the mismatch without making payment valid.

Source-bound fact

Store credit requires supported customer accounts or Shop Pay; checkout exposes the matching-currency balance. Official reference · Checked 17 October 2026.

Filled synthetic acceptance example

Synthetic teaching example, not a client case or a real-store assessment. On narrow screens, scroll to read the complete table.

Supplier acceptance procedure

1. Record legacy/new account mode and whether the user is actually signed in through a supported path.
2. Compare internal customer identity and currency, not the visible email label alone.
3. Test one authorised account with separate currencies and a signed-out control; preserve the actual offered payment option.

Interpret the output

The sample deliberately refuses to sum AUD and USD. A missing option with no identity evidence remains unexplained, not a zero balance. The useful supplier output is a path/currency/identity matrix that distinguishes account configuration from payment processing.

Explicit limits

D2C acceptance model only. Company-location B2B credit, recurring bills, draft/edited orders, fees and currency conversion are outside this fixture.

Replay the finite teaching model

Save both files in one folder. With Node22 or newer, run the command below. JSON contains explicit inputs and expected results. The script processes synthetic data only, with no network, credentials, payment or API calls. Passing proves the finite model only, not a live integration.

Filled inputs and expectations · Inspectable teaching script

node check.mjs store-credit-identity-currency-acceptance.json