Two levels

Your Astrada Account is the tenant Astrada provisions for your organization, configured by Astrada based on your commercial contract. Every Subaccount you create (see Core Resources) operates within it. The account level isn't something you call an endpoint to change yourself — but understanding what it controls explains behavior you'll otherwise see as unexplained defaults on your subaccounts.

Three settings live at both levels. Each has its own rule for how the levels interact — they are not all the same rule:

Setting	What it controls	How the levels interact
`configurations`	Which card networks, countries, and card/funding types are eligible to enroll	Account sets the ceiling (`capabilities`) — the countries you're contracted for, plus default blocked types. Subaccounts narrow within that ceiling, or inherit it wholesale with `"*"`.
`verificationPolicy`	Verification tier, sandbox routing	Copied onto a subaccount once, at creation — after that, only the subaccount's own value is ever read. Changing the account-level policy later does not affect existing subaccounts.
`enrollmentPolicy`	Whether the Spinwheel enrollment option is offered	The account-level `spinwheelEnabled` is a live master switch — off at the account level means off everywhere, checked on every read, regardless of what's stored on the subaccount.

Network, country, and card-type eligibility

Each subaccount's configurations (set via POST /subaccounts or PATCH /subaccounts/{subaccountId}) controls which cards are eligible to enroll, per network:

countries — an explicit array of ISO 3166 alpha-3 codes, or "*" to inherit your account's
full contracted list for that network. An explicit array must be a subset of the account's
contracted countries, or the request 400s. "*" also stays in sync automatically if your
account's contracted countries change later.
single-enrollment and bulk-enrollment — each carries its own countries and blocked
card/funding types, since a network can support different regions or restrictions for the two
enrollment paths. Your account has sensible defaults for both; a subaccount only needs to set
these if it wants something narrower.

See Quick Start: Card Enrollment for how this interacts with verification tiers, and Integration Guide for a working example.

Verification policy

verificationPolicy.stripeValidationLevel picks the verification tier — LOW/MEDIUM/HIGH/HIGHEST, see Verification Risk Tiers. This field is subaccount-only at request time — the resolver reads the subaccount's stored value and nothing else. There is no live fallback to the account level.

📘
What "unset" actually means
When a subaccount has no stripeValidationLevel set, verification does not default to
MEDIUM — it routes through the legacy, non-Stripe path (TokenEx/IXOPAY for Visa, TNS for
Mastercard) instead, which is a materially different flow. MEDIUM/HIGH/HIGHEST are tiers you
opt into explicitly via PATCH /subaccounts/{subaccountId}. If you want Stripe-routed
verification at all, set a tier — don't rely on an assumed default.

The account level still matters once: when a subaccount is created, it copies whatever verificationPolicy its account had at that moment as a starting value. From then on, the subaccount's own stored value is authoritative — changing the account's policy afterward has no effect on subaccounts that already exist. verificationPolicy.sandbox (see Test Cards & Sandbox Testing) follows the same subaccount-only rule.

verificationPolicy.failedAttemptLockout (see Verification Attempt Lockout) is also set per subaccount; we don't have a confirmed account-level interaction for this one to document here.

Enrollment policy

enrollmentPolicy gates a Spinwheel enrollment option and the card-program BINs used to match cards to it — an admin-managed setting configured during onboarding, not something you toggle via a public endpoint. The one behavior worth knowing: the account-level spinwheelEnabled is a live master switch. If it's off, it's off for every subaccount regardless of that subaccount's own stored value — and if the account is later re-enabled, subaccounts that already had it on come back automatically, with nothing to re-configure.