[lowtto]

It's not that processing payment client-side is wrong, it's that the Dominos app implement it wrongly, or DataCash simply doesn't provide any security feature for protecting against http request data tampering, which I believe the latter is not the case.

Most payment gateway have a security mechanism to ensure the response from payment server have its integrity remain intact. Most of the time by hashing some combination of responses value and shared secret key between merchant and the payment server, and comparing if both marchant calculated value and payment server hash matches. If it doesn't match, then it is safe to to throw an error and prompt appropriate message to said attacker. When implemented as such, the system are expected to immune to such attack as described by the author.

The article is a perfect case study to showcase the consequences when the developer decided to skip the security part. (yes it's entirely up to the web master if they want this or not, the payment server won't care).

[aj_n]

> Most payment gateway have a security mechanism to ensure the response from payment server have its integrity remain intact.

I've definitely seen SSL pinning used to this effect. The simple solution to Dominos' problems seems like a server-verifiable transaction token that coming from DataCash (or whatever gateway service). I agree that client-side payment processing isn't wrong -- in fact, it makes more sense than attempting PCI compliance on their middleman server.

[nolok]

From what I've seen, most developers understand "the client's sent data cannot be trusted", but they fail to understand how much it entails. It's not merely the forms they send, it's all of it, cookies, user agents, internal tokens that pass through Javascript, whatever. If the client touched it, it's compromised!