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 detailed examples of transaction sequences as they appear in the Program API, Events API, Auth API, and RDFs, consult the Card Transaction Scenarios. Also consult Finding Transaction Data to see where transaction types are visible.

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.

• Row 1 — The initial authorization for 30.00. Galileo places a 30.00 hold on the account.
• Rows 2–3 — Both 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.

• Row 1 — The initial preauthorization with the upcharge. Galileo places a 75.00 hold on the account.
• Rows 2–3 — Both rows have the same timestamp, and they represent the time when the gas has finished pumping. Row 3 is the completion that the pump sends with the actual sale amount, and Row 2 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.
• Rows 4–5 — Both 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. Row 5 is the final settlement amount, and Row 4 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 more examples see:
  • Scenario 2: Preauthorization with Completion
  • Scenario 23: Account Funding Transaction
  • Gas pump plus convenience store
• 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

• Row 1 — The initial authorization for 15.00. Galileo puts a 15.00 hold on the account.
• Rows 2–3 — Both 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. The local_amt field shows the unsigned amount of the increment. Galileo backs out the 15.00 hold and replaces it with a 25.00 hold.
• Rows 4–5 — Both 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. The local_amt field shows the unsigned amount of the increment. Galileo backs out the 25.00 hold and replaces it with a 30.00 hold.
• Rows 6–7 — Both 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.

📘

Note

See Enhanced incremental authorization reporting in the Authorization guide for additional fields that Galileo can enable for you.

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

• Row 1 — The original authorization for –40.00. Galileo puts a 40.00 hold on the account.
• Row 2 — The cardholder cancels the transaction, and 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.
• Rows 3–4 — 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).

• Row 1 — The initial preauthorization for –15.00. Galileo places a 15.00 hold on the account.
• Row 2 — 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.
• Rows 3–5 — All 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.00 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 message 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 messages.

• Row 1 — The BAUT: auth event message when the transaction is initially approved.
• Row 2 — The BEXP: auth_exp event message that is sent seven days later, when the authorization expires.
• Row 3 — The SETL: setl event message 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 is classified as an adjustment by the Galileo system. The merchant credit affects the balance only at settlement time—if the credit arrives through the authorization stream, the account is not credited at that time, although the transaction is visible in the Authorized Transactions RDF. At settlement, Galileo sends a BADJ: adj event instead of SETL: setl. The source_id in the BADJ: adj event contains the settlement detail ID, which is the transaction identifier in the settlement batch file.

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. The credit is not posted to the account when it arrives through the auth stream but is posted during settlement.

Visa

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. The credit is not posted to the account when it arrives through the auth stream but is posted during settlement.

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 event message. The fields might have different names than those shown here.

This example illustrates how a multi-clearing settlement appears through Events API messages, 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 event message with this data:

This is a conventional authorization that arrives over network rails and passes through the Auth API, if used. The BAUT: auth event message 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 event message 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 an event message 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 event message 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 event message 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 not resolved in the cardholder's favor. The initial available balance is $500.

• Rows 1–3 — The original authorization, backout, settlement transaction sequence.
• Rows 4–5 — Both 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 after the second presentment. Galileo posts dispute-related transactions at the same time, after the dispute has been 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

These examples show what typical transactions look like at different types of merchants.

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.

• Row 1 — The initial authorization, which includes the cash amount plus both fees.
• Rows 2–4 — All rows have the same timestamp, which is when Galileo receives a clearing file from Visa. Galileo backs out the original hold in Row 2.
• Row 4 — For the settlement, the ATM operator's fee plus the cash amount are in one settlement (Row 3) and the fee assessed by the Galileo issuer is in another (Row 4).

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.

• Row 1 — The initial preauthorization at the pump for –75.00. Galileo places a 75.00 hold on the account.
• Rows 2–3 — Both 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.
• Row 4 — 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.
• Rows 5–8 — All rows 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

35193. 
       

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.
• Row 1 — Amazon performs an initial check 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.
• Row 2 — Some hours later, Amazon obtains a preauthorization for –25.00. There is a delay between the AVS check and the preauthorization because Amazon, like many high-volume vendors, submits authorizations in batches.
• Rows 3–4 — Both rows happen a day or so later, when Amazon sends a clearing message for the preauthorization, and Galileo backs out the preauthorization amount.
• Rows 5–7 — 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.

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

• The Authorized Transactions RDF shows both transactions as positive amounts. This is an idiosyncrasy of Mastercard card loads. In the Posted Transactions RDF, the reversal amount is expressed as a negative number to represent 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.

• Row 1 — 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.
• Rows 2–3 — Both 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.
• Row 3 — 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.