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

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.

Conclusion

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.

Online Marketplace Model

With the success of eBay, Uber, AirBnB, and other similar online marketplaces, the concept of an online marketplace is rapidly entering new industries. As a result many modern software companies are providing online marketplace software for these different industries. Consequently, the problem of payment handling in marketplace-type systems becomes more and more relevant.

What an online marketplace is

Online marketplace is a platform, allowing its users to exchange products and services, which is provided and supported by a third-party entity. Examples include eBay and AirBnB.
Plenty of different companies develop software for online marketplaces. However, the need for effective organization and support of complex payment processes at online marketplaces maintains its relevance.

The difference between an online marketplace and a conventional business

The main marketplace-specific problem is as follows. During a traditional transaction, when a customer pays a merchant for a purchase, the merchant receives the money with a small processing fee withheld. The fee is retained by the processor (the company that processed the payment).
In an online marketplace two conceptually new components were added to the above-mentioned simple transaction processing mechanism.

The first one is as follows. In an online marketplace situation there is an additional party involved that needs to be paid for the service vended. So, when the merchant is paid, a fee has to be withheld (as in the conventional model). However, it needs to cover not only the cost of processing, but the cost of the service of the marketplace. Let us use examples to illustrate the difference.

Example 1

John purchases a T-shirt for $20 in a store and pays with his credit card. The store receives $19, while $1 is withheld by the bank that handles credit card processing for the store.

Example 2

John buys a $20 T-shirt at an online marketplace. The merchant receives $18.50. $1 goes to the bank that processed the transaction, as in Example 1. However, $0.50 from the transaction needs to go to the marketplace owner.
While it is possible for the marketplace to collect its fee as a monthly subscription, or as a separate (second) transaction, it is preferable to be able to withhold just one fee from the main transaction, and then – split it among any other parties, such as affiliates, that are involved.

Moreover, the marketplace owner is not the only new player in comparison to a conventional business.
Another important thing to consider, when dealing with marketplaces, is the affiliates. We are talking about third-party blogs and web-sites, which handle the promotion of different products (ads, which we see in blogs, leading to online marketplaces like Amazon and eBay, provide vivid examples of such promotions). Say, a blogger writes about different cleaning products and detergents. She writes about unique cleaning products, and references a link to the web-site (online marketplace), where these products can be purchased. It is expected, that the blogger is going to receive some small commission of every purchase that is made through the link from her blog.

Example 3

John smears his newly-bought T-shirt, goes online and finds the blog, providing some useful information on where effective detergents can be purchased. He clicks on the link in the blog and purchases the detergent at the online marketplace. Now, beside the fees, the bank and the marketplace owner are entitled to, the blogger should also get her small share of the transaction amount.

As we can see, the traditional transaction processing model does not fully meet the needs of an online marketplace. Online marketplaces have a need for split funding, i.e, they require the ability to split an original transaction into multiple sub-components (smaller payments), that can be distributed among different parties, such as affiliates.

Conclusion

If you want to build your business in accordance to the online marketplace model, you need to select the right payment processing partner, who, potentially, is capable of providing flexible split funding functionality. Although you can go with a traditional processor and build the split funding logic yourself, you are likely to experience many challenges, and still the process might not be transparent enough. Consequently, it might be better and more profitable for you to partner with a payment platform, which already supports split payment functionality. It might also be useful for you to check, if a payment facilitator model is the right one for you.
In the next article we are going to address two basic split funding models.