This guide describes general characteristics of transactions in the Galileo system. For an explanation of how card transactions work specifically, consult <a href="doc:about-card-transactions" target="_blank">About Card Transactions</a>.

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, <<glossary:ACH>> 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.

Consult <a href="page:finding-transaction-data" target="_blank">Finding Transaction Data</a> to see where each transaction type is visible.

## Creating transactions

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 <a href="doc:about-card-transactions" target="_blank">About Card Transactions</a> for more information.

    • An external depositing entity, such as an employer making a direct deposit. See <a href="doc:about-ach" target="_blank">About ACH</a> 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 <a href="ref:api-reference-auth-api-about-auth-api" target="_blank">Auth API webhook</a> or the <a href="ref:api-reference-events-api-about-events-api" target="_blank">Events API webhook</a>, obtaining <a href="doc:transaction-history" target="_blank">Transaction History</a> via API, or consuming the daily <<glossary:RDF>>s.

See <a href="doc:about-the-events-api" target="_blank">About the Events API</a> and <a href="doc:about-the-raw-data-files-rdfs" target="_blank">About the Raw Data Files (RDFs)</a> for more information.

## Classifying transactions

Each transaction is classified by its activity category and transaction type, also called the _otype_.

### Activity category

All transactions belongs to one of four activity categories:

  • <a href="doc:about-card-transactions" target="_blank">**Authorization/Settlement**</a> — A transaction that occurs over a card network's rails (system), such as when a cardholder initiates a purchase at a store.

  • <a href="doc:about-payments" target="_blank">**Payment**</a> — 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.

  • <a href="doc:about-adjustments" target="_blank">**Adjustment**</a> — 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.

  • <a href="doc:about-fees" target="_blank">**Fee**</a> — A transaction that charges a cardholder for a particular service, which may originate with the Program API or by an automated process.

Click the link for each category to see details on that category.

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:

CodeActivity type
`AU`Mastercard Banknet authorization
`SE`Mastercard Banknet settlement
`DB`Mastercard debit authorization
`SD`Mastercard debit settlement
`VI`Visa authorization
`VS`Visa settlement
`IS`Visa Interlink settlement
`PL`Visa Plus settlement
`EX`Expired authorization

Non-network activity types are represented as follows:

CodeActivity type
`PM`Payment
`AD`Adjustment
`FE`Fee

Note

For a list of all activity types consult the <a href="ref:api-reference-activity-type" target="_blank">Activity Type</a> enumeration.

### Transaction type

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.

An otype consists of one to four characters, can contain letters or numbers, and is case sensitive. For example, in the adjustment activity category, `DC` is a Discover chargeback whereas `dc` is a direct-load reversal.

An otype is unique only within the activity category. For example, `Z` is a bill-payment check in the adjustment activity category and a merchant credit in the authorization/settlement activity category.

This table contains some authorization/settlement otypes that are common to all networks:

Codeotype
`5`Mastercard Banknet settlement
`8`Mastercard Banknet settlement for mobile wallet or peer-to-peer cash transfer
`A`Retail sale
`B`Balance inquiry
`C`Preauthorization completion
`L`Preauthorization
`R`Reversal
`W`ATM withdrawal
`Z`Refund

See the <a href="ref:api-reference-transaction-types" target="_blank">Transaction Types</a> enumeration for a list of authorization/settlement otypes. For payments, adjustments, and fees, the otypes are in the Funds Flow document that Galileo provides you. You can see your custom otypes in the <<glossary:CST>> under _System Administration > Web Services > Provider Transaction Types_ with Right ID 165.

### Transaction codes

A transaction code (often designated `trans_code`) is a combination of an activity type (the first two characters) and an otype (the remaining characters). This table shows some common transaction codes.

CodeActivity typeotype
`AUA``AU` — Mastercard Banknet authorization`A` — Retail sale
`SE5``SE` — Mastercard Banknet settlement`5` — Settlement
`DBA``DB` — Mastercard debit authorization`A` — Retail sale
`SDA``SD` — Mastercard debit settlement`A` — Retail sale
`VIL``VI` — Visa authorization`L` — Preauthorization
`ISC``IS` — Visa Interlink settlement`C` — Completion
`PMVT``PM` — Payment`VT` — Visa Money Transfer
`ADH``AD` — Adjustment`H` — Chargeback
`FE0013``FE` — Fee`0013` — Domestic ATM withdrawal fee

Because of this structure, a transaction code can be easily deconstructed to obtain the activity type and otype.

### Activity type and transaction type in the Galileo system

The transaction code and its component parts are represented differently by different aspects of the Galileo system.

#### Program API

The program APIs return the transaction code, activity type and otype in these fields:

Endpoint`trans_code``act_type``type`
Get Account OverviewXX
Get Authorization History

X
Get Transaction HistoryXX
Get All Transaction HistoryXXX

Use the `trans_code` for reconciliation with the `TRANSACTION CODE/TYPE` field in the Posted Transactions RDF.

#### Events API

Authorization, Settlement, and Transaction Events messages break out the transaction code into two fields: activity type (`act_type`) and transaction type (`otype`).

#### Auth API

The activity type must be derived from the `auth_type` and `subnetwork` parameters. For example, if `auth_type: Auth` and `subnetwork: Mastercard Debit Switch`, then the activity type is `DB` (Mastercard Debit Authorization).

The otype 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 `B`.

#### RDFs

The Posted Transactions <<glossary:RDF>> includes the transaction code as `TRANSACTION CODE/TYPE`. The transaction code may be deconstructed to obtain the activity type and otype. Use the lookup file included with the RDFs to obtain the transaction code description.

Note

The `TRANSACTION CODE` field 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 <a href="ref:api-reference-transaction-types#authorization-types" target="_blank">Authorization types</a> list in the _Transaction Types_ enumeration.

#### CST

On the _All Transactions_ screen in the <<glossary:CST>>, the **Type** column contains the activity type description, and the **Type** field in the **Details** column contains the otype.

This table summarizes the way transaction codes are represented in the Galileo system.

Galileo systemActivity type / otype
Get Account Overview <br>Get Transaction History <br>Get All Transaction History`trans_code`
Events API`act_type` / `otype`
Auth API`subnetwork`+ `transaction_type`
Posted Transactions RDF`TRANSACTION CODE/TYPE`
CST**Type** column / **Type** field in the **Details** column

## Transaction properties

Among a transaction’s properties, the most important are the identifier, amount, timestamp, and the category-specific properties.

### Identifier

Galileo transaction IDs are integers, sequentially assigned according to the transaction type. See <a href="doc:transaction-ids" target="_blank">Transaction IDs</a> for an explanation of how Galileo assigns IDs and how to devise unique identifiers for your system.

### Amount

The `amount` or `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.

#### RDFs

In the standard RDFs the `TRANSACTION AMOUNT` field is followed by the single-character `TRANSACTION AMOUNT SIGN` field, which contains either `-` (debit) or `+` (credit). In the extended RDFs, the sign follows the amount and is in the same `TRANSACTION AMOUNT` field as the amount, for example: `30.25-` for a debit or `23.67+` for a credit.

#### Auth API

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:

  • `auth_type: Reversal`

  • `transaction_type: Merchant Credit`

  • `transaction_type: Payment`

#### Program API

Amounts that credit a cardholder account have no sign, and amounts that debit an account are are preceded by a hyphen: `35.41` and `-254.78`.

#### Events API

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 <a href="ref:api-reference-events-api-auth" target="_blank">`BAUT: auth`</a> event is a debit whereas <a href="ref:api-reference-events-api-auth-payment" target="_blank">`AAPM: auth_payment`</a> is a credit. On the other hand, <a href="ref:api-reference-events-api-fee-reversal" target="_blank">`FREV: fee_reversal`</a> contains a negative number because it is reversing out a fee. These exceptions are noted in each Event description.

### Timestamp

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.

Note

All Galileo timestamps are in the America/Phoenix time zone (MST -07:00), a time zone that does not observe daylight saving

### Category-specific properties

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.

## Linking transactions

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 typeLinked toLinking field
AuthorizationAuthorization`original_auth_id`<br>`prior_id`<br>`original_id`<br>Reversal ID
Settlement or postingAuthorization or non-network transaction`auth_id`<br>`source_id`
FeeAny transaction`related_transaction`

The linking fields for authorizations have different names in different systems, but they all contain the same value:

  • **`original_auth_id`** — <a href="ref:post_getauthhistory" target="_blank">Get Authorization History</a>, <a href="ref:post_gettranshistory" target="_blank">Get Transaction History</a>, Events API

  • **`prior_id`** — <a href="ref:post_getalltranshistory" target="_blank">Get All Transaction History</a>

  • **`original_id`** — Auth API

  • **Reversal ID**<<glossary:CST>>

  • **`related_transaction`** — <a href="ref:post_getpendingfees" target="_blank">Get Pending Fees</a> and <a href="ref:post_getaccountoverview" target="_blank">Get Account Overview</a>.

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_id` of the previous authorization in the chain.

  • An authorization or preauthorization is reversed. The reversal has the `auth_id` of the transaction to reverse in the linking field.

  • A preauthorization is followed by a completion. The completion contains the `auth_id` of 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_id` of the original authorization. (The original authorization has the fee included in the amount instead of broken out.)

For authorization/settlement transactions the `auth_id` and `source_id` contain the same value. For a transaction that does not originate on a card network, the `auth_id` may or may not be present. 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. See <a href="page:scenario-17-card-load-maestro" target="_blank">Scenario 17: Card Load (Maestro)</a> for an example.

In the CST, the **ID** field always maps to the `source_id`.

In the <a href="doc:base-rdfs#posted-transactions-rdf-fields" target="_blank">Base RDFs</a>, the mapping is as follows:

  • `PRIOR ID` — Contains the payment, adjustment, or fee that links to the current transaction.

  • `REVERSAL ID` — Contains the `AUTHORIZATION CODE` of the previous authorization in the series.

For examples of linking fields in use, see these card transaction scenarios:

  • <a href="page:scenario-2-preauthorization-with-completion" target="_blank">Scenario 2: Preauthorization with Completion</a>

  • <a href="page:scenario-3-incremental-authorizations" target="_blank">Scenario 3: Incremental Authorizations</a>

  • <a href="page:scenario-4-reversal-on-authorization-before-clearing-mastercard" target="_blank">Scenario 4: Reversal on Authorization Before Clearing (Mastercard)</a>

  • <a href="page:scenario-5-reversal-on-preauthorization-before-clearing-visa" target="_blank">Scenario 5: Reversal on Preauthorization Before Clearing (Visa)</a>

  • <a href="page:scenario-12-atm-reversal" target="_blank">Scenario 12: ATM Reversal</a>

## Blocking transactions

Depending on the use case for a particular product, you may want to block certain types of transactions from taking place, or you can block transactions depending on the status of the account. In some cases you need to set product parameters for the block, and in other cases you use the Program API.

### Card transactions

You can block card transactions using a variety of methods, depending on the type to block.

#### All card transactions

The fastest way to block all card transactions is to <a href="doc:card-statuses#freezing-cards" target="_blank">put a freeze on the card</a>. Such a block does not affect ACH, billpay, Program API transactions, or fees.

#### PIN or signature transactions

You might decide that you want to block all PIN transactions or all signature (non-PIN) transactions. The PBLOK parameter controls this kind of block.

#### Card loads

Card loads that arrive over network rails are blocked by default, and so they must be enabled by setting one or more of these parameters:

  • **DCLD** — Discover loads

  • **MCLD** — Mastercard and Maestro loads

  • **STRLD** — STAR loads

  • **VSALD** — Visa ReadyLink and Visa Money Transfers

After you have enabled any of these card loads, you can block the loads by <a href="ref:api-reference-account-statuses" target="_blank">account status</a> by populating the BLKLD parameter with the statuses to block.

#### Transaction types

You can block various transaction types using the <a href="ref:post_setaccountfeature" target="_blank">Set Account Feature</a> endpoint.

Transaction to block`featureType``featureValue`
Card not present`6``N`
Card not present and card present (allow mobile wallet only)`20``Y`
Card present`21``Y`
Mobile wallet`22``Y`
ATM withdrawals`9``Y`
Cash advances`10``Y`

#### By MCC

Blocking by <<glossary:MCC>> means that when an authorization request arrives for a card transaction, Galileo checks the MCC, and if the MCC is on your blocklist, Galileo denies the transaction.

You can set an MCC block in these ways:

  • During initial product configuration. The MCC block applies to all cards with that `prod_id`.

  • On a per-account basis, using <a href="doc:designing-authorization-controls#mcc-controls" target="_blank">Account-Level Authorization Controls</a>. These account-level controls are applied in addition to the product-level controls.

#### By merchant ID

To block transactions from a particular merchant, you can block the merchant ID, which identifies a specific point of sale. You can create merchant ID blocks during product setup, or if you are using Galileo's fraud-detection engine, merchant ID blocks will be added automatically. To apply a merchant ID block at the account level, use <a href="doc:designing-authorization-controls#merchant-id-controls" target="_blank">Account-Level Authorization Controls</a>, which override product-level MCC and merchant ID controls.

#### By country

During initial product setup you can determine which transactions to block by originating country code, such as <<glossary:OFAC>> countries. You can also set the BLKTM parameter to block transactions from those countries only at certain times of day. With the NOBLK parameter you can specify which country codes should never be blocked.

To block all international transactions for an account, call <a href="ref:post_setaccountfeature" target="_blank">Set Account Feature</a> with these parameters:

  • `featureType` — 8

  • `featureValue` — N

Consult <a href="doc:about-card-transactions#international-merchants" target="_blank">International merchants</a> in _About Card Transactions_ for information on how a transaction is considered to be domestic or international.

### API-based money movement

To block transactions that are initiated by the Program API (<a href="ref:post_createpayment" target="_blank">Create Payment</a>, <a href="ref:post_createadjustment" target="_blank">Create Adjustment</a>, <a href="ref:post_createaccounttransfer" target="_blank">Create Account Transfer</a>), input the account statuses in the STPLD product parameter. You can input all possible <a href="ref:api-reference-account-statuses" target="_blank">account statuses</a>, or you can input a subset.

### ACH transactions

If your program supports ACH transactions, you can block ACH transactions as follows:

Transaction to blockHow to block
Incoming ACH credit (funds going into the customer account)Set ACCRD
Incoming ACH debit (funds going out of the customer account)Set ACDBT
Incoming ACH credit by account statusPopulate ACSTS with the statuses to block
Incoming ACH debit on an inactive accountSet ACHCA to stop the debit when the account is not in `status: N`.

## Transaction history

See the <a href="doc:transaction-history" target="_blank">Transaction History</a> guide for the method to retrieve an account’s transaction history.