Credit Card Processing in Restaurant Industry

The purpose of this article is to discuss the peculiarities of credit card processing in the industries, where tips are widely used (restaurant industry is a vivid example). Originally, tips were given in cash, or added to the receipt as tip adjustments. Nowadays, EMV liability shift brings forward the need for new functionality, which has already been quite relevant for the industry for some time. So why not use the situation as an opportunity to expand the functionality even further?

Restaurant industry

Traditionally, restaurant industry was considered a card-present one, just like retail industry. However (especially in the US) it has some peculiar features, related to tips. In many countries service cost is included into the price of the purchased product, but in the USA it is added separately, so when a transaction is processed, the need for tip adjustment arises.

From traditional way to easier tip adjustment

A traditional solution, commonly used in the pre-EMV world, was as follows. After the customer got the bill, he presented the credit card (with magnetic stripe), the transaction was authorized, and the receipt was brought to the customer. On the receipt the customer could specify the tip amount, which was then input into the system. Tip adjustment was done “on top of” the authorization, i.e. the authorization amount was increased, and settlement was performed on a higher amount, which included the tip.

In case of an EMV card, as long as “chip-and-signature” approach is used, the process can, essentially, remain the same. However, if “chip-and-PIN” approach is used, you need to devise an alternative way of its implementation. The reason is as follows. The customer will have to physically interact with the payment terminal (either at the table or at the counter) to input PIN. Before EMV, a debit card could be processed like a credit one, but after the EMV liability shift, some solution for “chip-and-PIN” case is absolutely necessary. Moreover, as the customer will have to interact with the terminal, the new solution can also allow the customer to select the tip amount right on the terminal screen. In this case the customer will no longer have to sign the receipt and specify the tip amount on it.

The new features

Tip amount selection prior to authorization

If you are a merchant, working in an industry, which involves tips (such as restaurants, hair salons, shuttle and taxi services), and selecting a terminal solution, you need to take into consideration such issues as tip adjustment and PIN input.

If you are a developer, devising a card-present POS system for an industry, involving tips, you need to decide in advance, how the customer is going to select the tip amount while making a payment.

We should stress, that in card-present situation the customer will have to touch the terminal and deal with a specific payment application. Consequently, it is logical to implement tip selection mechanism within this application. This will simplify the process in the eyes of the customer (the need for tip adjustment as a separate operation will disappear).

For instance, a payment terminal itself can suggest options for tip amounts (5/10/15/20 %) to the customer. Once the customer selects the tip amount, it will be instantly added to the main amount and authorized. In this case there is no need to perform or even implement the tip adjustment functionality. Sometimes tip adjustment does not succeed, so if tip amount can be input into the device prior to authorization, this risk (even the possibility) is eliminated.

As we can see, developers of software for industries, involving tips, definitely, should envision the possibility of tip amount selection on the terminal screen. We would recommend offering the customer to select one of the pre-calculated tip amounts (such as, again, 10, 15, 20, or 25 %) or key in the amount of tip manually (‘other’ option).

Support for selection of multiple tip recipients

Another issue you should consider if you develop special logic for handling tips is that a tip can have several recipients. For example, in beauty salons tips can have several different recipients. Consequently, while developing POS software for beauty salons, you can keep this in mind.


If you are a merchant in search of a new solution, you can try to find a solution, not only allowing your customers to specify tip amounts on a payment terminal, but also split these amounts among different recipients.

If you are a software vendor, developing POS software for an industry, involving tips, you should add the respective flexible tip-handling functionality (tip adjustment, automated tip amount selection, and tips with multiple recipients) to attract more merchants to your software products.

Mobile Payment Processing Techniques

There is no doubt, that the role of mobile devices in our lives is rapidly gaining importance. Nowadays mobile devices and payment applications installed on them are often used for handling of online purchases. In this article we are going to address the ways of making and accepting payments through mobile devices. We will discuss the ways in which mobile payments can be processed and the types of payments that can be made with mobile devices.
The main problem of payment application usage is how to deal with PCI compliance in each particular case. We are going to consider several conceptual approaches, which allow people and entities to accept payments, and, at the same time, reduce their PCI exposure.
Conceptual approaches to mobile payment processing are as follows.

Mobile payment processing through In-App payments

The first and most widely available approach is the so-called In-App payment. It is used by the most popular online stores, selling apps, such as App Store, Google Play, and others. They offer payment APIs, allowing to accept payments from the user of a given mobile app. In case of In-App payments, PCI exposure is completely avoided, as cardholder data is handled by the apps marketplace.

Mobile payment processing through a payment page

The second approach is usage of a classical web-page (payment page), which is accessed by an app that needs to collect the payment on a mobile device. In this case the payment page is located on the payment server of the payment service provider, which handles transaction processing for the app marketplace. This allows the app that needs to collect the payment to remain out of PCI scope.

Mobile payment processing through integration with the PSP

The third approach is to perform the integration of your mobile app with the external API of the payment service provider.
In this case you have to be careful not to increase your PCI exposure level.
If you choose to integrate your app with the payment system of your PSP, there are several ways you can follow.

  • You can use a payment application, provided by the gateway, and control its operation through so-called inter-app communication.
  • You can use the SDK/API, provided by the payment gateway.

Depending on your PCI strategy, you can choose one of the listed options.
In both cases it is better to consult QSA regarding your PCI status. However, if you do not have a QSA and plan to do a self-assessment questionnaire, then inter-app communication is the safer option.
The advantage of the inter-app communication is that your application code is completely separated from the payment application that actually processes the payment.
The disadvantage of inter-app communication is that you have to operate two payment applications instead of one.

How to process payments

Within the mobile environment both card-present and card-not-present transactions can be processed.
To process card-present transactions you can use some external device. Traditionally, conventional card-readers were used. However, nowadays, many other solutions emerged, which allow you to accept EMV cards and input PIN. Some of these modern devices are operated through Bluetooth technology. So, you can choose a device to integrate with, if you need to process some particular types of cards and transactions.
For card-not-present transactions two options can be used.

  • One option is to input card data manually, using the on-screen keyboard of the mobile device.
  • Another option is to use special external libraries, such as They allow you not to input card data manually, but instead just take a photo of your card using the camera on your mobile device. Cardholder name and card number are extracted from the card photo using image recognition algorithms. As we see, in this case, a traditional card-not-present transaction is performed, however the cardholder does not have to input card number manually.


There are different approaches, which you can utilize for mobile payment processing. Your choice will depend on your technical/functional needs and on transaction pricing offering of a specific PSP (for instance, in-app communication is quite expensive in comparison to classical payment gateway integration).

Split Funding Models

Traditionally, when merchants processed their transactions, the processor simply deducted processing fee and funded the merchant the rest. Presently, there is a growing need to split the part into several deposits. One of the main reasons for that is the emergence of online marketplaces.

From conceptual viewpoint, there are two ways to implement split funding mechanism. A company may need to implement one way or another, depending on its business model. Some business models, however, need to accommodate both ways at the same time in order to function effectively.

The purpose of this article is to inform the readers about the two types of split funding platforms, so that they could choose the more suitable platform type.

Customized split: split funding on the submitter’s end

The most common and simple type of split funding mechanism is as follows. When a transaction is processed, the submitter specifies, how the funds are to be split. Say, there are two or three recipients specified at the moment of transaction submission. Recipients are merchants or users, registered within the system, that are going to receive their shares of the total transaction amount.

In other words, the submitting system specifies particular splitting (fund distribution) rules on per-transaction basis.

This approach is more suitable when the distribution of funds depends on the specific context of the transaction, such as the number of affiliates involved, or the number of items purchased.

Example 1

A customer purchases a t-shirt for $25, and the submitting system determines that there is an affiliate, involved in the transaction, who should receive $5. Therefore, the system specifies that the total transaction amount is $25, of which $5 should go to the affiliate.

We should note that, when the next t-shirt is sold, the distribution of funds might, actually, be different.

Pre-defined distribution: split funding on the gateway’s end

Under the second model (the more complex one), the split funding rules are set up in advance in the system itself (on the payment gateway’s end). Some information on merchant services commission sharing is available here {link}.

The second model is more suitable when the distribution rules are the same from transaction to transaction.

Example 2

An online rent payment software vendor partners with some specific payment gateway. The gateway charges a convenience fee. For each transaction the rent payment software charges $4.50 from that convenience fee. The rules can be configured accordingly in the rent payment software and recorded on the gateway’s end.

Example 3

An online store sells t-shirts and hoodies online. T-shirts and hoodies are provided by two different vendor companies. For t-shirt sales the online store marks up 10%, while for sales of hoodies it marks up 8% of net transaction amounts. The rest (90% and 92%) of net transaction amounts, respectively, goes to the vendors. Consequently, after the respective distribution rules are setup, when a transaction happens, it will be sufficient to specify the vendor involved.

Split funding peculiarities

We should note, that in each split funding scenario it should be clear, who is responsible for the payment of fees. In most cases it is easier to make the account, under which the transaction is processed, responsible for the entirety of the fees. In other words, the entire fee is paid by the merchant and not split into parts. However, there might be scenarios, when the fee needs to be split between multiple parties.

Another issue to address is handling of void and refund transactions. As every sale transaction is eventually split into multiple ones, it is necessary to define, how the sub-transactions can be voided or refunded. The simplest option is to allow void/refund of the main transaction and, subsequently, void or refund all sub-transactions. However, more customized scenarios may also be required.


Your choice of split funding platform should depend on particular split funding needs of your business.
If splitting logic is complex and context-dependant, while the software integrator (customer) needs to have full control of the distribution rules, the first (customized split) model is preferable.
If splitting rules are more or less consistent from case to case, the second approach (pre-defined distribution) might be more appropriate.