2 questions: How does this compare to existing eCommerce back-ends like SnipCart, Ecwid, Foxycart?
And: I presume your service requires javascript to function (as all of the similar services do)... any chance of providing a non-javascript fallback such as a generic-looking checkout page hosted on your own servers (like when you use a paypal button to send users to their site to complete the final step of the transaction)? Please don't tell me that "everyone uses javascript yay" or that I shouldn't be concerned -- I know who my clients and their users are and I know what their accessibility requirements are :) (I always have to say this when I ask eCommerce services this question because usually they dismiss it out of hand and it's very frustrating when you have requirements that sites work even without javascript).
Firstly we’ve looked at all of these options and as developers got pretty excited by their potential. The problem was that we found them to all be lacking in some degree, Snipcart is only for the most basic ecommerce, Ecwid is focused more on widgets, and Foxycart requires you to use their hosted checkout.
Secondly every member of our team has been in a position at some point in their working lives where we’ve had to build applications that support all manor of strange legacy requests. We completely understand.
Yes, if you use our javascript SDK with the API, you would require javascript for it to work. That said, you could take the backend approach and then there would be no issues with supporting older clients or applications as it would all be handled by the servers.
We have been thinking about adding a hosted checkout page for exactly the reason you describe. it would probably be an option so that you can either use a hosted checkout page quickly, or if you want more control you can use one of our SDKs and build your own checkout.
When for reasons of security or server side logic we do not feel comfortable running code on the client, we run it on node and setup a simple API that mirrors the vendor's API. Say for example that you are using Firebase (we use this for a chat app) but do not want to expose keys or need to run some code on messages (validations, etc). It is not ideal b/c part of the reasons of using BAAS is to avoid maintaining a back-end component. Depending on your needs, some BAAS vendors offer a "server code" solution, for example Parse's Cloud Code, that way you still avoid setting up a back-end component on your own but still run validations. etc. Parse's in particular is well setup based on events (after or before you save an object). Incidentally, they too use node.
Naturally, for this approach, you need that the BAAS vendor offers a Node SDK (most do), or maybe some other stack (PHP, Rails, etc).
Ah, I see... so actually this is a big distinguishing factor that separates this from the other services I mentioned! Looking forward to playing around with this.
The pricing confuses me a bit - as a user, I would have very little sense as to how many API requests or how much storage I would need for an eCommerce app. Why not price simply as a percentage of all processed transactions (in addition to the payment gateway commission, of course)
There’s two reasons behind the way we’ve structured our pricing:
Firstly you can very easily circumvent our checkout flow as we don’t lock you into using the entire system, we could therefore be supporting a large store and never receive a payment.
Secondly we see transaction fees as penalising you for selling well. It’s tough to push a product when gateways already charge for payments. A combined total of 5%+ for every order would be difficult for store owners to swallow.
We decided that offering a free tier and flat monthly fees for our paid users would be more acceptable. As a user you know exactly what you will be charged for each month.
Thanks for the feedback though, we’ll see what we can do to explain API requests and storage better.
FWIW (and for my situation, which is mostly smaller custom-designed ecommerce sites built on top of CMS's), I actually prefer this pricing model. 5% per sale is tough to swallow (this is a big reason I've avoided SnipCart). But basing it on site traffic (which is effectively what the per-API-call pricing is) is an easier sell to clients.
That being said, I agree that it's a little confusing to understand (or rather to guess how much one will be paying)... might be helpful to clarify if I need to guess ahead of time, or if per-month pricing automatically just happens based on the resulting number of API calls. (And if a rate limit could be set that would help too).
One more thought about this... what happens if my site gets DDOS'ed... what's the policy on avoiding (or not paying for) massive amounts of API calls that are accidental or bot-induced?
That's the reason why we added the little bit of information about page-views to try and guide the user a little in case they had a store already.
We very quickly know when a store is under attack and we either (where possible) drop the malicious traffic, or we absorb it. We had a customer on our free tier (30k requests) that ended up processing over 3 million during a 2 day attack, his site stayed up and we still didn't charge him.
Just my two cents, but I see your point of view as well.
Why is it easy to circumvent your checkout flow? I would own the money transfer. If a developer doesn't want to build their own store, they probably don't want to bother implementing Stripe themselves either (and I probably have no clue how to estimate how many API calls I need).
Do your target customers really need payment gateway flexibility? The biggest drivers (I can think of) would be acceptance (by country & payment type) and transaction fee.
You don't have to call it 5%+, you could frame it as 1% + whatever the payment gateway you choose charges. That doesn't feel too egregious.
You can use our checkout and order system but simply drop out the payment processing. Stripe makes this very easy and while people may not want to do it, by charging them a percentage of each transaction we're almost incentivizing them to do it.
We do need gateway options, each country is different and we're always being asked by users for support of X. I can promise you if we'd been able to stick only Stripe in and use it for everyone, we'd of done it. Our lives would have been so much easier!
And no we wouldn't call it 5% but the store owner would quickly do the math and that's where we'd end up. It's a hard sell, we ran the model past a number of people and it was almost universally rejected.
The parent commenter's concern was that the pricing is difficult to understand. But you said one of the reasons you selected your pricing structure is so that users now exactly what they will be charged for. I agree that it's much easier to estimate sales then the number of API calls that will be used.
Another point to consider is that users have a monetary incentive not to use any new features you may come up with in the future. (Unless of course, they have strong reason to believe that implementing these features will provide a significant boost in sales.)
We also felt that it meant the people building the sites also had an incentive to be more careful about the way they did it - like sharing resources across a session and limiting the calls per page, or implementing caching. All of which actually improve the user experience due to slightly faster page loads, which in eCommerce is crucial.
Charles from Snipcart here. Pricing is indeed always a delicate matter in the e-commerce world. You'll always have customers preferring a model over another. We believe the Moltin pricing will make a lot of sense for some people, but others might prefer the no-risk percentage model. I'd say it strongly depends on the merchant's business model. Side note: the guys at Moltin really have a kickass website.
Exactly, we went through four revisions of our pricing and I'm not sure we'll ever be certain it's the "right" one. We just knew we had to simplify it and after user feedback this is the one that stuck.
And thanks for the kind comments, we've always loved your animations and the attention to detail you put into your site. I mean who doesn't want a buy bacon button in their header?
Do you plan on adding modules?
Would you be willing to add features via partnerships?
Your "full" ecommerce stack lacks a few things that could be added either into your core or via external tools.
We have a really strong community ethos at Moltin, and we’re trying hard to open up as much of our platform as possible, both in open source and community modules.
We know there is still work to be done and we have a pretty lengthy set of features and updates going forward.
Interesting. Don't most of the ecommerce-as-a-service companies offer an API these days, or am I mistaken? How would this be different if they do? The pricing model?
Hi there, co-founder here. A few of them do have an API offering, but there's a few issues with them -
Firstly they’re bolted on the side, and aren’t usually functional enough to actually power a full store - generally they’re designed for add-ons.
Secondly you’re locked into their whole platform just to get access to the API even if you’re not looking to build a website, or use all of their services.
We’re making a product that gives you the ability to pick and choose exactly which parts of e-commerce you need, in a way that doesn’t lock you into the product.
Hi, could you elaborate on how you prevent lock-in?
We are interested in moving away from TicTail for our own shop, but do not want to reinvent the wheel so we can focus on developing a few custom features.
Because we’re an API, you can retrieve, remove, destroy your data at will.
When you incorporate us into your app or site, you have a very loose relationship with our system. That means its very easy for you to stop using our product without having to rebuild from scratch.
In the future we’ll be making it even easier to migrate to and from Moltin with tools to import and export data.
We are yes, we started with what we knew and now are allowing the community to vote on what they want us to release next - https://moltin.com/getting-started#vote
Commercetools is a good platform and one of our closest competitors. The key differences are that our pricing scales a lot better, we don’t lock you into a single gateway or charge transaction fees. We also don’t arbitrarily limit the number of products you can store, or the bandwidth you can use.
We’re also more flexible, we have an EAV system (Flows) that allows you to modify and store custom data sets in a structured way. This allows you to use Moltin as a much bigger part of your product than just what we currently offer.
They do have a few more features right now but we’re pushing hard on the development front to reach feature parity with the major platforms.
What benefit does Moltin offer over CMS backed ecommerce service such as Drupal commerce and Woocommerce? Your website seem to emphasize rapid application development yet this is not too different from the CMS backed alternatives.
If you want a basic site quickly, then going with a platform like WooCommerce and an off-the-shelf theme may work well for you. Once you start customising themes and adding advanced functionality, complicated folder structures and functional programming styles can cause no end of problems for many developers.
API based means you’re not locked into a specific CMS or blog platform, you’re not even locked into a specific language or device. All we care about is data transfer and logic, leaving you free to do anything with the frontend.
If you want to know more about what our platform provides apart from rapid development, we’ve touched on them in our other comments.
Because we’re quicker and easier to implement. That gives the developer much more freedom to be creative with their application, especially if they’re working within a budget or short timeframe.
Our API also allows you to pick and choose the components you want, you can build more than just a website, your data is accessible on mobile or at a physical retail store all from the same platform.
We have support for modifiers (size, colour, etc.), singles (gift wrapping, etc), input (custom options or labels). We’re working hard to make sure our new docs platform has all of this in it, but you can find it in the API reference and use these via our dashboard (forge).
If you ever have any problems we’re always available on email or live chat :)
These all are features a successfull webshop needs. I have to admit I only took a brief look at the API, but all this seems to be missing. Am I mistaken?
edit: seems like Categories at least exist. I didnt find the docs at first. I suggest putting the Documentation link into the "more" dropdown in the navigation
The beauty of an API approach is the features we don’t quite fully support can be easily created by you within your application, and then work alongside our product.
We don’t explicitly advertise support for digital products at the moment, however, we can support it to some degree. Reach out to us on livechat or email and we’ll be happy to help.
There is no reason why you couldn’t do that! we’ve even open-sourced a bunch of our components to help people do it - https://github.com/moltin
The reason we created Moltin was to speed up this process, bring it up to modern standards, and give developers the creative freedom to use the tools they’re comfortable with. By not going down the self-hosting route you also no longer have to manage the installation, keep the codebase secure or worry about scaling.
Our main stack utilises nginx, php, postgres, redis and a few other things in-between, we’re built on top of AWS purely for the flexibility it gives us.
so basically the benefit here is saved time and reduced operating costs by outsourcing the ecommerce infrastructure.
How did you decide that ecommerce would benefit the most by outsourcing the infrastructure?
I'm definitely interested in using this to see if I can host a shop since I most certainly end up creating a lot of it from scratch. From a developer point of view, it looks like an SDK/API for building ecommerce websites.
How would you differentiate yourself from shopify like solutions? Are you targeting the developer market vs non-technical users?
Correct. As a developer you know the amount of time you can put into building your own solution to a problem. That approach is fun and a great way to learn, but at some point the benefits can often outweigh the actual costs.
We all spent years building eCommerce websites on a range of platforms and grew more disenfranchised with them over time, we knew there had to be a better way.
We started to discuss the concept of building JS only stores. We loved what Stripe were doing for payments and wanted to bring it to the rest of eCommerce, so we ended up settling on our API approach.
Exactly, We're building for developers, Shopify (typically) supports quick stores for non-technical users, but as developers it greatly limits the flexibility we have.
And: I presume your service requires javascript to function (as all of the similar services do)... any chance of providing a non-javascript fallback such as a generic-looking checkout page hosted on your own servers (like when you use a paypal button to send users to their site to complete the final step of the transaction)? Please don't tell me that "everyone uses javascript yay" or that I shouldn't be concerned -- I know who my clients and their users are and I know what their accessibility requirements are :) (I always have to say this when I ask eCommerce services this question because usually they dismiss it out of hand and it's very frustrating when you have requirements that sites work even without javascript).
Thanks, and best of luck!