This guide provides suggestions for creating unique mapping identifiers for the transactions in your records.
As you store your own record of transactions—building off the Events API, Auth API, or RDFs and CDFs, for example—Galileo recommends that you have a way to map authorizations in your database to their respective settlements. With this mapping your customers can see authorized (pending) transactions in a separate list from settled (posted) transactions. See Transaction History for more information. Furthermore, you will need a way to differentiate transaction identifiers from different Galileo sources in your own databases.
For each card network that you implement, 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)
- STAR (MoneyPass, Presto)
Each authorizations table has
auth_id as the primary key (unique identifier for a row in the table). The tables are populated independently as the transactions come in from the networks, and the rows are numbered sequentially, 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, Discover or Pulse transaction.
The Visa and Star tables include all transactions from their respective subnetworks, so a transaction that comes in over Visa credit rails will never have the same
auth_idas an Interlink or Plus transaction. Likewise, a Star transaction will never have the same
auth_idas a MoneyPass or Presto transaction.
For your system, create one designator per authorizations table. (Consult the Network Codes enumeration to see Galileo network identifiers.) You could use a single-letter designator such as
M for Mastercard (credit) and
V for all of the Visa subnetworks, or you could use a spell-out such as
allpoint. You can combine the
auth_id and your network identifier in any way that makes sense to you, for example:
This example assumes that you are mapping
network: V to
network: P to
You receive an Authorization Event message with these values:
Then you receive another Authorization Event message with these values:
Later, you receive a Settlement Event message with these values:
In your database the transactions might look like this:
visa_44444 auth entry also has a settlement entry with the same identifier, you can display that transaction as settled, whereas the
mc_debit_44444 auth has no corresponding settlement, so you would display it as pending.
Transactions that do not take place over card-network rails have their own tables, and each table has an ID that is unique only to that table. These are the non-network transaction tables with their primary key (identifier) field names and their two-letter activity type. (For information on activity types, see Classifying transactions in the About Transactions guide.)
|ACH||PM or AD|
* ACH transactions have two entries: one in the ACH table and one in either the payments or adjustments table, depending on how the funds move.
** Billpay transactions have two entries: one in the billpay table and one in the adjustments table.
If each table has at least 300 transactions, then
adj_id: 300 and
pmt_id: 300 would collide with
auth_id: 300 in many contexts, such as in the
AUTHORIZATION CODE field of the Posted Transactions RDF or in your database. To differentiate between these transaction identifiers, you can use the activity type (
act_type) field or a short descriptor:
Consult the table below to see how the fields discussed in this guide correspond to fields in the RDFs. For an explanation of the Activity type + transaction type column, see Classifying transactions in the About Transactions guide.
|Authorization ID||Network||Activity type + transaction type||Source ID|
|Program API responses|
* The Authorized Transactions RDF has a field called
TRANSACTION CODE that is not the same as
TRANSACTION CODE/TYPE in the Posted Transactions RDF. See Authorization Types for values in the
TRANSACTION TYPE field.
SOURCE ID is a custom field that you must request for the RDFs.
§ See Activity type and transaction type in the Galileo system in the About Transactions guide for instructions on how to derive the activity category from these fields.
§§ The source ID maps to the individual transaction-type identifier, such as
adj_id for adjustments or
pmt_id for payments.
source_id maps to different identifiers depending on which endpoint retrieves the data, as shown in this table:
For more information on the RDFs, see the About RDFs and CDFs guide.
Updated 4 months ago