Payment processing in Android

Question

Assume that my company is PCI DSS complaint. I want to provide a custom view (in SDK library for Android) for payment processing to merchants who sell products via their Android mobile application.

The main goal is to make payment without giving access to merchant on payment details: card number or CVV.

My view will have inputs for the card number, expire date and CVV, but mobile payments SDK should make the card data unreadable for merchant APP. All this is explained here.

If I create a custom view for this task in the SDK library, how can I make sure, that a dishonest merchant won't unwrap my library, rewrite it and catch my payment calls to web service and log security data in his database.

How can I make sure, that calls to my payment web service are really made from my custom view?

Answer 1

This highly depends on the adversary you are proposing.

If by “unwrapping” you mean disassemble and patch, then you got yourself a threat model you can not defend against and here is why:

If you suppose they can disassemble and patch your code, they can basically do whatever they like - after all, it’s their application and they then use their own code that only appears to be yours.

Additionally, any secret you might use to verify a request came from a valid SDK instance (for example request signing) can be reverse engineered by such an adversary.

All in all, it’s the merchants application and they can run whatever code they like and it’s the consumers device you have no control of it’s running on.

This - by the way - is the reason that apps for payment are either from the operating systems vendor or a separate application that is linked to within the vendors app (for example Apple Pay, google wallet, PayPal).

Additionally, just to be clear: rooted devices might very well be used to dump all data in memory, thus there is no complete security.

Also noteworthy: any communication with your back end should be TLS-secured, including certificate pinning within the app to counter any MITM attacks.

Implementation details are off topic here and I will not cover them - you might have better luck with that on SO.

Answer 2

If I create a custom view for this task in the SDK library, how can I make sure, that a dishonest merchant won't unwrap my library, rewrite it and catch my payment calls to web service and log security data in his database.

You need to understand one very simple rule that Raph Koster put very succintly

Never trust the client. Never put anything on the client. The client is in the hands of the enemy. Never ever ever forget this.

While Raph is talking about online gaming, it still applies to just about everything else. Especially this part you mentioned

The main goal is to make payment without giving access to merchant on payment details: card number or CVV.

You can't prevent that. If I develop an app with your SDK, I can collect and store whatever data I please. Reading between the lines, it sounds like you're selling your PCI-DSS in your SDK, but your clients will develop the app. Understand, people can (and routinely do) repackage Android apps all the time. It's trivial to do.

In other words, your business model won't work. The client, by definition, will have to collect the data first and then pass that data to you. If they elect to store that data (in potential violation of PCI-DSS) you can't stop them, and you would be in trouble should said client(s) get hacked and have that data stolen.