Integrating payment processing into mobile apps, or why you can forget about PCI DSS / PA DSS
Sooner or later the majority of owners and developers of internet stores and mobile applications who take payments online will ask themselves: “should my project comply with PCI DSS standards?”
PCI DSS is a security standard used by all organisations which handle card payments: retail outlets, processing centres, financial institutions, service providers and other organisations which store, process or transmit cardholder information and/or critical authentication data.
With a website everything is quite simple: During the integration process, it is sufficient to use a technical solution which re-directs the payer to the site of a PCI DSS certified payment gateway (so-called hosted payment pages) or loads the certified site within a frame on the original website. Either way, the buyer is directed to a form where they enter their card information.
In such cases, the seller is not subject to the security standards since he does not store card data and it is not transferred through their servers. Plus, owing to the security policy of web browsers, they do not have access to the payment gateway frame.
With a mobile application things are a bit more complex. There is a popular misconception that if a mobile application requests card data then it is automatically subject to PCI DSS standards. But in fact, the organisation behind the development of PCI DSS standards (the PCI SSC — Payment Card Industry Security Standards Council) has not up to now issued separate requirements for mobile applications. This means the standards remain voluntary and not obligatory for the most popular category of mobile applications, specifically:
Category 3: Payment applications operating on any consumer electronic handheld device (e.g., smartphone, tablet, or PDA) that is not solely dedicated to payment acceptance for transaction processing.
Since a mobile application cannot exist without a back-end (the server side, which covers billing and the main business logic), one way or another the information required for processing a payment will pass through the seller’s server. But there is a nuance here: in order to ensure that a developer does not, accidentally or intentionally, programme an application to transmit card data to any uncertified servers, a mobile payments SDK should make the card data unreadable. This restriction ensures PCI DSS requirements are nullified:
PCI DSS may not apply directly to payment application vendors unless the vendor stores, processes, or transmits cardholder data, or has access to their customers’ cardholder data.
Let’s examine how this works in the mobile SDK of payment service Fondy using the Android version as an example.
Fondy is an international payment service available in Europe. It offers a wide range of solutions, including:
- Classic internet acquiring
- White label processing for web and mobile
- An accounting centre for all types of online businesses, from internet service providers and online retailers to dating sites and taxi services
The solution entails the card data being inputted into a View created by the SDK library, whilst the mobile application uses public methods of this View in order to initiate the payment, stylise the form and receive information about the completion of the payment.
An example of a demo application for Android
To start with we create a visual structure for our payment form — a layout (all the source code of the demo application can be found at github):
Make sure all the elements in the application, apart from the card data, are yours and that the form for inputting the card number, expiration date and CVV2 are encapsulated in the class com.cloudipsp.android.CardInputView. This is approximately what it looks like (for tests you can use the details shown in the documentation: https://docs.fondy.eu/docs/page/2/):
However all the elements, including those belonging to the class com.cloudipsp.android.CardInputView can easily be stylised according to the design of the main application. For later work with applications and cards enrolled in 3DSecure service, we will need elements of the class com.cloudipsp.android.CloudipspWebView. This is a WebView, in which the payer is re-directed to the site of his/her issuing bank in order to type in their password.
Now we’ll move over to our main class, which will implement the application logic: public class MainActivity. We initialise the object of the class Cloudisp:
Next, we put a handler onto the object of the class com.cloudipsp.android.Card in order to receive the results of the entering of the card number:
Now we’ll know when the user has finished entering their card data or, in the case of an error, we’ll receive information about the problem. After card data has been entered, we can create the order:
As you can see, integration is fairly simple and does not require special effort from the application developer. What’s more, the SDK solves two problems simultaneously: it gives the vendor a method to accept payments via card and saves them from having to get security certification.