I am currently implementing Android in-app payments, and am wondering what attack vectors I should look out for.
I have a simple application to view server-generated content. I want to allow the user to buy additional access in-app, and would like to know how to communicate a successful transaction to the server.
A quick summary of how Android in-app payments work:
- The app sends the user to Android Market with the product to buy
- The app is informed by the Market when the transaction is finished.
- The app requests transaction information using a nonce.
- Google sends a response to the app with the transaction record, repeating the nonce, signed with a developer-specific private key.
- The app can check the data using the nonce and the signature (+ public key).
- [update]: Android transactions always include a timestamp, and my app adds a GUID to identify the client. (both are in the signed transaction record)
More info here: http://developer.android.com/guide/market/billing/index.html
My current plan is to sent the full transaction record to the server, and check against the public key on the server.
Some questions I have:
- Is my plan inherently flawed?
- Is it preferable to generate and check the nonce server-side as well? Why is that nonce used anyway?
- Is it necessary (preferable) to use HTTPS when communicating with the server?
I'm not protecting private or top-secret data, but I don't want to make it easy for an attacker.