3 ms·
I think this is a great idea, despite its obvious flaw. To make it a better offering, I would probably add sample custom payment gateway "proxies" in common la
by shousper 14y ago
I think this is a great idea, despite its obvious flaw.
To make it a better offering, I would probably add sample custom payment gateway "proxies" in common languages (i.e. PHP, Ruby, etc.) for security.
What I mean by proxy is provide some generic server-side code as a middle man for the payment gateway which can confirm the details of an order (on your server) haven't been tampered with before forwarding onto the actual gateway (PayPal, etc.)
This way, the shops who don't mind dealing with dodgy purchases can run 100% client-side, while more others can use this feature to prevent invalid orders being created.
Am I talking sense, or day dreaming and missing a big inherent flaw?
- gingerlime 14y agoGreat suggestion. This way people can use their existing server-side payment integration if they need to, manage stock levels, sanity-check the customer address, run fraud-checks or whatever they need to do before the order is processed and payment is taken. It should virtually eliminate the js security flaw. Or at least give the chance to eliminate it. It makes implementing a cart on a website much simpler because you reduce the interface points between the client and the server to one (at least as far as the actual cart needs to keep itself updated).