Card Transaction Examples

This page contains examples for concepts that are explained in these guides:

• About Card Transactions — A general overview of how card transactions work, including the phases that a card transaction passes through.
• Authorization — An explanation of authorization and its variants.
• Settlement — An explanation of settlement and clearing.
• Crediting Cardholder Accounts — An explanation of transactions that return funds to the cardholder account.

Except where otherwise noted, these examples show card transaction sequences as they appear in Get All Transaction History responses. These same sequences are available in the CSTCST - Customer Service Tool. Software that the Galileo customer service team uses, which is also available to providers, to view customers and their accounts..

📘

Note

To see more detailed examples of transaction sequences as they appear in the Program API, Events API, Auth API, and 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, ask for the Card Transaction Scenarios PDF from Galileo.

Three-step sequence

The most common transaction sequence has three steps: authorization or preauthorization, backout, and settlement.

Assuming an available balance of $1000, a retail merchant, and Mastercard Banknet (credit) rails, this is how a purchase of $30 might appear.

• The top row is the initial authorization for 30.00. Galileo places a 30.00 hold on the account.
• The second and third rows have the same timestamp and show the authorization backout (BO5) immediately before its settlement (SE5). The momentary increase to the balance happens on the ledger but is not perceptible to the cardholder.

For a more detailed example, see "Scenario 1: Authorization with settlement" in the Card Transaction Scenarios PDF.

Also see this Recipe for an explanation of the fields in a Get All Transaction History response:

Five-step sequence

In the case of gas pumps and some other merchants, the transaction sequence has five steps: preauthorization, preauthorization backout, completion, completion backout, and settlement.

For a preauthorization with completion at a gas pump, Visa Interlink (debit) rails, and an upcharge of $75, this is how a $25 purchase might appear, assuming $1000 available balance at the beginning of the purchase.

• The top row is the initial preauthorization with the upcharge. Galileo places a 75.00 hold on the account.
• The second and third rows have the same timestamp, and they represent the time when the gas has finished pumping. The third row is the completion that the pump sends with the actual sale amount, and the second row is the preauthorization backout immediately before. The hold on the account is now 25.00. The momentary increase to the balance from the backout happens on the ledger but is not perceptible to the cardholder.
• The fourth and fifth rows have the same timestamp a day or so later, when the settlement batch file arrives at Galileo and Galileo matches the clearing message to the completion. The fifth row is the final settlement amount and the fourth row is the backout immediately before. The momentary increase to the balance happens on the ledger but is not perceptible to the cardholder.

For a more detailed example see "Scenario 2. Preauthorization with completion" in the Card Transaction Scenarios PDF. Also see the Gas pump plus convenience store example.

Also see this Recipe for an explanation of the fields in a Get All Transaction History response:

Incremental authorization

In this example, a ride-share app gets an authorization for $15, then after arriving at the first destination the cardholder asks for a second destination, which is an additional $10. After arriving at the second destination the cardholder asks for a third destination for $5. The network is Visa credit.

• The top row is the initial authorization for 15.00. Galileo puts a 15.00 hold on the account.
• The second and third rows have the same timestamp, and they represent the time that the cardholder asks for the second destination. The app sends an authorization request for the cumulative amount and indicates that it is an incremental authorization. Galileo backs out the 15.00 hold and replaces it with a 25.00 hold.
• The fourth and fifth rows have the same timestamp, and they represent the time that the cardholder asks for the third destination. The app sends an authorization request for the cumulative amount and indicates that it is an incremental authorization. Galileo backs out the 25.00 hold and replaces it with a 30.00 hold.
• The sixth and seventh rows have the same timestamp and they represent time when Galileo receives the settlement batch file, matches the settlement to the final authorization, backs out the 30.00 hold, and debits 30.00 from the account.
• The prior_id field (called original_auth_id, original_id, or reversal ID in other contexts) for each incremental authorization contains the auth_id of the previous authorization in the series.

For a detailed example of an incremental authorization, see "Scenario 3: Incremental authorizations with settlement" in the Card Transaction Scenarios PDF.

Authorization reversal and expiry

In this example the cardholder makes a purchase in a mobile app for $40 but cancels it a few minutes later. The cardholder has a $500 available balance before the transaction, and it takes place over Mastercard Banknet rails.

• The first row shows the original authorization for $40. Galileo puts a $40 hold on the account.
• In the second row, when the cardholder cancels the transaction, the mobile app sends a reversal for $40. Galileo releases the $40 hold.
• The merchant never sends a clearing message for the transaction because the authorization and reversal are for the same amount.
• The third and fourth rows show that after the configured amount of time, both the authorization and its reversal expire.

See Full reversal before clearing in the Crediting Cardholder Accounts guide for an explanation of this reversal type.

For a detailed example of a full reversal see these scenarios in the Card Transaction Scenarios PDF:

• Scenario 4: Reversal on authorization before clearing (Mastercard)
• Scenario 5: Reversal on preauthorization before clearing (Visa)

Partial reversal and expiry

This example shows a cardholder using a ride-share app. At the beginning of a ride, the app obtains a $15 preauthorization and then settles the actual amount ($10) at the end of the ride. The cardholder has an available balance of $500 prior to the ride. The network is Mastercard Banknet (credit).

• The first row is the initial preauthorization for $15. Galileo places a $15 hold on the account.
• The second row represents the end of the ride, when the ride-share app determines that the actual cost of the ride is $10, and so it sends a $5 reversal. Galileo removes $5 from the hold.
• The third, fourth and fifth rows have the same timestamp one or two days later, and they represent Galileo receiving the clearing message for $10. Galileo expires the $5 reversal first before backing out the original $15 hold and posting the $10 settlement.

For a detailed example of a partial reversal, see "Scenario 8: Partial reversal on preauthorization" in the Card Transaction Scenarios PDF.

Settlement of an expired authorization

This example shows a settlement that posts for an authorization that has expired. The auth_id of the expired authorization is provided in the expired_auth_id field in the SETL: setl event webhook and the EXPIRED AUTH CODE field of the Posted Transactions RDF. Both of these fields must be enabled by request. If you do not enable these fields, there is no identifier to link the expired authorization with its settlement; instead, you must infer the relationship by comparing other values such as the amount and the merchant ID.

The transaction is over Visa Interlink rails for $30. The initial available balance is $500, the authorization expires after seven days, and the settlement arrives at Galileo after 10 days.

This table shows fields in the Events API webhooks.

• The first row shows the BAUT: auth event webhook when the transaction is initially approved.
• The second row shows the BEXP: auth_exp event webhook that is sent seven days later, when the authorization expires.
• The third row shows the SETL: setl event webhook that is sent 10 days after the initial authorization, when the clearing message arrives at Galileo in the settlement batch file. Because the authorization had expired, Galileo creates a new authorization entry, backs it out, and posts the settlement. The SETL: setl event has a new auth_id but includes the auth_id of the expired authorization in expired_auth_id.

For a detailed example of the settlement of an expired authorization, see "Scenario 16: Settlement without Authorization" in the Card Transaction Scenarios PDF (version 1.1 or later for the new fields).

Merchant credit

See Merchant credits in the Crediting Cardholder Accounts guide for an explanation of merchant credit.

These examples show a $50 merchant credit from different networks, assuming a starting balance of $500.

Mastercard Banknet

A Mastercard Banknet (credit) merchant credit does not have an authorization record, and it is classified as an adjustment by the Galileo system. For this reason, Galileo sends both a SETL: setl event webhook and a BADJ: adj webhook when the merchant credit is settled.

Mastercard Maestro

For a Mastercard Maestro (debit) merchant credit there is an authorization record for a positive amount that is backed out when the settlement arrives.

Visa Interlink

Similar to Mastercard Maestro, for a Visa merchant credit there is an authorization record for a positive amount that is backed out when the settlement arrives.

In the Card Transaction Scenarios PDF, these scenarios provide detailed examples of merchant credits:

• Scenario 6: Refund after clearing (Visa)
• Scenario 7: Refund after clearing (Mastercard Banknet)

Incremental clearing

See Incremental clearing in the Settlement guide for an explanation of this example, including an explanation of what a bookkeeping authorization record is.

To link bookkeeping authorization records with the original preauthorization, Galileo uses these fields:

• original_multiclearing_auth_id — The auth_id of the original preauthorization that arrived over network rails.
• bookkeeping_auth_id — The auth_id of the bookkeeping authorization record that is next in the series.
• remaining_amount — The amount of the preauthorization that has not been cleared yet.

Existing clients must request that these fields be enabled for the SETL: setl Events API webhook. The fields might have different names than those shown here.

This example illustrates how a multi-clearing settlement appears through Events API webhooks, assuming that the multi-clearing fields have been enabled. Also see the Amazon transaction example for an alternative way for a merchant to handle multiple items in an order.

Original preauthorization

When the merchant obtains the preauthorization for the full sale amount, Galileo sends the BAUT: auth webhook with this data:

This is a conventional authorization that arrives over network rails and passes through the Auth API, if used. The BAUT: auth webhook does not indicate that this transaction will have multiple clearings.

First clearing

The first clearing for $150 arrives in a settlement batch file from the network. An indicator in the clearing message shows that this is not the final clearing. Galileo sends a SETL: setl webhook with this data:

Because the bookkeeping_auth_id field is populated, you know that Galileo has created a bookkeeping authorization record for the remaining $250 and that its auth_id is 333333. Galileo does not send a webhook to notify that a bookkeeping record has been created, and the bookkeeping records are not present in the RDFs. The original preauthorization amount is backed out before the bookkeeping authorization record is created.

Second clearing

The second clearing for $75 arrives in a settlement batch file from the network. An indicator in the clearing message shows that this is not the final clearing. Galileo sends a SETL: setl webhook with this data:

With the value in original_multi_clearing_auth_id you can link this settlement to the original preauthorization.

Final clearing

The final clearing for $175 arrives in a settlement batch file from the network. An indicator in the clearing message shows that this is the last clearing. Galileo sends a SETL: setl webhook with this data:

Because the bookkeeping_auth_id field is zero, you know that this is the last clearing for the transaction. If there were any remaining amount, it would expire after the configured time and be returned to the cardholder account.

Disputes

This example shows a chargeback and a second presentment over Visa rails for a disputed transaction of $70 that was resolved in the merchant's favor. The initial available balance is $500.

• The first three rows show the original authorization, backout, settlement transaction sequence.
• The fourth and fifth rows have the same timestamp and show the chargeback amount (ADh) and the second presentment amount (ADj). The second presentment is present because the dispute was resolved in the merchant's favor. In this case, Galileo posts the chargeback amount at the same time as the second presentment because they both arrived in the same batch settlement file.

See Disputes in the Crediting Cardholder Accounts guide for more information.

Examples by merchant type

ATM withdrawal

In this example the cardholder inputs $60 as the withdrawal amount. The ATM operator assesses a $2 fee per transaction, and the Galileo issuer assesses an additional $1 fee. The network is Visa Plus, and the cardholder has a $500 available balance.

• The top row shows the initial authorization, which includes the cash amount plus both fees.
• The second, third, and fourth rows have the same timestamp, which is when Galileo receives a clearing file from Visa. Galileo backs out the original hold in the second row.
• For the settlement, the ATM operator's fee plus the cash amount are in one settlement (third row) and the fee assessed by the Galileo issuer is in another (fourth row).

For detailed ATM transaction examples, see these scenarios in the Card Transaction Scenarios PDF:

• Scenario 11: ATM withdrawal
• Scenario 12: ATM reversal

Gas pump plus convenience store

Cardholders frequently make purchases at the convenience store where they pump gas. These sample transactions assume Mastercard Maestro (debit) rails, a $75 upcharge, $45 total at the pump, $12 at the convenience store, and a starting available balance of $500.

• The first row is the initial preauthorization at the pump for $75. Galileo places a $75 hold on the account.
• The second and third rows have the same timestamp a few minutes later, which represents the time when the gas transaction has finished and the pump sends a completion message. Galileo backs out the $75 preauthorization and debits $45 from the account.
• The fourth row is the authorization for the purchase inside the convenience store, a few minutes after the gas finishes pumping. Galileo places an additional $12 hold on the account.
• The remaining rows all have the same timestamp a day or two later, when Galileo receives the clearing file from Mastercard. Both the gas and convenience store debits are backed out and then replaced by the completion (SDC) and the settlement (SDA), respectively.

Amazon transaction

This example shows an Amazon transaction for two items, one of which ($25) is fulfilled by Amazon and the other ($50) by a third-party vendor. The cardholder has an available balance of $500 at the time the transaction is initiated and the transaction takes place over Mastercard Banknet (credit) rails.

This is only one possible way for a merchant to conduct a transaction with multiple parts. See the Incremental clearing example for an alternative.

• The information in the AVS and Response code columns is visible in the Authorized Transactions RDF.
• The merchant ID is available in the Authorized Transactions and Posted Transactions RDFs as well as responses from the Program API.
• The top row is the initial check that Amazon performs to ensure that the card is valid. AVS response Y means that both the address and Zip code matched, and response code 85 for an AVS check means success.
• The second row shows that some hours later, Amazon obtains a preauthorization for $25. There is a delay between the AVS check and the preauthorization because Amazon, like many high-volume vendors, submits authorizations in batches.
• The third and fourth rows happen a day or so later, when Amazon sends a clearing message for the preauthorization and Galileo backs out the preauthorization amount.
• The remaining rows show that when fulfilling its part of the order at a later time, the third-party vendor gets a separate preauthorization for $50, and then settles it in the usual manner.

Uber payment

The tables below show a $200 payment from Uber into a driver's account (available balance $500) using a Maestro load. Keep in mind that with payments, the authorization ID (if present) may not be the same as the source ID.

Authorized Transactions RDF

Posted Transactions RDF

Get All Transaction History response

• The record in the Authorized Transactions RDF shows the amount to load as a negative number, even though it is a payment into the account. These authorization entries are present for Mastercard loads but not Visa loads.
• Although there is a record in the Authorized Transactions RDF, there is no corresponding authorization record in the CST or the Program API responses, because there was no actual authorization—there is no authorization hold or subsequent backout. Only the settled payment is returned by the Program API and CST.
• In the CST the ID field corresponds to the source ID.
• The source_id maps to the pmt_id in the payments table.

For a detailed example of a card load, see "Scenario 17: Card load (Maestro)" in the Card Transaction Scenarios PDF.

International transaction

In this example a U.S. resident cardholder with a $500 available balance goes to Brazil and purchases items worth 200 Brazilian reals. This transaction takes place over Mastercard Banknet (credit) rails.

• The top row shows the original authorization for USD$39.62. The local_amt field plus local_curr_code shows that the amount at the merchant site is 200 Brazilian reals.
• The second and third rows have the same timestamp, which is when the clearing file arrives from Mastercard a few days later. Galileo backs out the original authorization amount.
• The clearing amount is still the U.S. dollar equivalent of R$200, but because the exchange rate has changed since authorization, the clearing amount is different from the authorization amount.

For detailed examples of international transactions, see these scenarios in the Card Transaction Scenarios PDF:

• Scenario 13: International authorization
• Scenario 14: International reversal