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

Conclusion

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

Encrypted MSRs and Payment Terminals

The purpose of this article is to analyze card-present transaction processing in greater detail and see how traditional and encrypted magnetic stripe readers (MSRs) as well as payment terminals are used, as well as to explain how MSR or terminal can, potentially, take an application, relying on it, out of PCI scope.

Generally, every credit card payment transaction can be classified as either card-present or card-not-present (CNP) one. Card-present transactions usually involve usage of a physical card, and, thus, a swipe of a magnetic stripe, which requires usage of a special device, called magnetic stripe reader (MSR). Card not present transactions include online and over-the-phone transactions where card information is manually keyed.

From traditional to encrypted MSRs

Traditional MSRs

Initially, traditional MSRs were introduced to read credit card swipes. After a card was swiped, the card data was transferred to the merchant’s payment processing application. The application, in its turn, generated the message for the payment gateway or underlying payment processing system, which would then process the transaction and respond with either approval or decline. Consequently, the swipe data from the card’s magnetic stripe (known as track data) was passed through the merchant’s payment processing application.

With the development of software industry new needs emerged. These were the needs for wider payment processing functionality within larger applications specialized to service a specific market such as restaurant software, supermarket POS, health club management software, country club management software etc.

In other words, if initially, specialized terminals were designed exclusively for payment processing, later the need for an integrated solution emerged. The solution had to incorporate payment processing functionality, but, at the same time, it had to be specialized for a certain industry.

As business software packages became more and more complex, they had to incorporate many additional functions beside basic payment processing functionality. Since software package was involved in communication with the payment gateway, and, therefore, had access to credit card information, it was getting within PCI scope. Consequently, it required PCI audit (generally, a complex and expensive procedure). It was necessary to somehow reduce or eliminate the need for PCI audit of the software which was not directly involved in the processing of credit cards.

For card-not-present transactions the problem was solved by the introduction of payment pages. While payment pages allowed merchants to resolve the issue of getting most of their web-based applications out of PCI scope, for desktop applications (and web applications, for which usage of payment pages was not feasible or desirable) the issue of PCI scope reduction remained relevant.

Encrypted MSRs

One of the solutions of the above-mentioned problem became available with the introduction of encrypted MSRs. An encrypted MSR functions just as an unencrypted (traditional) MSR. The only difference is that card data is encrypted at the point of swiping, using the encryption key injected in the device. The decryption key (to decrypt the data) is only available to the payment application, which will eventually handle this transaction and is not available to the software package that the merchant uses to run its business. Consequently, only the PSP’s payment application (which does have the encryption key) is capable of decrypting the swipe. So, when the swipe is read, neither the merchant, nor the business-specific software application, are able to decrypt it. Thus, only the payment gateway remains within the PCI scope (but PCI-compliance is a standard requirement for any payment gateway).

However, encrypted MSRs do not address one subset of scenarios, which, while minor, still represents a sizable number of transactions for retail businesses. Particularly, sometimes a card may be unreadable, so that the need for keyed entry arises. The card number, its expiration date and other data for a transaction has to be input manually in some way. Therefore, a business software package relying on MSRs cannot stay entirely out of PCI scope.

To avoid abovementioned scenarios and to enhance the way of dealing with credit card transactions in retail industry, payment terminals are used.

Payment Terminals and Their Types

Unlike a reader, which is a peripheral hardware device, a terminal is a mini-computer, specifically designed to facilitate card-present payment processing. It has its own operating system, which can run applications within itself. It has its own network card and can communicate with external systems, such as payment servers, directly. Consequently, it has the ability to establish a data flow of its own between itself and a payment application, which is not going to involve the software application that controls it.

There are several advantages that terminals have over MSRs. On one hand, a terminal allows a business to accept card swipes, while on the other hand, more advanced terminals allow for keyed entry of credit card data, PIN-based transactions and supplementary functionality, such as ability to round up change for charity donations, tip adjustments, customer satisfaction surveys, etc.

Payment terminals are generally classified as standalone terminals and attached terminals {http://global.verifone.com/}.

A standalone terminal has no API or DLL of any type through which an external application can communicate with it. It is mostly used by smaller businesses that use terminals simply to process payments. These businesses, generally, either do not rely on any software package to run their business, or use manual process to reconcile all the payments. Example of such a business is a small restaurant that handles orders on paper and just needs a way to accept credit card payments from customers.

An attached terminal has an API or a DLL that allows an external software application to interact with it. Consequently, attached terminals are generally used by those businesses that rely on some software package for their day-to-day business activities. Example of a business using an attached terminal is a supermarket where payment terminals need to be integrated with the main POS application.

Attached terminals provide a unique advantage to applications that rely on them. A business application is able to initialize the transaction providing terminal with the amount as well as various details (such as item listing, which can be displayed on the screen) through the API. After that the terminal captures the credit card information (either swiped or keyed) or PIN (when applicable) and sends it to the payment gateway, gets a response (approval or decline) and forwards the response back to the business application, without exposing cardholder data to the application itself.

Conclusions

Terminals are ideally suited for purely retail businesses that do not utilize recurring payments in any way, because, in most cases, these businesses do not have any provision for cardholder data flow from the system to the payment service processor (within the context of their application). Those businesses, that (in conjunction with their retail operations) utilize some type of e-commerce functionality and potential recurring billing, can use a combination of terminals, payment pages and tokenization techniques in order to be able to process transactions (accept payments) of various types, but still remain outside of PCI scope.

In cases when payment pages are a suitable option and the cost of terminals (which are more expensive than MSRs) is a major concern for a business, the preference may be given to encrypted MSRs. The only thing to be kept in mind in such cases is that MSRs do not support PIN-debit and EMV card processing on their own.

Payment Concepts: Cardholder Data Flow

This is the final installment in a mini-series of posts dedicated to PCI compliance. The purpose of this particular article is to familiarize merchants that have to accept payment card data and store it, so that their software is involved in cardholder data flow, with some solutions, allowing them to improve their flexibility in terms of PCI compliance.

If you have not read the intro, we recommend that you start with it, as it will improve your understanding of the current post.

The general solution, allowing merchants’ front-end software (web-site\CRM) not to be involved in cardholder data flow is to avoid touching credit card information. There are three ways to accomplish this: using a filter, using a hosted payment page (PayPage) or using a server request interceptor.

Cardholder data filter

When a merchant has a big and complex application with many different data flows, and it is desirable to take the application out of scope, it is possible to reconfigure the system in such a way that all of the incoming and outgoing messages are going through a sanitizing filter (so that the main application is connected to the outside environment only through this filter). The filter could use some sort of algorithm cleaning the credit card information from the incoming messages (replacing it with tokens) and inserting credit card information into the outgoing messages.

This scenario is intended for more complicated systems that need to receive messages from clients and exchange messages containing credit card data with other systems.

This filter solution is a server-oriented one, capable of reducing the PCI scope of a business (because the filter application is still touching the credit card data) but not of completely eliminating its PCI responsibility.

Hosted payment page

Hosted payment page is a common solution for smaller applications that simply need to process payments (and require credit card information only for that).

If the needs of the merchant are confined to accepting payments in a secure way and keeping its own front-end application out of scope, it can rely on a hosted payment page to collect credit card data.

In essence, a PayPage is a web-page that contains fields to gather credit card information. The merchant supplies the payment amount (how much to charge) and description (what to charge for) to the PayPage, and the PayPage collects credit card information and then processes the transaction (pushing the result back to the merchant via callback).

For example, a merchant has a shopping cart as part its own web-site. At the time that payment needs to be collected, a redirect to the PayPage occurs (specifying the payment amount and the information on what the payment is charged for). The PayPage (residing on a PCI-compliant server of the merchant’s payment processor) takes care of the rest. The user enters credit card information and the merchant gets a payment confirmation, or transaction response, which might include token for the merchant to store if it needs to reuse the card in the future.

Server request interceptor

An interceptor is somewhat similar to the filter, only it operates on the client’s side and is used as a solution for web-applications. The interceptor is a script (usually, Java script) residing on a PCI-compliant server, that attaches itself to a static form (responsible for taking in credit card information), and is able to intercept the request when the customer puts in all of the information and hits the “Submit” button. The form gets rendered, the user enters credit card information and submits the form. The script then intercepts this request and sanitizes it by dynamically extracting the credit card information, converting it into tokens and re-inserting them in the request, that is subsequently sent to the server.

Since the page itself is static, the interceptor script itself comes from a PCI-compliant server and the request hitting the server no longer has the credit card information in it, the entire application is, technically, out of PCI scope.

Conclusion to the PCI compliance mini-series

Although the final decision is always made by the assessor\auditor (especially, when a merchant is processing large volumes of transactions), there is a whole range of solutions allowing merchants to reduce their PCI scope or get out of it. So, even if a merchant doesn’t have resources to go through the full PCI audit, there are still ways allowing the merchant’s business to accept credit cards.

Our development has experience of using all three types of techniques, so if you need an advice on implementation of any of the described solutions, do not hesitate to contact us via our “ask question” page.