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

OwnerNetworkType
MastercardBanknet (Credit)Credit network. Credit card and signature debit.
MastercardMaestro/CirrusInterbank network. PIN debit and ATMs.
VisaVisaCredit network. Credit card and signature debit.
VisaInterlinkInterbank network. PIN debit and ATMs.
VisaPlusATM only.
DiscoverPULSEInterbank network. PIN debit.
DiscoverDiscoverCredit network. Credit card and signature debit.
FiservSTARInterbank network.
FiservMoneyPassATM only.
CardtronicsAllpointATM only.
PublixPresto!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.

Credit vs debit networks

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.

Primary vs secondary networks

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:

  • Maestro
  • Interlink
  • PULSE
  • STAR

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

Routing examples

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:

Transaction descriptionNetwork
Allpoint ATM withdrawalAllpoint
Non-Allpoint ATM withdrawalMaestro or Interlink
Gas pump with PIN enteredMaestro or Interlink
Online purchaseBanknet (credit)
Mobile wallet purchaseBanknet
Card-present retail purchase with PIN enteredMastro or Interlink
Card-present retail purchase with no PINBanknet
Fast-food purchase at the drive-throughBanknet
Ride-share purchase through appBanknet
Food-delivery purchase through appBanknet
Card loadBanknet or Maestro
Outgoing peer-to-peer cash transferBanknet

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. This same information is in the CREDIT INDICATOR field in the RDFs.

For example transactions over various networks see Card Transaction Examples or consult the Card Transaction Scenarios.

Network differences

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

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 a BADJ: adj webhook message 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

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_id field be added to your SETL: setl event messages. This value is also in the EXPIRED AUTH CODE field of the 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.

Also see the Authorization and settlement tables in the Transaction Types enumeration and Driving an account negative in the Settlement guide.

STIP transactions

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 scores

The risk_score in the Auth API webhook payload 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.

Country codes

The default standard for country codes is ISO 3166. Mastercard uses different country codes for these countries:

  • Ethiopia
    • 230 — Mastercard
    • 231 — All other networks
  • Yemen
    • 886 — Mastercard
    • 887 — All other networks
  • Germany
    • 280 — Mastercard
    • 276 — All other networks