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.

trans_codeamtauth_idprior_idcredit_indsource_idcalculated_
balance
1AuthAUA-3022330Y2233970
2BackoutBO530NoneNoneNone22331000
3SettleSE5-3022330Y2233970
  • 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.

MaestroVisa creditInterlinkStarDiscoverPulse
1AuthDBAVIAVIASTADCLPUA
2BackoutBDABVABVABSABCLBPA
3SettleSDAVSAISASSASCLSPA

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.

trans_codeamtauth_idprior_idcredit_indsource_idcalculated_
balance
1PreauthVIL-7555660N5566925
2Preauth backoutPVPV75NoneNoneNone55661000
3CompletionVIC-2588995566N8899975
4Completion backoutBVC25NoneNoneNone88991000
5SettleISC-2588995566N8899975
  • 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.

Mastercard BanknetMaestroVisa creditStar
1PreauthAULDBLVILSTL
2Preauth backoutBKBKPBPBPVPVPSPS
3CompletionAUCSDCVICSSC
4Completion backoutBO5BDABVABSA
5SettleSE5SDAVSASSA

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.

trans_codeamtauth_idprior_idcredit_indsource_idcalculated_
balance
1AuthVIA-1544440Y4444485
2Preauth backoutPVPV15NoneNoneNone4444500
3AuthVIA-2555554444Y5555475
4Preauth backoutPVPV-25NoneNoneYNone500
5AuthVIA- 3066665555Y6666470
6BackoutBVA30NoneNoneNone6666500
7SettleVSA-3066665555Y6666470
  • 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. 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. 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. 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.

Mastercard BanknetMaestroInterlinkStar
1AuthAUADBAVIASTA
2Preauth backoutBKBKPBPBPVPVPSPS
3AuthAUADBAVIASTA
4Preauth backoutBKBKPBPBPVPVPSPS
5AuthAUADBAVIASTA
6BackoutBO5BDABVABSA
7SettleSE5SDAISASSA

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.

trans_codeamtauth_idprior_idcredit_indsource_idcalculated_
balance
1AuthAUA-4066770Y6677460
2ReversalAUR4088996677Y8899500
3Expire authEXA4066770Y6677540
4Expire reversalEXR-4088996677Y8899500
  • 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.

MaestroVisa creditInterlinkStar
1AuthDBAVIAVIASTR
2ReversalDBRVIRVIRSSR
3Expire authDXAVXAVXASXA
4Expire reversalDXRVXRVXRSXR

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

trans_codeamtauth_idprior_idcredit_indsource_idcalculated_
balance
1PreauthAUL-1555110Y5511485
2ReversalAUR566330Y6633490
3Expire reversalEXR-5None0None6633485
4BackoutBO515NoneNoneNone5511500
5SettleSE5-1055110Y5511490
  • 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.

MaestroVisa creditInterlinkStar
1PreauthDBLVILVILSSL
2ReversalDBRVIRVIRSSR
3Expire reversalDXRVXRVXRSXR
4BackoutBDABVABVABSA
5SettleSDAVSAICASTA

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.

typeauth_idact_typeotypeamountexpired_auth_idopen_to_buy
1auth9090VIA30470
2auth_exp9090VXA30500
3setl2121ISM309090470
  • 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.

Mastercard BanknetMaestroVisa creditStar
1authAU ADB AVI ASS A
2auth_expEX ADX AVX ASX A
3setlSE 5SD MIS MST M

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.

trans_codeamtauth_idprior_idcredit_indsource_idcalculated_
balance
AdjustmentADC50None0None5511550

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.

trans_codeamtauth_idprior_idcredit_indsource_idcalculated_
balance
1AuthDBZ5044880N4488550
2BackoutBDZ-50NoneNoneNone4488500
3SettleSDZ5044880N4488550

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.

trans_codeamtauth_idprior_idcredit_indsource_idcalculated_
balance
1AuthVIZ5099440N9944550
2BackoutBVZ-50NoneNoneNone9944500
3SettleISZ5099440N9944550

These scenarios provide detailed examples of merchant credits:

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:

auth_idamountresponse_code
22222240000

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:

auth_idbookkeeping
_auth_id
remaining_amountamountoriginal_multi
_clearing_auth_id
222222333333250150222222

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:

auth_idbookkeeping
_auth_id
remaining_amountamountoriginal_multi
_clearing_auth_id
33333344444417575222222

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:

auth_idbookkeeping
_auth_id
remaining_amountamountoriginal_multi
_clearing_auth_id
44444400175222222

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.

trans_codeamtauth_idprior_idcredit_indsource_idcalculated_
balance
1AuthVIA-7011110Y1111430
2BackoutBVA70NoneNoneNone1111500
3SettleVSA-7011110Y1111430
4ChargebackADh7011220None1122500
52nd presentADj-7011330None1133430
  • 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.

Mastercard BanknetMaestroInterlinkPlusStar
1AuthAUADBAVIAVIWSTA
2BackoutBO5BDABVABVWBSA
3SettleSE5SDAISAPLWSSA
4ChargebackADHADdhADhADhADse
52nd presentADIADdjADjADjADSC

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.

trans_codeamtauth_idprior_idcredit_indsource_idcalculated_
balance
1AuthPLW-6322220N2222437
2BackoutBVW63NoneNoneNone2222500
3SettlePLW-6222220N2222438
4FeeFE0013-188882222None8888437
  • 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.

MaestroInterlinkStarMoneyPassPulseAllpointPresto
1AuthDBWVIWSTWSTWPUWAPWSTW
2BackoutBDWBVWBSWBSWBPWABWBSW
3SettleSDWVSWSSWMPWSPWASWPRW

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.

trans_codeamtauth_idprior_idcredit_indsource_idcalculated_
balance
mcc_code
1PreauthDBL-7522770N22774255542
2Preauth backoutPBPB75NoneNoneNone2277500None
3CompletionDBC-4533880N33884555542
4AuthDBA-1244220N44224435541
5Completion backoutBDC45None0None3388488None
6BackoutBDA12None0None4422500None
7SettleSDC-4533880N33884555542
8SettleSDA-1244220N44224435541
  • 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.
  • Row 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

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

Mastercard BanknetVisa creditInterlinkStar
1PreauthAULVILVILSSL
2Preauth backoutBKBKPVPVPVPVPSPS
3CompletionAUCVICVICSSC
4AuthAUAVIAVIASTA
5Completion backoutBOCBVCISCBSC
6BackoutBO5BVABVABSA
7SettleSE5VSCVSCSSC
8SettleSE5VSAISASSA

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.

Transaction codeAmountAVSResponse codeMerchant IDAuth IDBalance
1AVS checkDA00.00Y850000022225599500.00
2PreauthAUL-25.00Y000000022229900475.00
3BackoutBO525.00NoneNone500.00
4SettleSE5-25.000000022229900475.00
5PreauthAUL-50.00Y005550022222211425.00
6BackoutBO550.00NoneNone475.00
7SettleSE5-50.005550022222211425.00
  • 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.
  • Row 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.

Visa
AVS checkDA0
PreauthVIL
BackoutBVA
SettleVSA
PreauthVIL
BackoutBVA
SettleVSA

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

TRANSACTION CODEAUTHORIZATION CODETRANSACTION AMOUNT
289988200.00-

Posted Transactions RDF

TRANSACTION CODE/TYPEAUTHORIZATION CODETRANSACTION AMOUNTSOURCE ID
PMMX9988200.00+2255

Get All Transaction History response

trans_codeamtauth_idprior_idcredit_indsource_idcalculated_
balance
PMMX20099880None2255700
  • 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.

Mastercard BanknetVisa Money Transfer
PMMLPMVT
PMVH

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

TRANSACTION AMOUNTAUTHORIZATION CODETRANSACTION CODEREVERSAL IDTRANSACTION DATE/TIME
225.00+112228001272023 0:05:28
225.00+112328001272023 0:05:29

Posted Transactions RDF

TRANSACTION AMOUNTAUTHORIZATION CODETRANSACTION CODE/TYPESOURCE IDTRANSACTION DATE/TIMEPOST DATE
225.00+1122PMMX66001/27/23 0:05:2801272023
225.00-1123ADMX8991/27/23 0:05:2901272023

Get All Transaction History response

amtauth_idprior_idtrans_codesource_idcalculated_balancecredit_indauth_tspost_ts
22511220PMMX66001225None2023-01-27 00:05:282023-01-27 00:05:28
-22511230ADMX8991000None2023-01-27 00:05:292023-01-27 00:05:29
  • 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.

Mastercard BanknetVisa Money TransferVisa Direct OTC
ADqADyADyt

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.

trans_codeamtauth_idlocal_amtlocal_curr_code
1AuthAUA-39.629999200986
2BackoutBOA39.62NoneNoneNone
3SettleSE5-40.239999200986
  • 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.
  • Row 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.

MaestroVisa
1AuthDBAVIA
2BackoutBDABVA
3SettleSCAVSA