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 CST.

📘

Note

To see more detailed examples of transaction sequences as they appear in the Program API, Events API, Auth API, and RDFs, see the Card Transaction Scenarios.

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 nor can the funds be spent.

Other network codes

When the example above takes place on other networks, these are the values in the trans_code column.

• For a more detailed example, see Scenario 1: Authorization with Settlement.
• To see how to simulate this transaction in CV go to Three-Step Sequence Simulation.
• 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 nor can the funds be spent.
• 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.

Other network codes

When the example above takes place on other networks, these are the values in the trans_code column.

• For a more detailed example see Scenario 2: Preauthorization with Completion. Also see the Gas pump plus convenience store example.
• To see how to simulate this transaction in CV, go to Five-Step Sequence Simulation.
• 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.

Other network codes

When the example above takes place on other networks, these are the values in the trans_code column. Keep in mind that transactions in a mobile app are card-not-present transactions, and so interbank networks such as Maestro, Interlink and Star would not handle the precise scenario described above. However, incremental authorizations can also happen in card-present contexts.

• For a detailed example of an incremental authorization, see Scenario 3: Incremental Authorizations.
• To see how to simulate this transaction, see Incremental Authorization Simulation.

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.00. Galileo puts a 40.00 hold on the account.
• In the second row, when the cardholder cancels the transaction, the mobile app sends a reversal for 40.00. Galileo releases the 40.00 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.

Other network codes

When the example above takes place on other networks, these are the values in the trans_code column.

• See Full reversal before clearing in the Crediting Cardholder Accounts guide for an explanation of this reversal type.
• To see how to simulate a reversal in CV, see Authorization Reversal Simulation.
• For a detailed example of a full reversal, see these scenarios:
  • 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.00. Galileo places a 15.00 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.00, and so it sends a 5.00 reversal. Galileo removes 5.00 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.00. Galileo expires the 5.00 reversal first before backing out the original 15.00 hold and posting the $10 settlement.

Other network codes

When the example above takes place on other networks, these are the values in the trans_code column.

For a detailed example of a partial reversal, see Scenario 8: Partial Reversal on Preauthorization.

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.

Other network codes

When the example above takes place on other networks, these are the values in the act_type + otype columns.

• For a detailed example of the settlement of an expired authorization, see Scenario 16: Settlement Without Authorization.
• To see how to simulate a force-post in CV, go to Force-Post Simulation.

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.

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. Galileo posts chargebacks and second presentments at the same time, after the dispute is resolved.

Other network codes

When the example above takes place on other networks, these are the values in the trans_code column.

See the About Disputes 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).

Other network codes

When the example above takes place on other networks, these are the values in the trans_code column. The FE0013 would be the same for all networks, depending on your product settings.

• For detailed ATM transaction examples, see these scenarios:
  • Scenario 11: ATM Withdrawal
  • Scenario 12: ATM Reversal
• To see how to simulate an ATM withdrawal in CV, go to ATM Withdrawal, Visa Simulation.

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.00. Galileo places a 75.00 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.00 preauthorization and replaces it with a 45.00 hold.
• 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.00 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.

Other network codes

When the example above takes place on other networks, these are the values in the trans_code column.

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.

Other network codes

When the example above takes place the Visa credit network, these are the values in the Transaction code column. Keep in mind that an Amazon transaction is a card-not-present transaction and so the debit (PIN) networks would not be involved.

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.

Other network codes

When the example above takes place on other networks, these are the values in the trans_code column. Keep in mind that for a Visa Money Transfer there is no entry in the Authorized Transactions RDF.

For a detailed example of a card load, see Scenario 17: Card Load (Maestro).

Instacart deposit reversal

This example shows a reversal of a $225 deposit to a gig-economy worker’s account (using a Maestro load) due to an error on the company’s side. The cardholder has an available balance of $1000 to start.

Authorized Transactions RDF

Posted Transactions RDF

Get All Transaction History Response

• In the Authorized Transaction RDF and Posted Transaction RDF, the reversal amount is expressed as a negative number to represent it is the reversal of a deposit.
• 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 for the original load and the reversal maps to the adj_id.

Other network codes

When the example above takes place on other networks, these are the values in the trans_code column.

For a detailed example of a card load, see Scenario 20: Card Load Reversal (Maestro).

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.

Other network codes

When the example above takes place on other networks, these are the values in the trans_code column.

• For detailed examples of international transactions, see these scenarios:
  • Scenario 13: International Authorization
  • Scenario 14: International Reversal
• To see how to simulate an international transaction, see International Transaction, Visa Simulation.