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_code | amt | auth_id | prior_id | credit_ind | source_id | calculated_ balance | ||
---|---|---|---|---|---|---|---|---|
1 | Auth | AUA | -30 | 2233 | 0 | Y | 2233 | 970 |
2 | Backout | BO5 | 30 | None | None | None | 2233 | 1000 |
3 | Settle | SE5 | -30 | 2233 | 0 | Y | 2233 | 970 |
- 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.
Maestro | Visa credit | Interlink | Star | Discover | Pulse | ||
---|---|---|---|---|---|---|---|
1 | Auth | DBA | VIA | VIA | STA | DCL | PUA |
2 | Backout | BDA | BVA | BVA | BSA | BCL | BPA |
3 | Settle | SDA | VSA | ISA | SSA | SCL | SPA |
- 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.
trans_code | amt | auth_id | prior_id | credit_ind | source_id | calculated_ balance | ||
---|---|---|---|---|---|---|---|---|
1 | Preauth | VIL | -75 | 5566 | 0 | N | 5566 | 925 |
2 | Preauth backout | PVPV | 75 | None | None | None | 5566 | 1000 |
3 | Completion | VIC | -25 | 8899 | 5566 | N | 8899 | 975 |
4 | Completion backout | BVC | 25 | None | None | None | 8899 | 1000 |
5 | Settle | ISC | -25 | 8899 | 5566 | N | 8899 | 975 |
- 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 Banknet | Maestro | Visa credit | Star | ||
---|---|---|---|---|---|
1 | Preauth | AUL | DBL | VIL | STL |
2 | Preauth backout | BKBK | PBPB | PVPV | PSPS |
3 | Completion | AUC | SDC | VIC | SSC |
4 | Completion backout | BO5 | BDA | BVA | BSA |
5 | Settle | SE5 | SDA | VSA | SSA |
- For more examples see:
- 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.
trans_code | amt | auth_id | prior_id | credit_ind | source_id | calculated_ balance | ||
---|---|---|---|---|---|---|---|---|
1 | Auth | VIA | -15 | 4444 | 0 | Y | 4444 | 485 |
2 | Preauth backout | PVPV | 15 | None | None | None | 4444 | 500 |
3 | Auth | VIA | -25 | 5555 | 4444 | Y | 5555 | 475 |
4 | Preauth backout | PVPV | -25 | None | None | Y | None | 500 |
5 | Auth | VIA | - 30 | 6666 | 5555 | Y | 6666 | 470 |
6 | Backout | BVA | 30 | None | None | None | 6666 | 500 |
7 | Settle | VSA | -30 | 6666 | 5555 | Y | 6666 | 470 |
- 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 (calledoriginal_auth_id
,original_id
, or reversal ID in other contexts) for each incremental authorization contains theauth_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 Banknet | Maestro | Interlink | Star | ||
---|---|---|---|---|---|
1 | Auth | AUA | DBA | VIA | STA |
2 | Preauth backout | BKBK | PBPB | PVPV | PSPS |
3 | Auth | AUA | DBA | VIA | STA |
4 | Preauth backout | BKBK | PBPB | PVPV | PSPS |
5 | Auth | AUA | DBA | VIA | STA |
6 | Backout | BO5 | BDA | BVA | BSA |
7 | Settle | SE5 | SDA | ISA | SSA |
- 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.
trans_code | amt | auth_id | prior_id | credit_ind | source_id | calculated_ balance | ||
---|---|---|---|---|---|---|---|---|
1 | Auth | AUA | -40 | 6677 | 0 | Y | 6677 | 460 |
2 | Reversal | AUR | 40 | 8899 | 6677 | Y | 8899 | 500 |
3 | Expire auth | EXA | 40 | 6677 | 0 | Y | 6677 | 540 |
4 | Expire reversal | EXR | -40 | 8899 | 6677 | Y | 8899 | 500 |
- 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.
Maestro | Visa credit | Interlink | Star | ||
---|---|---|---|---|---|
1 | Auth | DBA | VIA | VIA | STR |
2 | Reversal | DBR | VIR | VIR | SSR |
3 | Expire auth | DXA | VXA | VXA | SXA |
4 | Expire reversal | DXR | VXR | VXR | SXR |
- 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:
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_code | amt | auth_id | prior_id | credit_ind | source_id | calculated_ balance | ||
---|---|---|---|---|---|---|---|---|
1 | Preauth | AUL | -15 | 5511 | 0 | Y | 5511 | 485 |
2 | Reversal | AUR | 5 | 6633 | 0 | Y | 6633 | 490 |
3 | Expire reversal | EXR | -5 | None | 0 | None | 6633 | 485 |
4 | Backout | BO5 | 15 | None | None | None | 5511 | 500 |
5 | Settle | SE5 | -10 | 5511 | 0 | Y | 5511 | 490 |
- 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.
Maestro | Visa credit | Interlink | Star | ||
---|---|---|---|---|---|
1 | Preauth | DBL | VIL | VIL | SSL |
2 | Reversal | DBR | VIR | VIR | SSR |
3 | Expire reversal | DXR | VXR | VXR | SXR |
4 | Backout | BDA | BVA | BVA | BSA |
5 | Settle | SDA | VSA | ICA | STA |
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.
type | auth_id | act_type | otype | amount | expired_auth_id | open_to_buy | |
---|---|---|---|---|---|---|---|
1 | auth | 9090 | VI | A | 30 | 470 | |
2 | auth_exp | 9090 | VX | A | 30 | 500 | |
3 | setl | 2121 | IS | M | 30 | 9090 | 470 |
- 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. TheSETL: setl
event has a newauth_id
but includes theauth_id
of the expired authorization inexpired_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 Banknet | Maestro | Visa credit | Star | ||
---|---|---|---|---|---|
1 | auth | AU A | DB A | VI A | SS A |
2 | auth_exp | EX A | DX A | VX A | SX A |
3 | setl | SE 5 | SD M | IS M | ST M |
- 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.
trans_code | amt | auth_id | prior_id | credit_ind | source_id | calculated_ balance | |
---|---|---|---|---|---|---|---|
Adjustment | ADC | 50 | None | 0 | None | 5511 | 550 |
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_code | amt | auth_id | prior_id | credit_ind | source_id | calculated_ balance | ||
---|---|---|---|---|---|---|---|---|
1 | Auth | DBZ | 50 | 4488 | 0 | N | 4488 | 550 |
2 | Backout | BDZ | -50 | None | None | None | 4488 | 500 |
3 | Settle | SDZ | 50 | 4488 | 0 | N | 4488 | 550 |
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_code | amt | auth_id | prior_id | credit_ind | source_id | calculated_ balance | ||
---|---|---|---|---|---|---|---|---|
1 | Auth | VIZ | 50 | 9944 | 0 | N | 9944 | 550 |
2 | Backout | BVZ | -50 | None | None | None | 9944 | 500 |
3 | Settle | ISZ | 50 | 9944 | 0 | N | 9944 | 550 |
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
— Theauth_id
of the original preauthorization that arrived over network rails.bookkeeping_auth_id
— Theauth_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_id | amount | response_code |
---|---|---|
222222 | 400 | 00 |
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_id | bookkeeping _auth_id | remaining_amount | amount | original_multi _clearing_auth_id |
---|---|---|---|---|
222222 | 333333 | 250 | 150 | 222222 |
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_id | bookkeeping _auth_id | remaining_amount | amount | original_multi _clearing_auth_id |
---|---|---|---|---|
333333 | 444444 | 175 | 75 | 222222 |
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_id | bookkeeping _auth_id | remaining_amount | amount | original_multi _clearing_auth_id |
---|---|---|---|---|
444444 | 0 | 0 | 175 | 222222 |
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_code | amt | auth_id | prior_id | credit_ind | source_id | calculated_ balance | ||
---|---|---|---|---|---|---|---|---|
1 | Auth | VIA | -70 | 1111 | 0 | Y | 1111 | 430 |
2 | Backout | BVA | 70 | None | None | None | 1111 | 500 |
3 | Settle | VSA | -70 | 1111 | 0 | Y | 1111 | 430 |
4 | Chargeback | ADh | 70 | 1122 | 0 | None | 1122 | 500 |
5 | 2nd present | ADj | -70 | 1133 | 0 | None | 1133 | 430 |
- 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 Banknet | Maestro | Interlink | Plus | Star | ||
---|---|---|---|---|---|---|
1 | Auth | AUA | DBA | VIA | VIW | STA |
2 | Backout | BO5 | BDA | BVA | BVW | BSA |
3 | Settle | SE5 | SDA | ISA | PLW | SSA |
4 | Chargeback | ADH | ADdh | ADh | ADh | ADse |
5 | 2nd present | ADI | ADdj | ADj | ADj | ADSC |
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_code | amt | auth_id | prior_id | credit_ind | source_id | calculated_ balance | ||
---|---|---|---|---|---|---|---|---|
1 | Auth | PLW | -63 | 2222 | 0 | N | 2222 | 437 |
2 | Backout | BVW | 63 | None | None | None | 2222 | 500 |
3 | Settle | PLW | -62 | 2222 | 0 | N | 2222 | 438 |
4 | Fee | FE0013 | -1 | 8888 | 2222 | None | 8888 | 437 |
- 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.
Maestro | Interlink | Star | MoneyPass | Pulse | Allpoint | Presto | ||
---|---|---|---|---|---|---|---|---|
1 | Auth | DBW | VIW | STW | STW | PUW | APW | STW |
2 | Backout | BDW | BVW | BSW | BSW | BPW | ABW | BSW |
3 | Settle | SDW | VSW | SSW | MPW | SPW | ASW | PRW |
- For detailed ATM transaction examples, see these scenarios:
- 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.
trans_code | amt | auth_id | prior_id | credit_ind | source_id | calculated_ balance | mcc_code | ||
---|---|---|---|---|---|---|---|---|---|
1 | Preauth | DBL | -75 | 2277 | 0 | N | 2277 | 425 | 5542 |
2 | Preauth backout | PBPB | 75 | None | None | None | 2277 | 500 | None |
3 | Completion | DBC | -45 | 3388 | 0 | N | 3388 | 455 | 5542 |
4 | Auth | DBA | -12 | 4422 | 0 | N | 4422 | 443 | 5541 |
5 | Completion backout | BDC | 45 | None | 0 | None | 3388 | 488 | None |
6 | Backout | BDA | 12 | None | 0 | None | 4422 | 500 | None |
7 | Settle | SDC | -45 | 3388 | 0 | N | 3388 | 455 | 5542 |
8 | Settle | SDA | -12 | 4422 | 0 | N | 4422 | 443 | 5541 |
- 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 Banknet | Visa credit | Interlink | Star | ||
---|---|---|---|---|---|
1 | Preauth | AUL | VIL | VIL | SSL |
2 | Preauth backout | BKBK | PVPV | PVPV | PSPS |
3 | Completion | AUC | VIC | VIC | SSC |
4 | Auth | AUA | VIA | VIA | STA |
5 | Completion backout | BOC | BVC | ISC | BSC |
6 | Backout | BO5 | BVA | BVA | BSA |
7 | Settle | SE5 | VSC | VSC | SSC |
8 | Settle | SE5 | VSA | ISA | SSA |
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 code | Amount | AVS | Response code | Merchant ID | Auth ID | Balance | ||
---|---|---|---|---|---|---|---|---|
1 | AVS check | DA0 | 0.00 | Y | 85 | 000002222 | 5599 | 500.00 |
2 | Preauth | AUL | -25.00 | Y | 00 | 000002222 | 9900 | 475.00 |
3 | Backout | BO5 | 25.00 | None | None | 500.00 | ||
4 | Settle | SE5 | -25.00 | 000002222 | 9900 | 475.00 | ||
5 | Preauth | AUL | -50.00 | Y | 00 | 555002222 | 2211 | 425.00 |
6 | Backout | BO5 | 50.00 | None | None | 475.00 | ||
7 | Settle | SE5 | -50.00 | 555002222 | 2211 | 425.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 code85
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 check | DA0 |
Preauth | VIL |
Backout | BVA |
Settle | VSA |
Preauth | VIL |
Backout | BVA |
Settle | VSA |
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 CODE | AUTHORIZATION CODE | TRANSACTION AMOUNT |
---|---|---|
28 | 9988 | 200.00- |
Posted Transactions RDF
TRANSACTION CODE/TYPE | AUTHORIZATION CODE | TRANSACTION AMOUNT | SOURCE ID |
---|---|---|---|
PMMX | 9988 | 200.00+ | 2255 |
Get All Transaction History response
trans_code | amt | auth_id | prior_id | credit_ind | source_id | calculated_ balance |
---|---|---|---|---|---|---|
PMMX | 200 | 9988 | 0 | None | 2255 | 700 |
- 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 thepmt_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 Banknet | Visa Money Transfer |
---|---|
PMML | PMVT 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 AMOUNT | AUTHORIZATION CODE | TRANSACTION CODE | REVERSAL ID | TRANSACTION DATE/TIME |
---|---|---|---|---|
225.00+ | 1122 | 28 | 0 | 01272023 0:05:28 |
225.00+ | 1123 | 28 | 0 | 01272023 0:05:29 |
Posted Transactions RDF
TRANSACTION AMOUNT | AUTHORIZATION CODE | TRANSACTION CODE/TYPE | SOURCE ID | TRANSACTION DATE/TIME | POST DATE |
---|---|---|---|---|---|
225.00+ | 1122 | PMMX | 6600 | 1/27/23 0:05:28 | 01272023 |
225.00- | 1123 | ADMX | 899 | 1/27/23 0:05:29 | 01272023 |
Get All Transaction History response
amt | auth_id | prior_id | trans_code | source_id | calculated_balance | credit_ind | auth_ts | post_ts |
---|---|---|---|---|---|---|---|---|
225 | 1122 | 0 | PMMX | 6600 | 1225 | None | 2023-01-27 00:05:28 | 2023-01-27 00:05:28 |
-225 | 1123 | 0 | ADMX | 899 | 1000 | None | 2023-01-27 00:05:29 | 2023-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 thepmt_id
for the original load and the reversal maps to theadj_id
.
Other network codes
When the example above takes place on other networks, these are the values in the trans_code column.
Mastercard Banknet | Visa Money Transfer | Visa Direct OTC |
---|---|---|
ADq | ADy | ADyt |
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_code | amt | auth_id | local_amt | local_curr_code | ||
---|---|---|---|---|---|---|
1 | Auth | AUA | -39.62 | 9999 | 200 | 986 |
2 | Backout | BOA | 39.62 | None | None | None |
3 | Settle | SE5 | -40.23 | 9999 | 200 | 986 |
- Row 1 — The original authorization for USD$39.62. The
local_amt
field pluslocal_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.
Maestro | Visa | ||
---|---|---|---|
1 | Auth | DBA | VIA |
2 | Backout | BDA | BVA |
3 | Settle | SCA | VSA |
- For detailed examples of international transactions, see these scenarios:
- To see how to simulate an international transaction, see International Transaction, Visa Simulation.
Updated 15 days ago