This guide describes general characteristics of transactions in the Galileo system. For an explanation of how card transactions work specifically, consult About Card Transactions.
In the Galileo system, “transaction” describes any movement of funds into or out of a customer account. Transaction types include payment-card transactions, direct deposits, ACHACH - Automated clearing house. A method of transferring funds from one bank to another, maintained by the U.S. Federal Reserve. The transfers are processed in batches, and it can take up to 72 hours for a transaction to clear a bank. The ACH is separate from card networks and Galileo processing. transfers, cash loads, ATM fees, and other types of money movement.
Transactions are central to any banking app. Your customers expect to use your product to create transactions and to see a history of their transactions. You can enable them to do both by using Galileo's API.
Transactions are created in two primary ways:
- Using the API — The transaction can be initiated by:
- Your customers on your web site or mobile app, such as an ACH credit
- You, according to your business logic, such as assessing a fee
- Outside the API — The transaction can be initiated by:
- A card reader at a point of sale or ATM, such as a card purchase at a merchant site. See About Card Transactions for more information.
- An external depositing entity, such as an employer making a direct deposit. See About ACH for more information.
- An external debiting entity, such as a utility automatically withdrawing a billing amount
For the transactions that are created outside of your programmatic control, you can be notified of them by consuming the Auth API webhook or the Events API webhook, obtaining Transaction History via API, or consuming the daily RDFRDF - Raw data file. Once per day Galileo sends you RDFs that contain a list of all of your previous day's transactions and all of your current customers. Compare the RDFs with your own records and if there are discrepancies, treat the RDFs as authoritative.s.
Galileo recommends that you keep a record of all transactions in your own system by consuming the Events API and reconciling it against the daily RDFs, as explained in the Transaction History guide. You should also create an identifier in your system for each transaction that is unique across all transactions. See the Mapping Transactions Within Your System guide for more information.
Each transaction is classified by its activity category and transaction type.
All transactions belongs to one of four activity categories:
- Authorization/Settlement — A transaction that occurs over a card network's rails (system), such as when a cardholder initiates a purchase at a store.
- Payment — A transaction by which funds are moved into a customer account, originating with the Program API or with an external source such as a paycheck deposit.
- Adjustment — A transaction used to modify the customer's balance for various operational purposes, either a credit or debit, originating with the Program API or a direct debit from outside the API, such as an ACH transaction.
- Fee — A transaction that charges a cardholder for a particular service, which may originate with the Program API or by an automated process.
The authorization/settlement category is broken down into multiple activity types, whereas payments, adjustments, and fees have only one activity type each. The activity types in the authorization/settlement category differentiate among card networks such as Mastercard and Visa and types of transactions such as authorizations, expired authorizations, backouts and settlements.
Galileo uses two capital letters to represent activity types. Some common authorization/settlement activity types are:
|Mastercard Banknet authorization|
|Mastercard Banknet settlement|
|Mastercard debit authorization|
|Mastercard debit settlement|
|Visa Interlink settlement|
|Visa Plus settlement|
Non-network activity types are represented as follows:
For a list of all activity types consult the Activity Type enumeration.
Each of the activity type categories is divided into more specific transaction types, often called otypes. For example, a payment could be a direct deposit, a cashier's check, or a cash load, among others.
A transaction type consists of one to four characters and may contain letters or numbers. Transaction types are case sensitive, so in the payment activity category,
DC is a Discover chargeback whereas
dc is a direct-load reversal.
A transaction type is unique only within the activity category. For example,
Z is a bill-payment check in the adjustment activity category and a refund in the authorization/settlement activity category.
This table contains some authorization/settlement transaction types that are common to all networks:
|Mastercard Banknet settlement|
|Mastercard Banknet settlement for mobile wallet or peer-to-peer cash transfer|
See the Transaction Types enumeration for a list of authorization/settlement transaction types. For payments, adjustments, and fees, the list of supported transaction types is specific to your use case and bank requirements. Galileo will provide you with a curated list of transaction types that you will be using.
A transaction code (often designated
trans_code) is a combination of an activity type (the first two characters) and a transaction type (the remaining characters). This table shows some common transaction types.
|Code||Activity type||Transaction type|
Because of this structure, a transaction code can be easily deconstructed to obtain the activity type and transaction type.
The transaction code and its component parts are represented differently by different aspects of the Galileo system.
The program APIs return the transaction code, activity type and transaction type in these fields:
|Get Account Overview||X||X|
|Get Authorization History||X|
|Get Transaction History||X||X|
|Get All Transaction History||X||X||X|
trans_code for reconciliation with the Posted Transactions RDF.
Authorization, Settlement, and Transaction Events messages break out the transaction code into two fields: activity type (
act_type) and transaction type (
The activity type must be derived from the
subnetwork parameters. For example, if
auth_type: Auth and
subnetwork: Mastercard Debit Switch, then the activity type is
DB (Mastercard Debit Authorization).
The transaction type is in the
transaction_type parameter. However, the value will be a transaction-type description rather than the code. For example, you would see
transaction_type: Balance Inquiry instead of
The Posted Transactions RDFRDF - Raw data file. Once per day Galileo sends you RDFs that contain a list of all of your previous day's transactions and all of your current customers. Compare the RDFs with your own records and if there are discrepancies, treat the RDFs as authoritative.s includes the transaction code as
TRANSACTION CODE/TYPE. The transaction code may be deconstructed to obtain the activity type and transaction type. Use the lookup file included with the RDFs to obtain the transaction code description.
TRANSACTION CODEfield in the Authorized Transactions RDF does not contain the
trans_code. It contains a numeral that specifies the type of authorization that was requested. See the Authorization types list in the Transaction Types enumeration.
On the All Transactions screen in the CSTCST - Customer Service Tool. Software that the Galileo customer service team uses, which is also available to providers, to view and manage customers and their accounts., the Type column contains the activity type description, and the Type field in the Details column contains the transaction type code.
This table summarizes the way transaction codes are represented in the Galileo system.
|Galileo system||Activity type / transaction type|
|Get Account Overview |
Get Transaction History
Get All Transaction History
|Posted Transactions RDF|
|CST||Type column / Type field in the Details column|
Among a transaction’s properties, the most important are amount, timestamp, and the category-specific properties.
amt field indicates how much money is involved in the transaction and specifies which direction the funds are moving: a positive amount means that money is entering the customer account (credit) and a negative amount means that money is leaving the account (debit).
The sign for the amount is represented differently in different Galileo systems.
In the RDFs the
TRANSACTION AMOUNT field is followed by the single-character
TRANSACTION AMOUNT SIGN field, which contains either
- (debit) or
In the Auth API the amount does not have a plus or minus sign. You must determine whether it is positive or negative by the transaction type. First, multiply the amount by –1, then multiply again by –1 for each of these conditions:
transaction_type: Merchant Credit
Amounts that credit a cardholder account have no sign, and amounts that debit an account are are preceded by a hyphen:
Most events have no sign in the
amount field, so you must infer whether the amount is credited or debited by the event type. For example, a
BAUT: auth event is a debit whereas
AAPM: auth_payment is a credit. On the other hand,
FREV: fee_reversal contains a negative number because it is reversing out a fee. These exceptions are noted in each Event description.
Depending on the data source and the activity category, there may be one or two timestamps. If there are two timestamps showing different times, the earlier timestamp shows the time the transaction was initiated and the later timestamp shows when it was posted. For authorization/settlements, the first timestamp is the authorization and the second the settlement. If the two timestamps show the same time it means the transaction was posted immediately.
All Galileo timestamps are in the America/Phoenix time zone (MST -07:00), a time zone that does not observe daylight saving
Other properties of the transaction may be important, depending on which activity category the transaction belongs to. For example,
mcc (merchant category code) is pertinent to authorizations and settlements, and
related_transaction is pertinent to pending fees.
Some transactions pass through multiple phases before completion, such as most card transactions (authorization/settlement), whereas fees are often connected to transactions that may or may not have originated on the card networks. The fields in this table can help you link related transactions.
|Transaction type||Linked to||Linking field|
|Settlement or posting||Authorization or non-network transaction|
The linking fields for authorizations have different names in different systems, but they all contain the same value:
original_auth_id— Get Authorization History, Get Transaction History, Events API
prior_id— Get All Transaction History
original_id— Auth API
- Reversal ID — RDFs (by request) and CSTCST - Customer Service Tool. Software that the Galileo customer service team uses, which is also available to providers, to view and manage customers and their accounts.
related_transaction— Get Pending Fees and Get Account Overview.
The linking fields contain the
auth_id of a previous authorization in these circumstances:
- The merchant performs incremental authorizations for a single purchase. Each authorization has the
auth_idof the previous authorization in the chain.
- An authorization or preauthorization is reversed. The reversal has the
auth_idof the transaction to reverse in the linking field.
- A preauthorization is followed by a completion. The completion contains the
auth_idof the original preauthorization.
- You charge a fee for a card transaction, such as an ATM fee. The fee is broken out separately from the settlement in the Posted Transactions RDF, and the fee entry has the
auth_idof the original authorization. (The original authorization has the fee included in the amount instead of broken out.)
For authorization/settlement transactions the
source_id contain the same value. However, the
source_id for a transaction that does not originate on a card network may or may not have an
auth_id, but when the
auth_id is present, the
source_id is often different, because it maps to the specific transaction type such as a payment ID or fee ID. For example, a Maestro load payment (
trans_code: PMMX) can have an
auth_id in the Authorized Transactions RDF that maps to the
auth_id in the Posted Transactions RDF, but the
source_id is different, because it maps back to the payment ID.
In the CST, the ID field always maps to the
Also see the Transaction sequence examples in the Transaction History guide.
See the Transaction History guide for the various methods to retrieve and maintain an account’s transaction history.
Updated 2 months ago