The Online Payments Cycle. Why Visa is King

Unless you are in the know, it will sound like a bold statement when I say nothing is as important for the growth of an online business as implementing an effective online payments infrastructure. An effective and durable solution to process payments on your website and actually have those payments land in your company’s bank account is the recipe for long term success. 

Many businesses give up at some point during their growth and fail to scale further due to an inability to master the above. As with all things, its mastery starts with a proper understanding of what actually happens when a consumer makes a payment on your website. It's vital to understand the steps. This note will take you through them chronologically and explain, at every step, who the players are and what they do. We will focus on payments with credit cards (which basically means Visa). 

In my experience, the most confusing element in tackling the payments landscape is the terminology. It is quite annoying that everyone uses different terms to refer to the same players in the game. But as you go along, you will slowly grasp the dominant terminology applied by most of the people in the online industry. I will stick to that. 

Introducing the Acquirer

Let's say, as an example, a US based consumer browses to an EU company’s website and then proceeds to buy a pair of shoes on the website using his Visa credit card. The company he wants to buy the shoes from is commonly referred to as the ‘Merchant’.  This Merchant will ask the consumer for his credit card number on the payment page. The consumer wants the shoes so he proceeds to enter his credit card information. So what happens now? 

At this point, all the Merchant has is some contact information and some digits. The Merchant does not want to just send the shoes to the consumer only to find out later that he doesn’t have enough money to pay for it. Somehow, the Merchant will have to check whether the consumer who entered the credit card info actually has enough money on his bank account to pay for the shoes. How does the Merchant do that? And if the Merchant does confirm that the consumer has enough money, how can the Merchant arrange for the money to be transferred from the consumer’s bank account to the Merchant’s bank account? This is where an important player enters the stage mostly referred to as the ‘Acquirer’, the ‘Acquiring bank’ or the ‘Payment Processor’. Think of companies like Adyen or Worldline. The Acquirer’s role is to check whether the consumer who entered the card information has enough money and, if so, make sure this money is actually paid to the Merchant. To be able to initiate this process, the Acquirer will need to receive the credit card data which the consumer has provided to the Merchant on the website. How does that happen? 

Meet the Gateway

The credit card data needs to be digitally transferred to the Acquirer in order to start the process. So there must be a digital connection between the Merchant and the Acquirer, i.e. there must be a technical integration between their respective platforms in order to enable the flow of the credit card data from the Merchant’s website to the Acquirer. If you are a very large and technically advanced Merchant (say Foot Locker), an Acquirer might be willing to allow your platform to integrate directly onto its platform. Most Merchants do not have this technical capability though. So they will need help from an organisation which is already itself connected to the Acquirer and is willing to help the Merchant connect to the Acquirer. Such organisation, i.e. technical intermediary, is generally referred to as a PSP (payment services provider) or a Gateway. Under the Payment Services Directive, the term PSP is much broader but in many online verticals the term is generally used for organisations whose business is to help a Merchant connect to an Acquirer. 

So the Merchant in our example will need to engage (enter into an agreement with) two service providers, i.e. an Acquirer and a Gateway connected to that Acquirer. Once a Merchant is connected to a Gateway, the Gateway will receive the credit card info inserted on the Merchant’s website by the consumer who wants to buy the shoes. This is important because not everyone can have access to the credit card data. This is very sensitive financial data so both its receipt and its transfer must be done by entities allowed to do so (like Gateways). The Gateway then securely transfers this credit data to the Acquirer. Gateways often have connections to many Acquirers. However the date can only be transferred to an Acquirer with which the Merchant has a contract in place  (i.e. a merchant account). 

Here comes the Issuing Bank 

So now the credit card data has gone from the Merchant's website via the Gateway to the Acquirer. This is all still pretty inconsequential. After all, the aim is to figure out whether the consumer has enough money in his bank account to pay for the shoes. So, it's great that the credit card data is now with the Acquirer but we need a connection to the consumer’s bank. So now the Acquirer needs to somehow send an authorization request to the consumer’s bank and have the bank confirm whether the consumer has enough funds on account to cover the shoes. The consumer’s bank is generally termed the Issuing Bank. It is called the Issuing Bank because it's the bank that has issued the credit card to the consumer. Bear in mind that the Acquiring bank may be in Europe (for example Amsterdam) and the consumer’s Issuing Bank may be in Cleveland, Ohio because the consumer is an American who lives there. 

Enter the King

How does the Acquirer in Amsterdam send a digital authorization request to the bank in Ohio? There needs to be a digital connection between the two for the data flow. There generally isn't any. It’s simply impossible for an Acquirer to technically integrate with a million banks around the world. This is where the most pivotal player comes in: Visa. Remember, the credit card in our example is a Visa card. Visa is King because Visa is actually connected to an incredibly large number of banks (I’m tempted to say all banks). So in order to digitally communicate with banks, i.e. to send authorization requests and receive answers from banks anywhere in the world, the Acquirer needs to be connected to Visa. The Acquirer will then send the authorization request, through the Visa network of digital rails, to the Issuing Bank in Ohio. 

Now what? The Issuing Bank in Ohio sees that a request came in from an Acquirer in Amsterdam for confirmation that the bank’s US based consumer has the money to pay an EU Merchant for the shoes. Not only must the Issuing Bank confirm that the consumer has sufficient  funds, the Bank must also (if there are sufficient funds) block this amount of money on the consumer’s account so it is reserved for the shoes and cannot be spent on anything else in the meantime. Before the Issuing Bank does this, it will first evaluate the request. It will first cast its own judgement on whether this is a proper request for the consumer’s money or some fraudulent attempt to take the consumer’s money for shoes which the consumer never wished to purchase. 

Declines and Authorizations

Should the Issuing Bank accept the request or decline the request? This is very important. A decline simply means missed revenue for the Merchant. There are many factors that come into play here. One of them is the jurisdiction (country) of the Acquirer. An Issuing Bank in Ohio is much more likely to approve a request for authorization from an Ohio based Acquirer (or US based Acquirer) than from an Acquirer on the other side of the world in Amsterdam. After all, the Issuing Bank will simply find it less credible that its customer (the consumer) has decided to buy a pair of shoes from an EU based Merchant with an Amsterdam based Acquirer. If the Acquirer would be based on some sunny island (like Cyprus or Malta) it would even raise more flags for the Issuing Bank and lean it towards a decline of the authorization request. For this reason, we see many EU Merchants who want to sell to US consumers actually setting up a company in the US and getting a US Acquirer. A US Issuing Bank is much less likely to decline authorization requests from US Acquirers. To decrease declines and increase authorizations (revenue) EU Merchants often find it useful to set up companies in the US and use those as the sellers. 

Visa handles it all 

Let's say the Issuing Bank in our example checks the consumer’s bank account and sees there is enough money to cover the shoes. It then blocks the funds and sends an authorization code back  (through the Visa network) to the Acquirer and (through the Gateway) to the Merchant. Remember, all of this happens in the couple of seconds after the consumer has made his purchase. As soon as the consumer sees on his screen that the payment was successful, this means the Merchant has received confirmation from the Issuing Bank that the purchase price for the shoes is available and blocked on the consumer’s account. The Merchant now feels comfortable sending you the shoes. 

Then at night (generally every night) the Acquirer adds up all the money it is owed by the Ohio based Issuing Bank whose cardholders have bought something on the websites of the Acquirer’s customers (Merchants). Actually the Acquirer does this with all issuing banks and prepares a file for all payments owed to it by all Issuing Banks. The Acquirer then sends the file to Visa and requests payment. Visa then (generally every night) pays this amount to the Acquirer. Now Visa needs to collect this amount back from (in our example) the Issuing Bank in Ohio. So Visa then adds up and consolidates all of the money (globally) it has paid to acquirers who have processed transactions for cards issued by the Issuing Bank in Ohio. Visa then sends a net demand for payment to the Issuing Bank in Ohio which must be paid the same night. No questions asked. Visa does this every night. Not just with one acquirer or issuing bank but all acquirers and issuing banks. Hundreds of millions of transactions are processed and cleared this way every night through the Visa network. Every Acquirer and Issuing Bank pays to and gets paid from Visa. The international flow of payment data largely happens on Visa’s digital rails. It's remarkable and it explains why everyone, Merchants, Issuing Banks and Acquirers, all bend the knee for Visa and are subject to its rules. 

You don’t want to be on the outs with Visa. Learning its rules and abiding by them is an absolute must.

Reach out to Starks Legal at Marianne@starkslegal.nl for any legal assistance with your payments issues