I am working on a mobile ticket sales app. The system allows users to pay for items using a 3rd party api (CardIO) saving all info to my server sitting happily up in the cloud.
The problem boils down to:
Because (1) the payment process occurs entirely on the phone, and (2) there is no API that allow my server to verify with the payment processor that the payment has actually occurred, I am left wondering how best to go about verifying that the user has indeed paid for the item before marking it as paid in my database on my server.
You see, a user could follow my api calls manually, log into their account, and then send the command to my server to mark a purchase as paid without having paid for the item.
So the question is:
How can I verify the payment has taken place either on my server, or through some sort of handshake or encryption with the mobile app?
My current approach:
I am sending the plaintext information needed via a SSL (HTTPS) call to the server. Along with this, I send a hash of that string and verify using the same algorithm on my server that the string sent matches the hash sent. The thought being, that I could then use some sort of secret key to generate this hash and then verify the plain text matches the hash on the server end as well to ensure that nothing has changed. My problem with this solution, is that I don’t think it is really that secure… Someone could, rather easily crack the algorithm, because they are given the encryption and the plain text.
Thanks for looking!
Stephen
The short answer is that you can’t trust the client, period. Hack around it all you want — that’s no way to build transaction information.
If your payment processor doesn’t have an API that you can rely on, then you need a better one… which solves your problems immediately and for the future.