Transaction IDs

This guide describes how Galileo assigns transaction identifiers and how you can create universally unique identifiers.

Transaction tables

Each type of transaction at Galileo is recorded in a separate table, according to the transaction type, and the primary key for that table is the transaction's ID.

These are the transaction tables that Galileo uses. You will have your own instance of each table in your core, according to what your program supports:

These IDs are generated in sequence, in the order in which the row was added to the table. For this reason, it is possible for an adj_id to be the same number as a pmt_id or for a fee_id to be the same as an auth_id. For that reason, you must find a way to uniquely identify a transaction, as explained further down.

Authorization identifiers

For each card network that you support, Galileo creates an authorizations table. (See Networks for more information.) These are the possible authorizations tables that can be created:

• Mastercard Banknet (credit)
• Mastercard Maestro/Cirrus (debit)
• Visa (credit, Interlink, Plus)
• Allpoint
• STAR (MoneyPass, Presto)
• Discover
• Pulse

Each authorizations table has auth_id as the primary key (which is the unique identifier for a row in the table). The tables are populated independently as the transactions come in from the networks, so it is possible for a transaction in one table to have the same auth_id as a transaction in another table. For example, if there are at least 300 transactions in each of the tables, then auth_id: 300 could refer to a Mastercard, Maestro, Visa, Allpoint, STAR, or Discover transaction.

Authorization vs settlement tables

Authorizations for all of the Visa-affiliated networks (Visa credit, Interlink, Plus) arrive at Galileo through the same connection, and so they populate the same authorization table. Therefore, an auth_id for Interlink will never collide with an auth_id from Pulse. Likewise, the auth_ids for the STAR-affiliated networks (STAR, MoneyPass, Presto) do not collide, because they arrive at Galileo over the same connection.

However, Galileo receives separate settlement batch files from the subnetworks: one from Visa credit, one from Interlink, one from Plus, and one each from STAR, MoneyPass, and Presto. For this reason, the network field of a BAUT: auth or AAAU: auth event message does not necessarily correspond to the network field of the corresponding SETL: setl event. You can see the different codes in the Network Codes table.

Consequently, the settle_detail_id in the SETL: setl event message is unique per settlement batch file, so a settle_detail_id from Interlink can collide with a settle_detail_id from Visa, and a STAR settle_detail_id can collide with a Presto settle_detail_id. However, you should correlate a settle_detail_id with an auth_id rather than using it as a standalone identifier.

Source ID

Because the source ID maps back to an entry in one of the transaction tables, the same rules apply for creating a unique identifier.

Creating a unique identifier

To create a unique transaction ID, combine the ID with the activity type, as shown in this table.

Card network transactions

For example, you would combine auth_id: 5555 with act_type: AU to get AU5555.

^{* The activity type must be derived by combining the network with the transaction_type and correlating it with the Activity Type.}

Other transactions

For example, you would combine pmt_id: 8888 with act_type: PM to get PM8888.

Examples

For examples of creating unique transactions see these sections of Building a Transaction Datastore:

• Authorization mapping
• Mapping non-card-network transactions