Core Resources
Core Resources for Astrada
Astrada has a simple object hierarchy seeking to represent real-world concepts.
In this section we will walk you through the high level concepts each one represents and direct you to further detailed information.
Within your Account, you can create multiple Subaccounts, as you see fit. Subaccounts then serve as a container for a set of Subscriptions, which relate to a Card, and Subscriptions will produce transaction data that is also contained within the Subaccount.
Below is a summary of the Astrada hierarchy:
Subaccounts -> Cards & Subscriptions -> Data (Transactions and Transaction Messages)*
* Further details coming soon
Configuration Resources
Subaccounts
Subaccounts are a resource within your Astrada Account. They are created by you and enable the segmentation of Cards and Transactions based on your own concepts. They can be used for entitlements and cost-control purposes.
Card and Enrollment Resources
In the Astrada ecosystem, three core resources—Cards, Subscriptions, and Verifications—play pivotal roles in managing the lifecycle of enrollment and ensuring data sharing can be managed seamlessly.
Cards
A Card in the Astrada represents the physical or virtual payment card, encapsulating essential information that remains constant over its lifetime. This includes the card's country of issuance, expiry date, and other indelible facts.
Subscriptions
The Subscription resource models the state of the continuous flow of transactional data associated with a specific Card within a specific Subaccount.
Verifications
Verifications represent the processes required to transition a Subscription from an inactive state to an active state, ensuring that the Card is validated and authorized for data tracking and analysis.
Transaction Resources
Within the Astrada service we offer two distinct views of card transactions to help you grasp the entire payments ecosystem more comprehensively.
These individual messages model the specific card network messages that comprise the full cycle of a real life purchase (single card transaction). Notably, this includes the behind-the-scenes activities that convey meaning but that are typically invisible to cardholders. The kind of message being represented is indicated by the messageType field, with values like 'AUTH_ADVC'.
This is a holistic representation of the state and history of a single card transaction. Unlike Transaction Messages, which offer a segmented view, the Transaction aims to provide a comprehensive overview of the entire lifecycle of a single card tap or swipe. It amalgamates all relevant messages and the implied current state to offer a complete picture.
By utilizing both the granular insights from Transaction Messages and the overarching view from Transaction, you can achieve a well-rounded understanding of card transactions in your application.
You can find out more about the precise fields available on the Transaction Message and Transaction objects on their respective reference pages.
Updated about 2 months ago