Is it bad to implement a payment system using JavaScript?

Question

I am wondering here is that is it a bad idea to implement a legal payment system using JavaScript on the client-side and PHP on the server-side? I am mainly worried about IEEE floating point and overly loose languages.

Answer 1

The main problem is Javascript, which doesn't even have a real integer type, let alone an (official) proper decimal library (PHP has BC Math). There is an old third-party port of Java's BigDecimal to Javascript you could use on the client side. Alternatively, calculate everything in cents, since an IEEE double can accurately represent integers up to 53 bits in length, which is enough to hold even the entire US sovereign debt for at least another 10 years (probably).

Answer 2

I would say it depends on how you implement it. Javascript runs on the client side and is therefor not secure. It cannot be trusted. Also, it means your system will not work for people who have Javascript turned off or use older browsers.

As long as you keep that in mind, use the PhP to handle the secure stuff and check everything that comes from the Javascript and are willing to lose those who do not have Javascript, then I don't see a problem with it.

But doing all that can be harder than you would think, so be careful.

Answer 3

The real issue, as others have noted, is that you can't trust the client. Ever. No calculations ought to be done on the client side, or using data (such as price) coming from the client. Beyond that, I would never use a float to represent monetary amounts. Money should always be represented as an integer where 1 represents a single unit of the basic unit of currency (e.g. cents). it complicates matters slightly but do yourself a favor and create some easy accessor functions and your life will be easier for it.