Commerce.js 1.0 - Create the best commerce experiences with API level control

@paul_benigeri Yeah! The ability to easily A/B test checkouts was a feature that kept coming up when speaking with developers and merchants. Commerce.js lets you create as many checkouts as you want and have true control over the purchasing experience for your checkouts. Test a multi step checkout vs one page checkout. Test a heavily branded checkout vs a more traditional plain checkout, all are simple to design, implement and launch. CJS plugs into any major analytics platform so you can determine which has the best conversion rate and track your customer purchasing journey. You can literally implement any design or flow you can think of to see what resonates with your audience!

@paul_benigeri @devenkoshal @andrunder One other interesting potential is re-engaging abandoned cart customers. For example if you notice a customer dropped off on the 3rd page of a multi step checkout you could then re-engage them with a single page checkout. Our tokenization approach lets carts & checkout "instances" live for up to 7 days and accessed anywhere - They drop of on their desktop during a multi step checkout, you can re-engage them on their phone with a one page checkout.

@andrunder Yeah sounds great. The deep integrations of cart + customer info + billing seems very powerful. Connecting everything together is usually the hardest part. Thanks for the additional info.

Would be great to have a complete showcase of all the different live sites using it currently, with an optional description of what is Chec / Commerce.js stuff and what they did.

@balupton We will definitely be doing that when we have enough examples. We're thinking of something similar to https://framerjs.com/gallery/ but with checkouts/purchasing experiences you can download or view.

@vhmth Thanks man!

@devankoshal of course - keep killing it!

@sam_maclean thanks!

@joethomas_x @andrunder Thanks Joe! That really depends on what your trying to create, at the most basic level you could have something up and running inside your existing website in a matter of hours. The longest part of any eCommerce integration is usually in the creation of the checkout. Checkouts are notoriously difficult due to how dynamic they need to be. The customer changes one thing that could trigger something else that needs to happen etc. It's for this exact reason why we created helper endpoints to do the heavy lifting for you when you build with Commerce.js. Some examples of what the helper functions do: - Create client side validation rules which can be passed straight into jQuery, all you have to do is make sure your input names match - simply call "Commerce.Checkout.helperValidation()" - Calculate live tax rates for an order - just call "Commerce.Checkout.setTaxZone()" - Check if the pay what you want price entered by the customer is valid - "Commerce.Checkout.checkPayWhatYouWant()" We even built-in a few helpers purely to help the developer/designer such as; - Getting a list of countries for a dropdown - Getting a list of states/provinces in a country for a dropdown - Calculating the buyers location from their IP address (If you ever wanted to just pre fill address inputs or just have it handy) (For a full list of current helpers, check out the docs - https://commercejs.com/docs/api/...) What's great about this approach is that every time a helper function is called that influences price, for example setting a new tax zone or verifying if a quantity is available, we can (and do!) return something we call "The live object" - https://commercejs.com/docs/api/.... This is a living object which constantly updates & changes based on what events are happening, it contains things like up-to-date totals, tax breakdowns for the current cart, and more. The entire purpose of the live object is to solve this question. "What new total(s) do we show now that X has happened?" There's not a set answer I could give here, but in a nutshell even the most entry level developer/designer with basic HTML/JS knowledge could have something up and running in a few hours to days. We want the kids at home that are up at 4am learning how to code to be able to use this, so we're trying to make the skill set barrier to entry next to none.

@drewbedard Thanks Drew, awesome you're already up and running!

@dylanjha Cheers! Checkout logic certainly is a big pain point when it comes to eCommerce builds, hopefully we've eliminated that for you now :)

@airjoshb @andrunder @devenkoshal - Yup we actually have them ready (thanks to Swagger) should be live post thanksgiving. Subscription items are still in development but yes it will! When we were rewriting the cart/checkout we wanted to make it product agnostic. All items should work together in the cart regardless of there settings. Product Types Digital Physical Items with PWYW enabled PreOrder Items Subscription items all will work together in the cart.

@devankoshal @andrunder @devenkoshal very cool. I am rebuilding a subscription based product right now—not sure if I can wait, but will definitely give it a whirl when it is ready.

@airjoshb @andrunder @devenkoshal No problem, subscription support is probably about a 4 to 6 weeks away.

@airjoshb Hi Joshua, just letting you know our Ruby SDK is now available - https://github.com/chec/commerce...

@mrdobelina @devenkoshal The primary difference between Commerce.js and Moltin is integration speed and the merchant dashboard. With Commerce.js you can launch in a fraction of the time. Our helper endpoints and general approach to integration contribute to this -> https://commercejs.com/docs/intr.... Devan goes into detail about it here - https://www.producthunt.com/post... Moltin's focus is on building eCommerce infrastructure. Commerce.js is focused on the storefront and "purchasing experience" integration as well giving 100% design control beyond the storefront. Our merchant dashboard is another big differentiator. We have a merchant first approach to everything we build and spend as much time focusing on the merchant as we do on the developer. We're meticulous about this as it is where the end user (merchant/admin) will spend most of their time after you're done with the integration.

@andrunder @devenkoshal thanks for the explanation! I'll be sure to check out Commerce.js with my developer.