Transaction Types

The transaction type, also called the otype, is a code that is combined with the activity type (act_type) to create a complete transaction code (trans_code). Transaction codes identify where a transaction originated and what kind of transaction it is.

The first two characters of a transaction code are the Activity Type and the remaining characters are the otype. For example:

• SE5 — Mastercard Banknet retail settlement
  • activity type SE (Mastercard Banknet settlement)
  • otype 5 (retail sale)
• VIL — Visa preauthorization
  • activity type VI (Visa authorization)
  • otype L (preauthorization)

See Classifying transactions in the About Transactions guide for more information.

📘

Note

Most payment (PM), adjustment (AD) and fee (FE) otypes are in the Funds Flow document that Galileo provides you. However, some payments and adjustments are triggered by card transactions; those universal otypes are included in the tables below.

To see where these codes are visible, go to Activity type and transaction type in the Galileo system in the About Transactions guide. Additionally, a list of Galileo system fees can be found in About Fees.

Transaction type (otype) lookup

This table provides a quick reference for standalone otypes that are related to card transactions. To see how the otypes combine with the activity types, see Transaction codes. These codes are case-sensitive.

^{* When this otype is present in the type field of the Get All Transaction History response, it is a string. Other numerical otypes (such as for fees) are returned as integers without leading zeros.}

Transaction codes

The tables below show how the activity type combines with the otype to create a transaction code (trans_code). Your program may not use all of the codes shown here. Use the curated list that Galileo gave you to see all of the otypes for your program.

Authorization and settlement

These tables show transaction codes for transactions over card networks. The first table contains the codes associated with transactions that arrive through the authorization stream, and the second contains codes associated with transactions from the settlement batch files.

Authorization stream

See Authorization for more information.

In Program API responses, denied authorizations are DDA for Maestro and DAA for all other networks. DAA can also mean "non-financial transaction."

^§In-person cash withdrawals, not ATMs

Settlement file

See Settlement for more information.

* Includes settlements of both standard auths and completions.
^§ Mastercard merchant credits are processed as adjustments, and ADD is the merchant credit reversal.
^‡ Mastercard settlements (SE) have different codes depending on the type of transaction being settled:

• SE5 — Retail settlement or settled completion
• SE7 — Cash disbursement settlement
• SE8 — Mobile wallet or cash-transfer app settlement

^†Mastercard force-posts use SE5, which is the same code as a normal settlement. To differentiate, call Get All Transaction History or open the All Transactions screen in the CST and find the authorization that corresponds to the SE5 transaction. If the authorization (AUA) and backout (BO5) have the same timestamp as the SE5, then the SE5 is a force post. See Unmatched settlements in the ledger for more information.

Other transaction codes

You may also encounter some of these network-related transaction codes:

• SDV — Maestro reversal debiting balance
• VSV — Visa reversal debiting balance
• VSRW — Visa cash reversal
• VSF, ISF — Visa and Interlink fee collection
• VSJ, ISJ, PLJ — Visa, Interlink and Plus adjustments
• AUM, VIM, STM — Unmatched reversal or completion (AU11 for Mastercard unmatched completion)

Card loads

Card loads that take place on network rails first arrive at Galileo in the auth stream, where they get an authorization table entry, and then they are converted into payments (PM) to post to the cardholder account. Reversals are converted to adjustments (AD).

In the RDFs you will see the Card load auth codes in the AUTH TRANSACTION CODE field and the Card load posted and Card load reversal posted codes in the TRANSACTION CODE/TYPE field.

All of these transaction codes are case-sensitive. See Card loads for more information.

^§ These loads do not arrive at Galileo over card-network rails but rather via special APIs. Do not include these transactions with settlement totals when doing reconciliation.
^‡ For some programs, ADq also means ACH Debit Adjustment. To differentiate between the two transaction types, identify a field that is always populated for ACH transactions only, such as SOURCE TRACE in the Posted Transactions RDF.
* The Visa Money Transfer types are differentiated by the BAI. See the Business Application Identifier enumeration for the definitions.

• VH — AA ,BP, CP, FD, GD, GP, LO, MD, OG, PD
• VT — All other BAIs

Disputes

The dispute-related codes (chargeback, second presentment, exception, arbitration) are valid only when using Galileo's disputes process. All of these transaction codes are case-sensitive. See Transaction codes for disputes in the Disputes at Galileo guide for definitions of the table columns.

These transaction codes apply to all networks:

• ADfd — Final dispute
• ADtc — Temporary credit

Authorization types

These authorization types are derived from DE003 and may be present in the following data sources:

• Authorization Events API webhook messages as auth_tran_type.
• Authorized Transactions RDFs as TRANSACTION CODE
• Posted Transactions RDF as AUTH TRANSACTION CODE

These values are not available from the Program API.