Hacker News Reader

Comment by AJSturrock | Hacker News Reader

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.

View on HN

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?

Reply on news.ycombinator.com