Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Moltin – eCommerce Back End as a Service

moltin.com

Post reply on HN
Print view View original

41–50 of 50 posts

Re: Show HN: Moltin – eCommerce Back End as a Service

#41

Post by michaelmior »

AJSturrock wrote: post #24
ngoel36 wrote: post #23

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 ev…

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

Re: Show HN: Moltin – eCommerce Back End as a Service

#42

Post by chuckouellet »

AJSturrock wrote: post #24
ngoel36 wrote: post #23

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 ev…

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.

Re: Show HN: Moltin – eCommerce Back End as a Service

#43

Post by jordanlev »

bikamonki wrote: post #30
jordanlev wrote: post #19

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 transact…

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

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

Re: Show HN: Moltin – eCommerce Back End as a Service

#44

Post by jordanlev »

AJSturrock wrote: post #24
ngoel36 wrote: post #23

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 ev…

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?

Re: Show HN: Moltin – eCommerce Back End as a Service

#45

Post by jHoldroyd »

jordanlev wrote: post #44
AJSturrock wrote: post #24

Earlier quoted context omitted.

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 ev…

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 t…

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.

Re: Show HN: Moltin – eCommerce Back End as a Service

#46

Post by jHoldroyd »

michaelmior wrote: post #41
AJSturrock wrote: post #24

Earlier quoted context omitted.

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 ev…

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 i…

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.

Re: Show HN: Moltin – eCommerce Back End as a Service

#47

Post by ngoel36 »

AJSturrock wrote: post #24
ngoel36 wrote: post #23

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 ev…

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.

Re: Show HN: Moltin – eCommerce Back End as a Service

#48

Post by jHoldroyd »

chuckouellet wrote: post #42
AJSturrock wrote: post #24

Earlier quoted context omitted.

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 ev…

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?

Re: Show HN: Moltin – eCommerce Back End as a Service

#49

Post by jHoldroyd »

ngoel36 wrote: post #47
AJSturrock wrote: post #24

Earlier quoted context omitted.

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 ev…

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 driv…

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.

Re: Show HN: Moltin – eCommerce Back End as a Service

#50

Post by bikamonki »

jordanlev wrote: post #43
bikamonki wrote: post #30

Earlier quoted context omitted.

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

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

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

Post reply on HN