The website is beautiful, but I don't even think the notion of a "javascript shopping cart" should exist. It's stupidly dangerous. This is real money we're talking about! Wow.
It's not a big deal. Just do a check on the backend. You can swap price tags in stores too, and they most certainly will not honor it if they realize.
I've done a mid 5 figure number of transactions through PayPal for digital goods, and I don't use the encrypted links (mainly because Flash doesn't support them). There have been a remarkably small number of fraud attempts (<0.1%).
One guy bought a game for $0.01, then initiated a chargeback when it didn't arrive. I raised my eyebrows, issued a refund, and the matter was over.
Not being able to trust the client is intrinsic to JS shopping carts, but I don't think this is a critical flaw.
Although I don't see what prevents merging the JS cart with a web based cart on the checkout page. Send the contents, and the page with the big 'click to charge card' button is generated server side.
Actual transaction happens in Paypal's page. Not for a complete e-commerce site, but for simple usages with few products i beleive this is a good solution.
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?
Great 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).
I got super-excited for a moment because I'm literally in the midst of a weekend project putting together, well, a simple online store (I'm a novice - yes, these things still take me a weekend ;)
But this is, alas, too simple. I'm actually taking the plunge and building a Rails app.
Anyone have some good/great/awesome JS shopping cart suggestions that are perhaps equally-simple in theory but a bit more robust?
I'm using Rails, ActiveMerchant and Stripe.js so far (been looking for a good excuse to actually use Stripe - psyched to try 'em out).
Something between this and Spree, which is massive massive overkill for my purposes.
FYI - this is a day late but this is exactly what I decided to do. Moment of zen in the shower when I realized "yes, I need to learn rails and this would be a great opportunity to get better, but I also need to ship the product so why am I reinventing the wheel?"
Shopify is fantastic so far. Still getting my Rails chops dirty playing with webhooks and some post-order processing, so it's not all lost :)
Hah, I too got excited (and almost mad) when I just saw this as I just spent the past week building a django-based ecommerce solution for a custom project... This might have potential but I'm not convinced. It is interesting though. I'm also using stripe for my project and excited to try them out:)
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.
I don't see what the big deal is with this if it's for physical products. You'd obviously just verify before shipping. If it's for digital goods it clearly wouldn't be a good idea though.
Can anyone help me email the contents of the cart when the user presses 'checkout'? I've spent over 8 hours trying to do this and have had no luck (4 last night, 4 today). I don't know much javascript so any help will be very much appreciated.
My business doesn't need customers to pay online, they will pay in person. I just need to receive orders through email.
No specific date, just that they are working on it. It does currently support checkout-via-post though, so it wouldn't take much php (or whatever) to make it work.
Something super trivial, but I can see the down arrow on the Items toggle button seep through... On Chrome 23.0.1271.64
Nice little library though. Interesting comments regarding changing prices.. Curious how paypal handles things like that (since on Paypal's side you don't really create "products" do you?)
I've spent about 3 months looking for shopping carts on and off and this one was one of the carts I was considering. I abandoned the whole javascript hard coded shopping cart idea because it was simple in the short term, complex in the long term.
These javascript hard coded shops are designed for people who feel comfortable around code, re-sizing images, ftp uploading, and editing html files. But those VERY same people who are comfortable around code are better off to just install a managed store with a database (Word Press e-commerce), which will streamline everything, keep track of inventory, etc... So they don't have to hard code anything and their store can grow.
They can just install wordpress in 5 minutes, wp e-commerce in 5 minutes, find a free theme they like and install that, and have a store ready to go. All without touching code. They can drag and drop all their images and never have to ftp files or edit .html documents to change prices.
I don't want to shit all over this beautiful little cart. It's perfect if you already have an HTML site that ISN'T wordpress powered. But it's just not an elegant solution. Or a logical one.
Here are the other solutions.
- Gum Road.
- Paypal Buy it now / Add to cart / View Cart buttons.
- Word Press e-commerce, woo-commerce, marketpress, and all the other competitors.
I tried out Plum Cart (another javascript cart) from codecayon.net, and it was just such a pain in the ass to have to hard code everything. Let alone the limitation of no USPS real shipping calculations or stock management. Setting up wordpress was the best choice for a small little store.
I ended up going with WP e-commerce.
=== WP e-commerce ===
It's free, comes with everything you need to get started, does downloadable items, and you can buy the stripe plugin for like $37. It has only 3 stars but over 2+ million downloads, the team behind it got overwealmed by the usage, and the USPS module is probably causing all the frustration. A lot of stores run WP e-commerce. You'd never know unless you roam around the support forums and see people post links asking for tips and code changes.
=== Woo-commerce ===
Pain in the ass to do variations. Very polished. Simple in many ways, complex in others, not ready for prime time. Does downloadable items. I left it after that.
=== MarketPress ===
$19 one time. Even less ready than Woo-commerce. Comes with Stripe module, VERY polished. NO good shipping calculations if you store sells diverse items. Does downloadable items. Does not have Paypal Payments Standard, only paypal express (must upgrade to business account).
NOTE: if you're using ANY USPS shipping calculation module, your USPS webtools api account must be set to LIVE product mode before you can recieve quotes in your shopping cart. Test modes DO NOT WORK. USPS doesn't realize this. You have to email them manually to get your account out of TEST and into LIVE mode.
WP-Ecommerce has three stars because the owner (who isn't a developer) aggressively marketed the plugin and left it's users hanging out to dry. Updates were done by several hired developers who ended up making a mess of the code. Anyone who wrote a negative review about it was met with an abusive comment from the owner.
This was two years ago since I last tried the plugin so I don't know how support is now, but the way it's written is unsuitable as a reliable ecommerce platform. I tried to set up a jewelry shop for a client who had bracelets in different colors and designs. It wasn't until the website slowed down to a crawl that I found that the system created 30 bracelets x 8 colors x 15 designs = 3600 records in the database. Every time you tried to update a price all 3600 records needed to be updated. And as most people know doing anything 3600 times in WordPress is a pain.
Woo-commerce and MarketPress are much better, but at the moment there are no good e-commerce solutions for WordPress. WordPress has become decent for use as a CMS but if you're looking for an e-commerce solution your best bet would be a stand-alone system like OpenCart or managed like Shopify or Magento Go.
A lot has changed in 2 years. There have been a lot of updates with a major architectural ones just a few days ago. As well as 5 star ratings from developers who have seen the project grow.
I tried opencart a while back and I just didn't get it. There's theme templates in multiple folders, it's over kill for a store with just 4 or 5 products, and its design and layout was too set in stone. I never found a theme I liked. I wanted something that I could install, strip down to the core, and build my really simple, really minimal store from. Open cart wasn't flexible or minimal in that sense. The user has to click, click, click, to get anywhere. It felt like all the products where categorized and tucked away and the user has to find them. Maybe it's possible to change via heavy template modification but I haven't seen any template actually do that.
It's easier for me to start with something minimal like wp e-commerce and build it up with modules, than to start with something overly templated and featureful and try to tear it down to simplicity.
Interesting that you're rundown is the opposite of what I've recently heard.
I run a small WP group and we invited a couple of companies to come along and share their experiences in using WP for ecommerce/sales and WP e-commerce was slammed pretty hard.
WooCommerce was given a lot of praise but they, like you, agreed it was early days.
None of them had used MP but I've used it for a large project when it was very early in development and my developer hacked the core so much (we needed digital downloads) it no longer resembled the original product.
A few other carts were mentioned, none really of note. I think the point that you made about 'comfortable around code' is perfect, none of these are really for the novice.
My biggest complaint are the stock templates. They're a huge mess of strange indentation and tables for layout. The strange glitches with WP_DEBUG set to true were a bit frustrating as well for a plugin that should have these kinks worked out by now. This was last week.
Nice breakdown of the current landscape, I'm working on one of my own and I'm really in need of feedback before I give it a public push.
Mine doesn't really do a cart yet, but it does the purchasing flow with only one code insertion on the site. Stripe and a few other features are in my short term roadmap.
If you expect to sell a lot of volume or have a lot of products in your inventory, I recommend OpenCart http://www.opencart.com/. It's free & opensource has a lot of features, templates and plugins. Allows you to manage sales and inventory very well and also easy to use like Wordpress.
Tried WP-Ecommerce about 2 years ago, and it was totally unusable - kept breaking. Support was poor, even when paying for it. Have things gotten a lot better since then?
Yeah, they've hired people and had a lot of fixes and upgrades. They're updating it constantly now. Just in the last 2 weeks it had 2 updates, one being a major update.
Also, this confused me for a few seconds...I thought dials went clockwise ;) http://i.imgur.com/QEl7v.png