Guides
Log into Sandbox

About Card Transactions

Suggest Edits

This guide explains the basics of how card transactions work: which entities are involved in card transactions, the sequence of events, and some examples of how different merchant types handle transactions. Along with this guide you may want to read these other documents:

  • About Transactions — A general guide to how transactions are represented in the Galileo system.
  • Card Transaction Scenarios — Example scenarios to show how various card transaction types appear in the Program API, Events API, Auth API, and the RDFs.
  • Finding Transaction Data — Quick reference to see where to find different types of transactions.

Subsections in this guide:

  • Networks — Credit and debit network types and how transactions are routed
  • Authorization — Authorization requests and their variants such as preauthorization, incremental authorizations, and partial authorizations
  • Settlement — Settlements, backouts, and completions
  • Crediting Cardholder Accounts — Card transactions that move funds into cardholder accounts such as reversals, merchant credits and card loads
  • Card Transaction Examples — Examples of the transaction types explained in the other guides

A card transaction is usually initiated by a cardholder at a point of sale. The transaction is facilitated through its various phases by card networks until the transaction has completed.

Prominent card networks are Visa and Mastercard for credit card transactions, whereas interbank networks such as Interlink and Maestro handle ATM and PIN-debit transactions. Galileo is integrated with most major credit card and interbank networks in the United States. See Networks for more information.

Card transactions are not initiated or facilitated through the Program API; however, you may be informed of each step of the transaction in real time through the Events API, or you may subscribe to the Authorization Controller API, to participate in authorizations. These transactions are also recorded in the RDFs and can be viewed using transaction-retrieval endpoints such as Get All Transaction History.

Transaction participants

All card transactions have at least five participants.

441

Card transaction participants. Double lines indicate card-network rails.

Merchant

A merchant is an entity that offers goods, services, or cash in exchange for a card payment. A merchant can be a physical store, an online vendor, a mobile app, an ATM, a card-loading vendor, or a money-movement app. Merchants have card-reading devices on their physical premises or card-processing software on their online sites or in their mobile apps.

Acquirer

Prior to accepting card transactions, a merchant must set up a business relationship with an acquirer, which is a bank or intermediary. The acquirer has physical access to the card networks and provides the merchant with card-reading hardware or software. The acquirer handles card-network messages on behalf of the merchant as well as moves funds between the merchant account and the card networks. Merchants send their transactions to their acquirers over an electronic connection.

Card network

A card network is an entity that has laid cable to create the network over which card transactions are processed. This physical infrastructure is called a network's "rails," which transmit a standardized set of messages between acquirers and issuers. The networks also transfer funds between issuers and acquirers and assist in resolving disputes.

For more information see the Networks guide.

Issuer

The issuer is an entity, usually a bank or an intermediary, that offers cards to customers and maintains the card accounts. Issuers determine which card types to offer, what features the account has, and which restrictions to impose. Issuers also have physical connections to the card networks and handle network messages on behalf of their cardholders.

For Galileo clients, Galileo fulfills the role of issuer in payment-card transactions by partnering with issuing banks (which hold the funds for cardholder accounts), handling the messages that arrive over the network rails and by transferring funds between customer accounts and the card networks.

Cardholder account

The account on which a card transacts is the cardholder account. The account is typically a DDA or a credit account. These accounts may be held by Galileo or by you, depending on your setup.

At the time that you create a card program, you decide whether to permit PIN transactions, signature transactions, or both, and you determine which networks to use for each type of transaction.

Transaction phases

All payment-card transactions pass through these phases:

  1. Acquisition
  2. Authorization
  3. Clearing
  4. Reconciliation and settlement

1. Acquisition

In this first phase of the transaction, the cardholder presents card information at a merchant's point of sale.

At physical locations the card information is acquired through a card reader. This device is provided to merchants by their acquirers. Most card readers permit cardholders to insert their cards into a slot that reads a chip, which contains sophisticated security information that is difficult to reproduce for fraudulent purposes. For cards without chips, the reader permits the magnetic stripe to be swiped. In "contactless" transactions, a specialized card can be "waved" near an NFC reader that can pick up the card information, or the cardholder can wave a mobile phone that contains a mobile wallet. Depending on how the card is set up, the cardholder may be required to enter the PIN for the card.

For websites and mobile apps, merchants obtain specialized software from their acquiring banks that accepts a typed-in PAN, expiry date, and CVV, as well as the cardholder's billing address. Mobile apps also accept payments from mobile wallets. See Mobile wallet support in the Choose a Card Strategy guide for more information.

Older methods of acquiring card information include making a physical imprint of the card onto paper (if the PAN is embossed), typing the PAN via keypad into a device, or writing the PAN on a paper slip to submit to the acquirer. Issuers, acquirers or card networks may no longer permit some of these acquisition methods for security reasons.

With all of the electronic methods, the card's PAN, expiry date, CVV, card network, and other information are transmitted to the authorizing entity (issuer) through the network. With non-electronic methods the PAN, expiry date, and CVV are manually delivered to the acquirer, which converts the information into an electronic format and sends it to the network. For non-electronic methods where authorization is not requested prior to the transaction, the merchant assumes the risk of accepting cards that may not be valid or that might not support the transaction.

📘

Note

Neither Galileo nor its clients are involved in the acquisition phase of a payment-card transaction; however, different acquisition configurations affect how the transactions are processed and therefore affect the data that you see.

Card-not-present transactions

Acquisitions can be classified according to whether the physical card is used to initiate a transaction. When the cardholder is present on the merchant's premises and can produce the physical card (or a phone that contains a mobile wallet), it is a "card present" transaction. When the cardholder presents card information without being present at a physical site—at an e-commerce site, in a mobile app, or over the phone—it is a "card not present" transaction.

For card-not-present transactions, issuers or card networks usually require verification information such as the expiry date and CVV, and merchants use AVS to ensure that the legitimate cardholder is initiating the transaction. Issuers may decide not to allow card-not-present transactions, or in other cases may temporarily disallow card-present transactions, such as when the physical card is in transit to the cardholder.

For additional security, some online merchants use the 3-D Secure (3DS) protocol to authenticate the cardholder for online transactions. 3DS is required in some jurisdictions and strongly recommended in others. See 3-D Secure Access-Control Server for how to enable 3DS for your program.

Card validation

Validating a card at a point of sale can take one of two forms, depending on how the card account is set up and on merchant decisioning:

  • PIN — The cardholder enters a PIN on the keypad of a card-reading device.
  • Signature — The cardholder signs a receipt, and the merchant compares the signature to the signature on the back of the card. Online transactions, cash-app transfers and any other transactions where a PIN is not input are treated as signature transactions as well.

Whether a PIN is entered determines the type of network that the transaction uses. See the Networks guide for more information.

At the time of acquisition, the merchant or acquirer may apply rules to determine whether they will accept the card type, based on the BIN. For example, a merchant might have a policy to not accept prepaid cards. In that case, the card is rejected at the merchant site and no authorization request is sent.

2. Authorization

Authorization is an anti-fraud and risk-mitigation measure to verify the card and cardholder's authenticity as well as the card's ability to support the transaction.

After the card information and purchase amount are acquired, the merchant sends an authorization request with the transaction amount to its acquirer, who routes the request to the appropriate network. The network performs some preliminary fraud-detection checks and sends a risk score, along with the authorization request, to the issuer.

The issuer verifies that the card passes validation checks, then ensures that the card account can support the transaction. In the case of a debit or prepaid account, the issuer checks for sufficient funds, and in the case of a credit account, verifies that the credit limit has not been exceeded. The issuer also checks for violations of velocity limits and other restrictions such as location or merchant type. Further fraud-detection checks may also take place at this point.

📘

Note

For authorization requests Galileo fulfills the role of issuer. Galileo clients may also participate in the authorization process by using the Authorization Controller API.

If the card and transaction pass all verification checks, the issuer returns an "authorization approved" message and the merchant completes the transaction; otherwise, the issuer returns an "authorization denied" message, along with the reason for the denial, and the merchant cancels the transaction.

After approving an authorization request, Galileo places a hold on the cardholder account for the amount of the transaction. This hold changes the available balance amount such that it is not taken into consideration for the next authorization request. For example, if a cardholder has 200.00 in their account and Galileo approves an authorization for 50.00, the cardholder then has only 150.00 in available funds. If the cardholder attempts to make another purchase for 151.00, the authorization will be denied for insufficient funds, even though the first 50.00 has not yet been debited from the account.

📘

Note

See the Authorization guide for further details about authorization, including preauthorization, upcharges, partial authorizations, AVS-only checks, balance inquiries, provisioning requests, authorization linkage, and incremental authorizations.

3. Clearing

Merchants regularly compile a list of completed transactions during a particular period, usually the current day, although some high-volume merchants may compile these lists multiple times per day, and low-volume merchants may send them every few days. These lists include adjusted amounts that were added to the transaction after initial authorization was granted, such as a tip added at a restaurant, or a transaction may end up being less than the authorized amount.

The merchants then send the clearing messages to their acquirers. The acquirers sort through the transactions, and then route batch files to the various card networks. The networks sort through the transactions and compile batch files to send to each issuer.

4. Reconciliation and settlement

The issuer receives a batch file from each network at least once per day. The issuer compares the transactions to the authorizations that it has in its system, and when the transaction matches, the hold is backed out, the transaction is changed from an outstanding authorization to a settled transaction, and the amount is posted to the cardholder account. Matching the clearings with authorizations is called reconciliation, and posting the amount to the account is called settlement.

📘

Note

See the Settlement guide for details on settlement, including backouts, completions, force posting and incremental clearings.

As the final step in a transaction, the network calculates the debits and credits for each issuer and presents the net amount owed to the issuers. In separate processes, the networks settle with acquirers and the acquirers settle with their merchants.

Example transaction workflow

This diagram shows the stages of a typical transaction.

614

Most card transactions have two distinct phases.

Card transactions in the ledger

Card transactions in the Galileo ledger are usually represented by multiple entries or rows. Most transactions have either three or five entries.

Three-step sequence

Most card transactions are represented by three entries in the Galileo ledger:

  • Authorization — When Galileo receives an authorization request, regardless of whether the request is approved or denied, Galileo creates an entry in the authorization table. Galileo creates an authorization ID (auth_id) that follows the transaction through its various stages. If the authorization request is approved, the authorization amount is placed in an authorization hold so that the cardholder cannot spend the amount, but the amount is not yet debited from the account.
  • Backout — When the settlement batch file arrives, just prior to posting the settlement, Galileo backs out the authorization by creating a backout entry that has the opposite sign of the authorization. The backout releases the authorization hold.
  • Settlement — The settlement is the third entry. It represents the amount that is actually debited from the cardholder account and moved into the account that you use to pay the network.

You can see examples of the three-step sequence in these places:

Five-step sequence

A less-frequent transaction type creates five entries in the ledger:

  • Preauthorization — The first entry is often a preauthorization instead of a conventional authorization. It also creates an authorization hold on the amount.
  • Preauthorization backout — The second entry backs out the preauthorization at the time that the completion arrives at Galileo. The completion arrives over network rails instead of being in the settlement batch file. The backout releases the preauthorization hold.
  • Completion — The completion entry, which represents the actual sale amount, creates a new authorization hold.
  • Completion backout — When the settlement batch file arrives, the completion is backed out with a ledger entry that has the opposite sign as the completion. The backout releases the completion hold.
  • Settlement — The settlement is the fifth entry, which represents the amount that is actually debited from the cardholder account and moved into the account that you use to pay the network.

You can see examples of the five-step sequence in these places:

📘

Note

To see all ledger entries including backouts, use the Get All Transaction History endpoint or view All Transactions in the CST.

Other sequences

Other sequences may also occur according to the nature of the transaction. Some example are found here:

Returning funds to cardholder accounts

Although most transactions move funds from the cardholder account to the merchant, some transactions move funds in the opposite direction:

  • Reversals
  • Merchant credits
  • Card loads
  • Disputes

For information on these types of transactions, see the Crediting Cardholder Accounts guide.

Transactions by merchant type

The majority of cardholder transactions will be at retail outlets, either online or on premises, with the typical three-transaction sequence (authorization, backout, settlement). This section explains what kinds of variations you can expect with transactions from particular merchant types.

Restaurants and bars

In many establishments that serve food or alcohol, customers are permitted to add a tip to the bill when paying with a card. The tip-adding can take one of two forms:

Signature-based

  1. At the table the customer is presented with a bill, and the customer gives the server the card.
  2. The server obtains authorization or preauthorization for the amount of the bill and prints out a receipt.
  3. The customer writes in a tip and signs the receipt.
  4. The merchant sends a clearing amount for the bill amount plus the tip. The settlement and preauthorization amounts are therefore different.

Galileo is obligated to post the full amount to the cardholder account even if the cardholder's account is driven negative by the tip amount. See Upcharges in the Authorization guide for a way to mitigate this risk.

PIN-based

  1. The server gives the bill to the customer.
  2. The customer goes to the cashier and uses the card reader to input a PIN. The card reader is programmed to ask if the customer wants to add a tip, and then accepts manual input.
  3. The card reader sends the bill amount plus the tip as a single authorization request.

With this method there is no risk of the tip amount driving the account negative, because the full amount is authorized.

Fast food

Most fast food restaurants do not use PIN verification, especially at a drive-through window. To improve their customer experience, some restaurants do not wait for authorization before completing a transaction, and so when they clear the transaction it results in a force-post. Restaurants therefore assume the risk of the transaction being disputed.

Gas pumps

Transactions at gas pumps follow a five-step sequence (preauthorization, backout, completion, backout, settlement) instead of the usual three-step sequence (authorization, backout, settlement). Because the total sale amount is not known until after the gas is already in the tank, a gas pump gets preauthorization before dispensing the gas, and then when the sale amount is known, sends a notification over the authorization rails of the final amount. Later, the gas station owner sends a clearing message for the final amount, which arrives at Galileo in the settlement batch file.

See Five-step sequence and Scenario 2: Preauthorization with Completion for examples. Also see Upcharges in the Authorization guide, because setting an upcharge for gas pumps is a common use case.

It's also not unusual for a customer who pumps gas to make a purchase at the corresponding convenience store. In that case you will see two sets of transactions within a few minutes of each other: one for the pump (often MCC 5542, automated pumps) and one for the convenience store (MCC 5541, service stations).

See Gas pump plus convenience store in Card Transaction Examples.

ATMs

ATMs typically use MCC 6011. ATM fees may be assessed by the ATM operator, by the network, or by you. An authorization request for an ATM includes the withdrawal amount plus all fees in one request. With the settlement, the fees from the ATM operator and network are included with the cash amount, whereas any fees assessed by you are broken out in a separate transaction.

ATMs are programmed to send reversals when there is an error, such as a duplicate authorization or an amount dispensed that is different from the authorized amount.

For more information see ATMs in the Authorization guide and ATM networks in the Networks guide. For examples see ATM withdrawal in Card Transaction Examples or these other scenarios:

E-commerce

When a cardholder makes a purchase on an e-commerce site, the merchant usually performs an AVS-only check, which has an authorization amount of 0.00. Galileo returns response code 85 (valid test, non-financial transaction) along with the AVS results when the card and account are active. If the card or account are not active, Galileo returns 05, or if other conditions apply such as a lost or stolen card, Galileo responds with the appropriate code. (See the Authorization Response Codes enumeration.)

Because web sites and apps cannot ask for PIN input, all e-commerce transactions are signature transactions.

See AVS-only checks in the Authorization guide for more information.

Amazon

When a cardholder initiates a transaction, Amazon usually performs an AVS check. Some hours later, Amazon sends out preauthorization requests in a batch file and later sends a conventional clearing or completion. When an order includes items from a third-party vendor, the vendor usually gets its own preauthorization for that portion of the order and clears or completes it separately. There is no identifier to tie the transactions to the AVS check or to the various parts of a single order. The timing of when portions of an Amazon order are authorized varies widely depending on how the third-party vendors are integrated with Amazon as well as a number of other factors internal to Amazon.

Keep in mind that the merchant IDs for the various parts of an Amazon order might be different from the original AVS check, depending on who fulfills the order. A third-party vendor usually has something like "AMZN Mktp" (Amazon Marketplace) in the transaction description and a different merchant ID than the AVS check.

For an example see Amazon transaction in Card Transaction Examples. Also see Incremental clearing in the Settlement guide for another way that e-commerce merchants might clear orders that ship separately.

Hotels

When a hotel accepts a reservation, it typically preauthorizes the guest's card for 50.00 or so as a reservation fee. When the guest checks in, the hotel often reverses the reservation fee and preauthorizes the card for the anticipated amount of the stay. When the guest checks out, the hotel sends a clearing for the total amount of the stay, including minibar and other charges. Sometimes a hotel does not reverse the reservation fee but rather deducts it from the settlement at the end of the stay.

In the case of an extended stay, a hotel might get preauthorizations for the next two days only, for example, and then send a clearing message for those two days before preauthorizing the next two days.

Car rental

Car rental agencies typically obtain a preauthorization for an amount that is considerably higher than the anticipated final amount, often for several hundred dollars. When the car is returned the agency sends a partial reversal to release the excess funds from the hold. They then send a conventional clearing message a few days later.

For a detailed example of a car rental transaction, see Scenario 8: Partial Reversal on Preauthorization.

Ride-share services

The ride-share apps tend to send a high number of preauthorizations that are later backed out or reversed because of these factors:

  • The apps get preauthorizations at the beginning of the ride for the estimated amount, and then may get separate authorizations when the ride is finished and the ride total is known.
  • Many cardholders have two ride-share apps, so they create ride requests on both apps at once to see which service can provide a ride the soonest. Then they cancel one request in favor of the other.
  • Ride-share app users often make and then cancel ride requests soon after, for whatever reason.

When a rider is picked up the app sends a preauthorization request for the estimated amount. This transaction often has "pending" or "temp auth hold" in the transaction description. The next steps vary depending on what the app is configured to do. Any of these scenarios may play out:

  • When the ride is completed, the app sends another preauthorization request for the actual amount. The description for this second preauthorization may contain "trip" or "charges." Galileo backs out the first preauthorization soon after.
  • When the ride is completed, the app sends a reversal for the difference between the preauthorization and the final amount, if the final amount is less. Galileo expires the reversal when it receives the clearing message.
  • When the ride is completed, the app sends a conventional clearing message for the actual amount, which may be less than the preauthorized amount. The preauthorized amount is held until Galileo gets the clearing message.
  • When the rider provides a tip after the ride transaction has completed, the app gets another preauthorization for that amount, and the clearing for the tip may be included with the clearing for the original ride or it may be cleared separately.

For examples see Incremental authorization and Partial reversal and expiry in Card Transaction Examples as well as Scenario 3: Incremental Authorizations.

Peer-to-peer cash transfers

Services such as Venmo, Cash App, Zelle and PayPal perform peer-to-peer cash transfers and typically use MCC 4829 (wire transfers) or 6012 (financial institutions).

When your customers send funds to a peer, the transaction is authorized and settled in the usual manner as a debit from the account. The name of the peer who receives the funds is in the transaction description.

When your customers receive funds from a peer, the transaction is a card load, which is a payment activity type. The name of the peer who sent the funds is in the transaction description. The load will be either a Mastercard or Visa load, depending on the card's branding.

See Card loads, below, for more information. Also see these detailed examples:

Card loads

According to your settings, cardholders can directly load cash onto their cards at selected merchant sites, or companies can electronically load funds onto cards. When a cardholder receives funds from a cash-transfer app, such as a Venmo cashout, or payments from a gig-economy company such as Uber, the load type depends on the card's branding: Mastercard or Visa.

Examples

Gig-economy workers

Drivers for ride-share and food-delivery services often receive payments to their accounts as card loads, such as a Maestro load or Visa Money Transfer.

For an example see Uber payment in Card Transaction Examples and Scenario 17: Card Load (Maestro).

Mobile wallets

When a cardholder adds a mobile wallet card as a payment method in a mobile app, the app typically sends an AVS request to verify that the card is valid. After a successful AVS check, the app sends a conventional authorization request for the sale amount with a conventional settlement afterwards.

See Mobile wallet support in the Choose a Card Strategy guide for more information. Also see AVS-only checks in the Authorization guide.

International merchants

See International transactions in the International guide for more information.

Updated 11 days ago

Galileo Financial Technologies, LLC 2024

All documentation, including but not limited to text, graphics, images, and any other content, are the exclusive property of Galileo Financial Technologies, LLC and are protected by copyright laws. These materials may not be reproduced, distributed, transmitted, displayed, or otherwise used without the prior written permission of Galileo Financial Technologies, LLC. Any unauthorized use or reproduction of these materials are expressly prohibited.