This seems to suffer from the source of prices being the html itself. This implies trusting the client - I'm a web inspector away from choosing what I want to pay.
Clever hackers can change prices of simpleCart(js) items before checkout. This is a known security flaw that exists with ALL javascript shopping carts. It is highly recommended that all orders be checked upon receiving or backend security checks be put in place (View Tutorial.)"
Agreed. I wonder if you could put a clause in your terms of service that states you will not give refunds for modified price amounts?
Then on your confirmation page, just have a nice "Thank you for your donation. Unfortunately, you won't be receiving any goods. Please see our TOS for details."
One issue with this, besides the possible legality of it, is if they used their credit card they could just dispute the claim. Stripe for example charges you $15 anytime someone disputes one of your charges even if you didn't do anything wrong. So you'd probably end up being out more than if you just refunded the money. Not sure what PayPal, Google checkout, etc policies are on this although I'd imagine they're quite similar.
I would completely understand if this _was_ a server side shopping cart, but it's not. It's a client side shopping cart which you can use on any architecture - you just have to give it data, and then check the data at payment using whatever server side language you want. It's not any different to a Spine or Backbone based project.
Just because it's JavaScript doesn't mean it should be in npm, similar to just because a project is written in ruby doesn't mean it should be in rubygems. A lot of the time, there's no reason for a ruby project to be bundled as a gem - it just ends up polluting an already crowded package management ecosystem. I wasn't sure if there was something I might have missed about npm. To me, it seems like it would be something that would be better managed with Bower ( http://twitter.github.com/bower/ ) given you don't (and shouldn't!) need npm in order to use it.
I read your original reply to hayksaakian as an enquire as to why hayksaakian would assume the js to be related to node since the js is client side.
In that context, my reply means that since hayksaakian started with the assumption that it was server side, it's only logical that he would conclude the js to be a node module since server-side javascript's most popular implementation is node.
Of course, looking back I see that I may have misread hayksaakian's reply.
"What simpleCart(js) Does Not Do:
Is Not: Foolproof
Clever hackers can change prices of simpleCart(js) items before checkout. This is a known security flaw that exists with ALL javascript shopping carts. It is highly recommended that all orders be checked upon receiving or backend security checks be put in place (View Tutorial.)"