Show HN: Moltin – eCommerce Back End as a Service

by AJSturrock • 11 years ago

116 49 11 years ago

bsbechtel2• 11 years ago

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?

jHoldroyd17• 11 years ago

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• 11 years ago

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.

bsbechtel2• 11 years ago

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

jHoldroyd17• 11 years ago

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

base• 11 years ago

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?

jHoldroyd17• 11 years ago

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.

kposehn• 11 years ago

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

jHoldroyd17• 11 years ago

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

karambahh• 11 years ago

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.

jHoldroyd17• 11 years ago

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.

thecatspaw• 11 years ago

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• 11 years ago

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

jHoldroyd17• 11 years ago

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.

jtchang• 11 years ago

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

jHoldroyd17• 11 years ago

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

jordanlev4• 11 years ago

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!

thasmin• 11 years ago

The website has PHP and curl examples.

jordanlev4• 11 years ago

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.

AJSturrock3• 11 years ago

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.

Thanks for wishing us luck!

bikamonki3• 11 years ago

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

jHoldroyd17• 11 years ago

We've had a few people doing that, and we'll be forking our JavaScript SDK to natively support Node in the next week or two.

jordanlev4• 11 years ago

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

ngoel362• 11 years ago

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)

AJSturrock3• 11 years ago

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.

michaelmior• 11 years ago

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

chuckouellet• 11 years ago

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.

jordanlev4• 11 years ago

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?

ngoel362• 11 years ago

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.

Svenstaro• 11 years ago

How about a Python SDK? :D

jHoldroyd17• 11 years ago

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

curiously3• 11 years ago

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

bikamonki3• 11 years ago

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

jHoldroyd17• 11 years ago

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

cyri• 11 years ago

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

jHoldroyd17• 11 years ago

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.

curiously3• 11 years ago

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?

outrunthewolf2• 11 years ago

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

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.

curiously3• 11 years ago

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?

Immortalin• 11 years ago

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.

AJSturrock3• 11 years ago

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.

Show HN: Moltin – eCommerce Back End as a Service

Related Stories