Skip to content

Payment sandbox fixtures (Wave 3)

Wave 3 of the Selenium → browse-tests migration covers payment flows. Those flows depend on a sandbox payment account being wired up on the test org. This doc spells out the env-var contract and how to obtain values.

Contract

Env var Set from local.settings.json field Purpose
BROWSE_TEST_STRIPE_TEST_CARD stripeTestCard Stripe sandbox PAN used in card-entry fields. Default 4242424242424242 is the published Stripe test card.
BROWSE_TEST_STRIPE_ACCOUNT stripeAccount Permalink of the test sub-org whose Stripe Connect account is in test mode. Stripe tests skip when blank.
BROWSE_TEST_STRIPE_ACCOUNT_EMAIL stripeAccountEmail Admin login email for the Stripe-connected sub-org. Tests that log in as that org directly (e.g. payment-regression/02-reports-payments-export-read-only.ps1) need both this and stripeAccount.
BROWSE_TEST_IYZICO_TEST_CARD iyzicoTestCard Iyzico sandbox PAN used in card-entry fields. Default 5528790000000008 is the published Iyzico test card.
BROWSE_TEST_IYZICO_ACCOUNT iyzicoAccount Permalink of the test sub-org whose Iyzico merchant account is in sandbox mode. Iyzico tests skip when blank.
BROWSE_TEST_IYZICO_ACCOUNT_EMAIL iyzicoAccountEmail Admin login email for the Iyzico-connected sub-org. Same login-as-that-org pattern as the Stripe pair.

Wiring lives in scripts/dev/pr-ready-check.ps1 immediately after the admins-only-field wiring. PM-* batch authors consume the env vars directly; the precheck browse-tests/payment-regression/00-fixture-check.ps1 reports which gateways are configured at suite start so missing fixtures are visible.

Test cards

The card numbers ship with this file as safe defaults — they are gateway- published, marked unusable for real charges, and need no rotation:

Override these only if you need to exercise a specific decline / 3DS / non-USD scenario.

Sandbox accounts

The account identifiers are your test org, not a global secret. Wiring order:

  1. Pick a test org on *.raklet.org that is not your primary dev org — payment flows leave traces that should not pollute regular dogfood data.
  2. Connect that org's Stripe (Settings → Payment → Stripe Connect) in test mode.
  3. Repeat for Iyzico (Settings → Payment → Iyzico) in sandbox mode.
  4. Put that org's permalink in the stripeAccount / iyzicoAccount field of your local.settings.json, and its admin login email in the corresponding stripeAccountEmail / iyzicoAccountEmail field.

Until you have done that, the account fields stay blank and the gateway's tests skip — which is the correct safe default.

Why split card from account

A test card is a constant published by the gateway. An account is the sandbox-connected merchant. Splitting them means engineers without sandbox access can still run other suites without false failures, while PM authors can move the test card to a non-default value (3DS, decline) per-test by overriding only the card env var.

Adding a new gateway

If a Wave-3 test needs a gateway other than Stripe / Iyzico:

  1. Add <gw>TestCard and <gw>Account fields to browse-tests/local.settings.example.json under the _optional_payment_sandbox block.
  2. Wire BROWSE_TEST_<GW>_TEST_CARD and BROWSE_TEST_<GW>_ACCOUNT in scripts/dev/pr-ready-check.ps1 (same pattern as Stripe/Iyzico).
  3. Extend the table in docs/testing/browser-test-migration-prompt.md so batch authors see the new gateway in the fixture contract.
  4. Extend 00-fixture-check.ps1 to surface the new gateway's status.

That keeps adding a gateway to four small, mechanical edits — no test-author guesswork about env-var names.