Payment Gateway and the On-Us / Not On-Us Concept

A Payment Gateway is the technology that ensures the payment instrument used by the payer in a triggered transaction is successfully routed to the relevant bank — whether by charging the cardholder's or account holder's bank, or by drawing on the available balance in the account — enabling products and services to be accessed digitally, online, contactlessly and swiftly. The Payment Gateway solution is the path that provides, in a secure and standardised manner, the bridge between the buyer and seller, the cardholder's bank, and the bank whose Virtual POS is used for the transaction. In other words, this bridge facilitates the fast and contactless transfer of the amount from the buyer's account to the seller's account.

Acting as an intermediary between the customer and the merchant, the Payment Gateway supports not only the financial transaction type we refer to as a sale, but also all financial transaction types supported by the Virtual POS bank, such as cancellation/refund, pre-authorisation (placing a hold) and final authorisation (releasing the hold).

Although it may appear to simply mediate transaction types at a high level, the Payment Gateway cycle is a living system that is constantly evolving and open to change. The management of its evolution and change lies in the hands of the players or rule-setters of the payment systems ecosystem.

Alongside financial transaction types, all flows including campaign queries offered by banks to cardholders or Virtual POS owners, sector-specific parameter usage, reporting and more are carried out through the Payment Gateway.

The process may look complex in a diagram, but the entire sequence takes only a few seconds. Since Payment Gateways are triggered by the user's sensitive data, they must guarantee the security of transaction data — such as CVV codes, card numbers and expiry dates — during transfer. For this reason, every payment gateway must have and maintain PCI DSS compliance, which sets robust data protection standards.

This method of purchasing products and services through online systems via Payment Gateway technology can be built as an infrastructure provided directly by banks, where the merchant integrates directly with the bank's systems to access this bridge; alternatively, it can also be realised by integrating with an intermediary service provider that has already integrated with the banks' systems and facilitates merchants' integration with bank systems through a single channel.

When examining Payment Gateway integration methods, there are two main approaches. Some banks provide the Payment Gateway solution through their own in-house structures. For this reason, merchants wishing to obtain a Virtual POS integrate directly with the banks' Payment Gateway structures using the integration documentation provided by the relevant banks.

On the other hand, there are also banks that outsource their Virtual POS Payment Gateway structure rather than handling it in-house. In such a structure, merchants wishing to adopt a Virtual POS Payment Gateway encounter an integration process provided by the Payment Gateway service provider or system referred to by the bank, rather than by the banks themselves.

The most significant advantage of this outsourced service is the possibility that the relevant service provider manages this process with more than one bank. In such a case, merchants can integrate with banks using virtually identical integration documentation.

Why Should You Integrate with Multiple Payment Gateways?

As can be understood from the explanations above, one of the important players in the payment system ecosystem that provides integration with the Payment Gateway structure is the merchant or online website. To make it easier to follow, instead of referring to the system as a Payment Gateway, we can call it the bank Virtual POS system — because at the integration point, merchants must choose not "which Payment Gateway should I integrate with?" but "which bank's Virtual POS structure should I integrate with?". One of the most important reasons for needing to integrate with more than one Virtual POS bank is that each card-issuing bank only permits instalment transactions through the Virtual POS systems of its own bank or its contracted network banks. Merchants who wish to offer customers more options during online shopping integrate with all banks or the most widespread banks for instalment advantages. This can sometimes be shaped by the merchant's business model.

Cardholders who encounter a screen presenting instalment options at the payment step should be aware that the website where they are shopping has connected to the relevant banks' or their network-member banks' Virtual POS gateways through more than one integration.

The On-Us and Not On-Us Concept

Like any system, the world of payment systems has its own specific terminology. Among these terms, one of the most frequently heard during or after a transaction is the on-us / not on-us concept.

To classify a transaction as on-us or not on-us, we need to look at two main players in the payment system cycle:

- Card Issuer Bank

- Acquirer Bank

Without going into technical detail, I will explain which transactions are on-us and which are not on-us with a simple example.

For a transaction to be classified as on-us, the card used by the person purchasing the product or service must be from the same bank as the Virtual POS system through which the transaction is processed.

Transactions carried out with an Akbank card through an Akbank Virtual POS system can be called on-us transactions.

A not on-us transaction, on the other hand, is one where the card used by the buyer is from a different bank than the Virtual POS system through which the transaction is processed.

Transactions carried out with an Akbank card through an İşbank Virtual POS system can be called not on-us transactions. Although Virtual POS banks may view not on-us transactions as negative from a profitability and cost perspective, they are obliged to allow them due to customer satisfaction requirements, Visa/Mastercard rules, and the profits obtained, however small.

Due to the reasons mentioned above, the routing of a transaction as on-us or not on-us is entirely a step managed by the merchant's integration. Although the preference may appear to cardholders as a process they can visibly control, this choice can be indirectly managed through the merchant's integration methods.

In a follow-up article, we will discuss how on-us and not on-us transactions are correctly routed, the Payment Switch concept and its alternatives, together with the Payment Switch mechanisms that may exist in some gateway solutions.