
Show HN: Moltin – eCommerce Back End as a Service - AJSturrock
https://moltin.com/
======
jordanlev
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).

Thanks, and best of luck!

~~~
bikamonki
Have you tried a proxy approach with node.js? I have done this twice already
when using baas solutions.

~~~
jordanlev
I've never thought of this... do you have more details on how exactly you
accomplish this?

~~~
bikamonki
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).

------
ngoel36
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)

~~~
AJSturrock
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.

~~~
jordanlev
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?

~~~
jHoldroyd
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.

------
karambahh
Nice!

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.

~~~
jHoldroyd
In short, Yes! But perhaps not soon.

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.

------
bsbechtel
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?

~~~
jHoldroyd
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.

~~~
Spone
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.

~~~
jHoldroyd
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.

------
kposehn
Question - are you planning on making a ruby gem for it?

~~~
jHoldroyd
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](https://moltin.com/getting-started#vote)

------
cyri
How do you compare to:
[http://www.commercetools.com/en/pricing/](http://www.commercetools.com/en/pricing/)
(I'm not affiliated with them.) They are expensive ... but why should I choose
you?

~~~
jHoldroyd
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.

------
Immortalin
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.

~~~
AJSturrock
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.

------
base
If someone is going to integrate with your API in PHP as an example, why not
use a full open source shopping cart where they have more control?

~~~
jHoldroyd
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.

------
bikamonki
Do you support non-US businesses? Payments in particular. For example: send
all collected payments to a Paypal account.

~~~
jHoldroyd
Yes we do, we support over 50 payment gateways with more on the way. You can
see the complete list here -
[https://moltin.com/faq#gateways](https://moltin.com/faq#gateways)

------
jtchang
How do you handle the case of a product that you get to select different
options? I don't see it in the API.

~~~
jHoldroyd
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 :)

------
thecatspaw
This looks nice, but very limited.

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

------
krmmalik
Is this for inventory based sites inky or would it work for digital products
too?

~~~
jHoldroyd
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.

------
bsbechtel
Also, your close button on the signup popup doesn't seem to work on Firefox.

~~~
jHoldroyd
Sorry about that, I'll take a look at the issue now.

------
Svenstaro
How about a Python SDK? :D

~~~
jHoldroyd
Again, on the list - but if someone were to do one we'd be happy promote it ;)

~~~
curiously
I'd definitely be interested in this as a Flask user.

------
curiously
so why should a developer use this vs building their own? if open source back
end tools exist why not self host those?

looks like a great product, curious to know what stack you are running, are
each backend hosted on amazon?

~~~
outrunthewolf
Hey, another co-founder here.

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](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.

~~~
curiously
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?

~~~
outrunthewolf
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.

