This guide explains card network types as well as how different transaction types are routed over the networks. Information about selecting primary and secondary networks is also provided.
A card network (also called a "payments network" or "card association") is a business entity that comprises banks, dedicated networks, and messaging systems to facilitate card transactions. This messaging infrastructure is called a network's "rails."
There are two primary types of card network:
- Credit card — Originally formed by a single bank or financial entity, these networks process credit card transactions. Examples: Visa, Mastercard, Discover.
- Interbank — Originally formed by groups of banks to link ATMs and process debit cards. Examples: STAR, Pulse, Cirrus, Maestro, Interlink. Most credit card networks have created or acquired at least one interbank network.
As explained in Debit card validation in About Card Transactions, at the point of sale card transactions are classified according to how the card is validated:
- PIN — A PIN is input on a card reader
- Signature — A PIN is not input
Each type of validation is routed over different network rails: The PIN transaction is routed over an ATM or interbank network whereas the signature transaction goes over credit rails. Merchants tend to prefer PIN transactions because they get better interchange rates over interbank network rails and better protection in disputes; however, using a PIN is not practical or possible for a merchant in all contexts, such as at a fast food drive-through or on a web site.
Galileo is integrated with these card networks.
|Mastercard||Banknet (Credit)||Credit network. Credit card and signature debit.|
|Mastercard||Maestro/Cirrus||Interbank network. PIN debit and ATMs.|
|Visa||Visa||Credit network. Credit card and signature debit.|
|Visa||Interlink||Interbank network. PIN debit and ATMs.|
|Discover||PULSE||Interbank network. PIN debit.|
|Discover||Discover||Credit network. Credit card and signature debit.|
|Publix||Presto!||ATM only. Southeastern U.S. region.|
When you set up your program with Galileo, you will need to determine whether to permit signature transactions, PIN transactions, or both.
- If you do not allow PIN transactions, your cardholders cannot use ATMs.
- If you do not allow signature transactions, your cardholders cannot perform transactions that don't have PIN input, such as online transactions.
Whether a card transaction uses a credit or debit network depends on these factors:
- Which types of transactions you permit — If you do not permit PIN transactions, for example, the transactions will arrive at Galileo over credit rails.
- Whether the card is credit or debit — For credit products the network is credit, unless you have enabled PINs for the credit card, and then PIN transactions use debit rails.
- How the merchant is set up — Some merchants such as formal restaurants prefer to not use PINs because they don't want to produce a card reader at each table. Other merchants prefer PINs because they get better interchange rates and better chargeback protection with PIN transactions.
In some rare cases a PIN transaction might go over another network's credit rails, such as a Mastercard PIN transaction arriving over Visa credit rails, because networks can handle each other's transactions.
As you set up your card products you will decide which card network to use as a primary network, usually Mastercard or Visa. Each network has separate credit and debit rails. For example, if you choose Mastercard, your signature transactions will go over Mastercard Banknet rails and your PIN transactions will go over Mastercard Maestro rails. For Visa the signature transactions go over Visa credit rails and the PIN transactions over Interlink.
Depending on your circumstances, you may also need to associate a secondary, unaffiliated debit network with the primary network. This permits merchants and their acquirers to choose which debit network to use based on interchange rates and other benefits.
For example, if your primary network is Mastercard, you could select Visa Interlink as a secondary network, and your PIN transactions would go over Visa Interlink or Mastercard Maestro rails according to merchant/acquirer decisioning. As desired, you can add more debit networks as secondaries, and merchants can select from among those options.
These networks can serve as secondary networks:
By default, ATM transactions are routed over debit rails. You may decide to apply an ATM fee on top of network or ATM operator fees. As desired, you can make arrangements with an ATM-only network to offer fee-free withdrawals to your customers when they use that network's affiliated machines.
In that case, Galileo changes how the transactions are routed so that you can waive the ATM fee. For example, if Visa is your primary network and Maestro your secondary, you could arrange with MoneyPass, for example, for fee-free withdrawals. Withdrawals at MoneyPass machines would therefore be routed over MoneyPass rails, whereas non-MoneyPass withdrawals would come in over debit rails (Interlink or Maestro). To the MoneyPass withdrawals no fee would be applied but for the withdrawals over debit rails there would be an out-of-network fee. (Fees that the ATM operator applies would still be applied.) For more information on ATM transactions see ATMs in the Authorization guide.
An example debit card program has selected Mastercard as its primary network, Visa Interlink as its secondary network, and has arranged with Allpoint to provide fee-free withdrawals from its ATMs. Transactions would likely be routed as follows:
|Allpoint ATM withdrawal||Allpoint|
|Non-Allpoint ATM withdrawal||Maestro or Interlink|
|Gas pump with PIN entered||Maestro or Interlink|
|Online purchase||Banknet (credit)|
|Mobile wallet purchase||Banknet|
|Card-present retail purchase with PIN entered||Mastro or Interlink|
|Card-present retail purchase with no PIN||Banknet|
|Fast-food purchase at the drive-through||Banknet|
|Ride-share purchase through app||Banknet|
|Food-delivery purchase through app||Banknet|
|Card load||Banknet or Maestro|
|Outgoing peer-to-peer cash transfer||Banknet|
The responses to transaction-related endpoints such as Get All Transaction History include a
cred_ind field, which is
true when the transaction arrived at Galileo over credit rails. You can also arrange to have this field included in your RDFs.
Some aspects of card transactions are handled differently depending on the network. Some of these differences will require you to adjust your code.
Merchant credits for most networks are indicated by the otype (transaction type)
Z, but for Mastercard Banknet (credit), merchant credits are processed as adjustments. These adjustments have the transaction code
ADC and there is no corresponding authorization entry. Galileo sends both a
SETL: setl event webhook and a
BADJ: adj webhook when a merchant credit is settled for Mastercard Banknet. Also see the Authorization and settlement tables in the Transaction Types enumeration.
For more information see Merchant credits in the Crediting Cardholder Accounts guide.
Force-postings for most networks are indicated by the otype
M, but for Mastercard Banknet (credit), force posts have the transaction code
SE5, which is the same code as a typical retail settlement. You can identify a force-posted settlement in one of these ways:
- Expired auth ID field — You can request that the
expired_auth_idfield be added to your
SETL: setlevent messages as well as the
EXPIRED AUTH CODEfield to your Posted Transactions RDF. When this field is populated, the force posting is the result of an expired authorization.
- Missing authorization — If there is no matching authorization for a settlement, expired or otherwise, then the settlement is a true force-posting.
Visa and Mastercard handle STIP transactions slightly differently. Each network has a backup system that uses its own set of rules for declining or approving STIP transactions. Consult the documentation from each network to see what the rules are. Also see Stand-in processing in the Authorization Controller API guide for more information on STIP.
risk_score in the Auth API webhook is a 3-digit number for Mastercard (0–999) but a 2-digit number for Visa (0–99). If you are using the Auth API, you will need to devise a way to account for these different scales.
The default standard for country codes is ISO 3166. Mastercard uses different country codes for these countries:
- 230 — Mastercard
- 231 — All other networks
- 886 — Mastercard
- 887 — All other networks
- 280 — Mastercard
- 276 — All other networks
Updated 3 months ago