Introduction

This page maps the resource model behind the Astrada API — what each resource represents and how it relates to the others. For field-by-field contracts, see each resource's page under API Reference in the navigation.

Account

Your Account is the tenant Astrada provisions for your organization, configured by Astrada based on your commercial contract — which networks, countries, and card types you're eligible to enroll (capabilities), and any account-wide policy overrides. It's not something you manage via a public endpoint; every Subaccount you create operates within it. See Account & Subaccount Configuration for what carries over and what doesn't.

Subaccount

Subaccounts are a resource within your Astrada Account that enable the segmentation of Cards and Transactions based on your own concepts — for example, by department, program, or end customer. They're the unit entitlements and cost-control are applied at: enrollment controls (which cards are eligible) and verification policy (how strictly they're verified) are both set per Subaccount, each following its own rule for how it relates to the Account level — narrower, not identical, to the "ceiling" framing above. See Account & Subaccount Configuration for the full model.

Card

A Card represents the physical or virtual payment card, encapsulating essential information that remains constant over its lifetime — its network, country of issuance, expiry date, and other indelible facts.

Cardholder

Name, email, postal code, and an employer-side corporate.employeeId mapping for the person a card belongs to. Cardholder information is only populated for cards enrolled through a Network Bulk Feed, sourced from the feed itself — standalone SDK enrollment doesn't collect it. Fetch it via GET /cards/{cardId}/cardholder when available.

Subscription

The Subscription resource models the state of the continuous flow of transactional data associated with a specific Card within a specific Subaccount. A Card is enrolled by creating a Subscription; its state reflects whether that flow is currently active.

Verification

Verifications represent the processes required to transition a Subscription from an inactive state to an active state — a 3DS challenge with the card issuer. The Subaccount's verification policy controls how strict this process is.

Transaction Message

Individual messages model the specific card network messages that comprise the full cycle of a real-life purchase (authorization, advice, reversal, and so on) — each carries a messageType such as AUTH_ADVC or FINL_ADVC.

Transaction

A holistic representation of the state and history of a single card transaction. A Transaction amalgamates all relevant Transaction Messages and the implied current state, providing a comprehensive overview of the entire lifecycle from authorization through settlement.

Bank Link

A Bank Link represents a single bank-connection enrollment — the hosted flow a cardholder completes to connect a bank account via Plaid. Its state moves from pending to completed once the user finishes enrollment, at which point it exposes the Bank Accounts discovered under it.

Bank Account

A Bank Account is a connected (or manually created, "virtual") account at a financial institution. It's the anchor for bank-sourced activity: Bank Transactions sync onto it, and Cards are linked to it — automatically, the first time a card's transactions produce a high-confidence match against the account's feed, or manually via PATCH — to enable earlier settlement on that card's spend.

Bank Transaction

A Bank Transaction is a single movement synced from a linked Bank Account, via Plaid or an uploaded statement. Its status and settlement fields track whether it has been matched to a card Transaction and, if so, whether that match has settled on the unified Transaction feed.