Show HN: Moltin – eCommerce Back End as a Service
moltin.com
moltin.com
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!
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.
Thanks for wishing us luck!
Naturally, for this approach, you need that the BAAS vendor offers a Node SDK (most do), or maybe some other stack (PHP, Rails, etc).
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.
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.)
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?
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?
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.
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.
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.
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.
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.
In the future we’ll be making it even easier to migrate to and from Moltin with tools to import and export data.
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.
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.
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.
If you ever have any problems we’re always available on email or live chat :)
Is there any support for:
- Vouchers
- Promotions
- Categories
- Classifications
?
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
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.
looks like a great product, curious to know what stack you are running, are each backend hosted on amazon?
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.
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?
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.