- Your 2% on top of Stripe's fees is off the charts IMO. Stripe charges $.30 + 2.9% and they're taking care of the actual payment. You're merely making it simpler to insert a button.
- The difficulty in practice isn't creating a button to make the payment; it is what happens before and after the payment. Offer to host and automate the delivery of the access-restricted deliverable when it's digital (ebook, software, etc.). Work with Zapier and similar to offer integrations on their end. Provide your users with a way to run their own affiliate program. (Charge extra for that.)
But really what it's doing is stopping you having to build / host the back end server and code that handles the tokenised payment exchange for Stripe (Stripe - and all other similar payment processors require there to be some non-front end code to handle secure token exchange)
So I'm hoping that 2% works out better than managing a server and potentially hiring a developer to build you some code if you can't write it yourself :)
I'm still feeling out prices... 2% was the starting point because it's in line with services that sort-of compete (Celery, SnipCart and so on)
Totally take your points about digital asset delivery - it's on the backlog.
Having done this a few times, integrating a payment processor you're unfamiliar with to a site takes a few hours when they don't provide a library and you're doing it for the first time. I might have misunderstood what you're offering, but to me it sounded like you were basically providing that as a hosted service.
Stripe's API is reputably simple, and Stripe provides ready-made libraries to make your job even simpler. I can't imagine for a moment that using the ready-made library Stripe provides on Github takes more than an hour or two. So you're basically talking about a $10-50 job depending on how generous you feel when hiring an online code monkey or an adolescent down the street to do it for you.
Free + 2% might work for some non-technical user who wants to experiment with selling a product right now without investing a penny. It won't the moment the idea takes off. You'll immediately look for something with a monthly recurring fee.
The reason breaks down to psychology. When you sell a lot of stuff online, you only see the monthly recurring charge once. The transaction fees, by contrast, will be all over your statement. Sooner rather than later, you look at each and every single one, thinking: "Sigh, so much money being spent on this... Why am I paying for this again? Can't I use something else?"
As an anecdote to illustrate the point further: where I live, banks charge a tax on transactions, and what essentially amounts to a tax on paying that tax to boot. It's tiny - under .1%. But cash transactions are, as you'd expect, commonplace - including for things like buying houses.
At any rate, what I'm trying to get at here is that unless you're delivering something on top that is valuable enough to retain your users, you'll only be attracting users who are looking for a temporary solution to experiment with an idea. I'd expect them to churn the moment they see enough transactions that your extra fee associated with each one will prompt survey cheaper alternatives.
One such value, by the way, is having most if not all of the things you want to use in one place, or good APIs and integrations to be able to use the 3rd party tools you want. This matters a lot too in practice.
Maintaining and integrating several different poorly written self-hosted apps to run the cart, billing, delivery, affiliates, accounting, a few types of analytics, etc. is grueling. Integrating multiple hosted tools to do the same is also grueling - but less so, and it doesn't involve much maintenance. Being able to use new apps and services Zapier-or Segment-style is, by contrast, not grueling and extremely valuable.
I'm iterating rapidly on the idea - and in particular I'm happy to talk to customers about pricing plans that aren't currently listed on the landing page (if that means fixed fee and no transaction cost then that's doable)
tbh I'm not sure that Stripe appeals to the most cost-conscious entrepreneurs, and right now I am targeting those who want to test ideas rapidly, and who are likely to then find time / money to build out their own integration (which will mean I have a high degree of churn if I don't adapt.
That's fine, it's all learning!
Again - thanks for all the time you've spent replying. Good luck with your project(s) too :)
I can see the value for non-tech-savvy users. Simple (to understand) product, clear description and instructions.
For non-price sensitive products (i.e. the type of products you'd expect to be developed and sold on line by small / indie producers), the 5% cost of payment (Stripe + Trolley) can be factored in the price without too much pain.
My main question is how many potential customers are there, who aren't already selling through a complete platform such as Etsy.
Hi laurentl
That is an excellent question - in fact it's exactly the one I'm trying to answer with this MVP of Trolley :)
Right now I've "launched" on HN and IndieHackers only, and I'm focussing on software, lean-startup folks to gather feedback.
Next up will be questions around digital downloads ("information products" and other things), so I'll need to engage more with those communities. I don't believe they're well served by Etsy, though they do have alternatives.
Right now it's all about learning where our product and markets best align - and the feedback I'm getting here today is enormously valuable. Thanks!
Hi galaxyLogic
Right now we don't have download purchases, but for this use case (for a small startup or a bootstrapped company) I'd do it by taking payment and then emailing someone a license key.
For low volumes it's totally achievable.
Drop me a line on rg@trolley.link if you'd like to talk further, I'm interested to see what your project is, and how I can help.
I haven't put much active thought into the licensing of the Trolley widget JavaScript code... I'm keen to understand what you're looking for, and why the tag being Free Software is important in this case.
Happy to chat - maybe drop me a line at rg@trolley.link ?
Absolutely. PayPal's user experience is usually (though not exclusively) offsite though.
Trolley gives you a Stripe Checkout-powered on-site checkout.
Right now, Trolley seems to appeal to people who want to do business with Stripe instead of PayPal.
In the future we may well add PayPal as a payment backend in between rolling out our added value like digital downloads, subscriptions and the other cool stuff we're planning :)
Just my feedback: The 2% transaction fee on top of Stripe is a big turnoff for me.
My main use would be selling digital files via Stripe (ebooks, etc). Other services like getdpd.com offer that as a cut-and-paste button for static sites at a fixed monthly price plus they handle hosting and delivering the files to the customer for that same fee.
I'm not saying you need to try to target the same niche, I'm just offering one potential customer's feedback :-)
I'm definitely happy to talk to potential customers about alternate pricing models....
Basically the fee is a % field in the DB, if I wanted to reduce it, or zero it and work through invoicing or direct payments for individual customers, that's cool)l with me.
If it's of interest, drop me a line on rg@trolley.link and we can work out a model that's better for your use case.
Just a suggestion, place a demo pay button on the homepage so visitor can know what it looks like without registering an account. Might probably gain more interest and conversion rate.
Also, what options are available on the backend? Will the buyer be asked for a billing address? Can I turn this off? Can they be asked for a shipping address? What happens when someone buys something? Do they get an email? Do I get an email?
I'd consider answering these questions either as documentation that goes through all of the options available on the backend and/or as a walkthrough of the complete process from signing up to getting an order. A demo Trolley account that's set up with a Stripe test key wouldn't be a bad idea either.
You're quite right. We're working on a demo setup :)
FYI though - yes, you can choose whether to collect billing & shipping info at a per-product level.
The buyer and seller both get notified by email (and if you have the Stripe app as a seller, you'll get a push notif).
The charge gets fully logged in the seller's Stripe account, with all metadata (so if you ever disconnect Trolley you don't lose anything about your customers)
Sorry to hijack, but I've long had this idea, and possibly offer it to people here for stealing, but mainly want feedback on whether it'd be worth implementing:
You, the creator, make some content available for download. You only require the visitor to give you an email address, optionally requiring validation. The visitor then downloads and consumes the content. After some amount of time, configurable by you, the visitor gets an email saying "hey, if you enjoyed my content, please click here to pay me the recommended $X, or ignore this email to be notified later, or click 'no thanks' to never be notified again". Basically, paying after the content was consumed, but not so much later that they've forgotten about it.
I think it's a nice idea that would lead to very little revenue for the creator. You're making it easier to get the content free than to pay for it - is that the intention?
Trolley actually uses Checkout in the UI, so we don't compete directly.
What Trolley gives you is - you don't need a server!
If you use Checkout yourself, adding the widget to your front end is really easy - but you also need to provide some code in the backend that processes your form submission and then does the token exchange with Stripe to actually make the charge on the customer's account.
That means you either need to be on some kind of all-in-one e-commerce suite, use WordPress and some plugins (and either host it yourself or pay someone to) or build and run some infrastructure of your own (heroku, DO, EC2, maybe FaaS if that's your thing)
Think of Trolley as a Stripe backend-as-a-service with a useful UI feature :-)
Checkout is great - but it'not enough to sell online on its own (I think my comment above that explains this posted just after yours, so you may not have seen it :-)
Trolley requires and uses Stripe Checkout, but it's there to make it easier and faster to sell - especially if you want a static HTML site - than checkout alone.
My $.02: I am surprised people are so aversed against the idea of browser based micropayment. I think that's the one component missing from the internet; which could also save us from Amazon and ads. And make content creators richer. (No, Paypal does not count; for obvious reasons and too many clicks … 2?4?)
1. Would this be able to support subscription/recurring payments? E.g. for SaaS.
2. Do you have a versioned release of the JavaScript file so that Subresource Integrity (SRI) can be used?
3. Could you document the origins that the JavaScript file loads content of different types from, so that it would be easy to lock this down using a Content Security Policy?
This is a neat idea. I work with 250 caving clubs that each have individual websites (generally wordpress) and need a way to collect annual membership dues and one time donations.
Most of these clubs have been around for decades, are not growing fast, but have a small very engaged membership. The only time these clubs work with developers is if a member happens to be one and volunteers the time. This really sucks for the member who happens to be the developer. (I stop telling people I can build stuff.)
Most clubs are collecting cash or check in person and at best are using Paypal which sucks because of the off-site experience. I would never set a club up with Stripe because I know if I leave no one will be able to maintain the code, but I would try this out.
The structure of the JavaScript is interesting. It looks like this:
if(typeof Math.imul == "undefined" || (Math.imul(0xffffffff,5) == 0)) {
Math.imul = function (a, b) {
var ah = (a >>> 16) & 0xffff;
var al = a & 0xffff;
var bh = (b >>> 16) & 0xffff;
var bl = b & 0xffff;
// the shift by 0 fixes the sign on the high part
// the final |0 converts the unsigned value into a signed value
return ((al * bl) + (((ah * bl + al * bh) << 16) >>> 0)|0);
}
}
[240k of minimized JavaScript
generated by ClojureScript]
The non-minimized code is just a copy/paste of the imul polyfill [1] from MDN. I'm curious why that is needed, since the ClojureScript seems to already have an imul polyfill included (the function named Ed in the minimized code). Is ClojureScript's polyfill broken?
ClojureScript uses the Google Closure compiler under the hood.
From a quick dig around, looking at the Closure changelog, they introduced a polyfill of their own; I'm guessing this went in after CLJS built one, so now there are 2 in the compile / transpile chain.
One of the consequences of nothing in life being simple any more!
Don't be sarcastic, it doesn't add to the discussion. You're just saying you agree in a silly way and citing some things you also happen to find needlessly complex.
Looks interesting! We've deployed Snipcart on a few static/React sites to keep them self contained which offers a JS powered cart/checkout experience for the same 2% load on the payment fees.
Do you see Trolley evolving to include a cart to allow multiple product purchases?
Definitely, yes. Right now we're focussing on making Trolley as lightweight and easy to get started as possible, before pulling in more features.
I'm really interested in your feedback on how Trolley stacks up against its' competitors; if you had some time to drop me a line on rg@trolley.link I'd love to talk to you in more detail.
Our pricing is also MVP so if you think there's something I'd have to do there to win business from you (or people in your position) then I'm keen to understand that too. I'm already aware of use cases like agencies building sites for their clients that might need an alternate pricing model :-)
Does Trolley also handle calculating sales taxes and integrating Stripe's sales tax on orders features? Or is there a 3rd party involved/recommended when using Trolley?
Could you put a demo up, perhaps? Obviously, most people wouldn't actually go through the whole process and send money, but I'm just intrigued how it "feels".
(Trolley never sees your card details or touches your money; the only pieces of Personal Information we ever see are email addresses and shipping names & addresses.)
What Trolley adds on top of Stripe is that we handle the integration code for you so you don't need a server or to pay for a back end developer, and we make it super easy to put a payment button on any website that triggers the whole process :-)
- Your 2% on top of Stripe's fees is off the charts IMO. Stripe charges $.30 + 2.9% and they're taking care of the actual payment. You're merely making it simpler to insert a button.
- The difficulty in practice isn't creating a button to make the payment; it is what happens before and after the payment. Offer to host and automate the delivery of the access-restricted deliverable when it's digital (ebook, software, etc.). Work with Zapier and similar to offer integrations on their end. Provide your users with a way to run their own affiliate program. (Charge extra for that.)
Inserting a button is part of what Trolley does.
But really what it's doing is stopping you having to build / host the back end server and code that handles the tokenised payment exchange for Stripe (Stripe - and all other similar payment processors require there to be some non-front end code to handle secure token exchange)
So I'm hoping that 2% works out better than managing a server and potentially hiring a developer to build you some code if you can't write it yourself :)
I'm still feeling out prices... 2% was the starting point because it's in line with services that sort-of compete (Celery, SnipCart and so on)
Totally take your points about digital asset delivery - it's on the backlog.
Thanks again!
Stripe's API is reputably simple, and Stripe provides ready-made libraries to make your job even simpler. I can't imagine for a moment that using the ready-made library Stripe provides on Github takes more than an hour or two. So you're basically talking about a $10-50 job depending on how generous you feel when hiring an online code monkey or an adolescent down the street to do it for you.
Free + 2% might work for some non-technical user who wants to experiment with selling a product right now without investing a penny. It won't the moment the idea takes off. You'll immediately look for something with a monthly recurring fee.
The reason breaks down to psychology. When you sell a lot of stuff online, you only see the monthly recurring charge once. The transaction fees, by contrast, will be all over your statement. Sooner rather than later, you look at each and every single one, thinking: "Sigh, so much money being spent on this... Why am I paying for this again? Can't I use something else?"
As an anecdote to illustrate the point further: where I live, banks charge a tax on transactions, and what essentially amounts to a tax on paying that tax to boot. It's tiny - under .1%. But cash transactions are, as you'd expect, commonplace - including for things like buying houses.
At any rate, what I'm trying to get at here is that unless you're delivering something on top that is valuable enough to retain your users, you'll only be attracting users who are looking for a temporary solution to experiment with an idea. I'd expect them to churn the moment they see enough transactions that your extra fee associated with each one will prompt survey cheaper alternatives.
One such value, by the way, is having most if not all of the things you want to use in one place, or good APIs and integrations to be able to use the 3rd party tools you want. This matters a lot too in practice.
Maintaining and integrating several different poorly written self-hosted apps to run the cart, billing, delivery, affiliates, accounting, a few types of analytics, etc. is grueling. Integrating multiple hosted tools to do the same is also grueling - but less so, and it doesn't involve much maintenance. Being able to use new apps and services Zapier-or Segment-style is, by contrast, not grueling and extremely valuable.
Anyway, good luck with your project!
I'm iterating rapidly on the idea - and in particular I'm happy to talk to customers about pricing plans that aren't currently listed on the landing page (if that means fixed fee and no transaction cost then that's doable)
tbh I'm not sure that Stripe appeals to the most cost-conscious entrepreneurs, and right now I am targeting those who want to test ideas rapidly, and who are likely to then find time / money to build out their own integration (which will mean I have a high degree of churn if I don't adapt. That's fine, it's all learning!
Again - thanks for all the time you've spent replying. Good luck with your project(s) too :)
For non-price sensitive products (i.e. the type of products you'd expect to be developed and sold on line by small / indie producers), the 5% cost of payment (Stripe + Trolley) can be factored in the price without too much pain.
My main question is how many potential customers are there, who aren't already selling through a complete platform such as Etsy.
Right now I've "launched" on HN and IndieHackers only, and I'm focussing on software, lean-startup folks to gather feedback.
Next up will be questions around digital downloads ("information products" and other things), so I'll need to engage more with those communities. I don't believe they're well served by Etsy, though they do have alternatives.
Right now it's all about learning where our product and markets best align - and the feedback I'm getting here today is enormously valuable. Thanks!
I use Gumroad exactly for this reason. Hosting / distribution of my files, coupons, affiliates, analytics !
The only thing that bothers me with Gumroad is that the checkout experience is slow. The form can take several seconds to load.
Alt if the app is server-based how does the payment give them a login and password they can use to login to my app online?
Drop me a line on rg@trolley.link if you'd like to talk further, I'm interested to see what your project is, and how I can help.
I'd be fine with that if there wasn't any non-free JavaScript involved. (But there is.)
I haven't put much active thought into the licensing of the Trolley widget JavaScript code... I'm keen to understand what you're looking for, and why the tag being Free Software is important in this case. Happy to chat - maybe drop me a line at rg@trolley.link ?
Right now, Trolley seems to appeal to people who want to do business with Stripe instead of PayPal.
In the future we may well add PayPal as a payment backend in between rolling out our added value like digital downloads, subscriptions and the other cool stuff we're planning :)
My main use would be selling digital files via Stripe (ebooks, etc). Other services like getdpd.com offer that as a cut-and-paste button for static sites at a fixed monthly price plus they handle hosting and delivering the files to the customer for that same fee.
I'm not saying you need to try to target the same niche, I'm just offering one potential customer's feedback :-)
I'm definitely happy to talk to potential customers about alternate pricing models....
Basically the fee is a % field in the DB, if I wanted to reduce it, or zero it and work through invoicing or direct payments for individual customers, that's cool)l with me.
If it's of interest, drop me a line on rg@trolley.link and we can work out a model that's better for your use case.
I'd consider answering these questions either as documentation that goes through all of the options available on the backend and/or as a walkthrough of the complete process from signing up to getting an order. A demo Trolley account that's set up with a Stripe test key wouldn't be a bad idea either.
FYI though - yes, you can choose whether to collect billing & shipping info at a per-product level.
The buyer and seller both get notified by email (and if you have the Stripe app as a seller, you'll get a push notif). The charge gets fully logged in the seller's Stripe account, with all metadata (so if you ever disconnect Trolley you don't lose anything about your customers)
You, the creator, make some content available for download. You only require the visitor to give you an email address, optionally requiring validation. The visitor then downloads and consumes the content. After some amount of time, configurable by you, the visitor gets an email saying "hey, if you enjoyed my content, please click here to pay me the recommended $X, or ignore this email to be notified later, or click 'no thanks' to never be notified again". Basically, paying after the content was consumed, but not so much later that they've forgotten about it.
What does everyone think?
I designed this to be a simple Stripe-backend-as-a-service for people who want to take money fast without having to roll any backend code.
e.g. landing pages that take a deposit for your product (KickStarter style)
Trolley actually uses Checkout in the UI, so we don't compete directly.
What Trolley gives you is - you don't need a server!
If you use Checkout yourself, adding the widget to your front end is really easy - but you also need to provide some code in the backend that processes your form submission and then does the token exchange with Stripe to actually make the charge on the customer's account.
That means you either need to be on some kind of all-in-one e-commerce suite, use WordPress and some plugins (and either host it yourself or pay someone to) or build and run some infrastructure of your own (heroku, DO, EC2, maybe FaaS if that's your thing)
Think of Trolley as a Stripe backend-as-a-service with a useful UI feature :-)
Trolley requires and uses Stripe Checkout, but it's there to make it easier and faster to sell - especially if you want a static HTML site - than checkout alone.
Few questions:
1. Would this be able to support subscription/recurring payments? E.g. for SaaS.
2. Do you have a versioned release of the JavaScript file so that Subresource Integrity (SRI) can be used?
3. Could you document the origins that the JavaScript file loads content of different types from, so that it would be easy to lock this down using a Content Security Policy?
Thanks.
We don't support subscriptions today - but we're actively working on it. Single-item payments is our MVP but subscriptions are next.
Documentation is .... um, "light" at the moment.
Right now, you should be able to use connect-src,img-src,script-src all "https://svr.trolley.link"
We also depend upon Stripe Checkout, so you should add the attributes for their stuff too ( https://stripe.com/docs/security )
Don't have a versioned release right now, which is a gap. Thanks for pointing it out, I'll sort it :-)
Most of these clubs have been around for decades, are not growing fast, but have a small very engaged membership. The only time these clubs work with developers is if a member happens to be one and volunteers the time. This really sucks for the member who happens to be the developer. (I stop telling people I can build stuff.)
Most clubs are collecting cash or check in person and at best are using Paypal which sucks because of the off-site experience. I would never set a club up with Stripe because I know if I leave no one will be able to maintain the code, but I would try this out.
Use flatmarket:
https://github.com/christophercliff/flatmarket
The guy developing it was even nice enough to set up a heroku button; can be run for free: https://github.com/christophercliff/heroku-stripe-checkout
You'll still incur stripe charges, but no extra 2 percent.
[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
From a quick dig around, looking at the Closure changelog, they introduced a polyfill of their own; I'm guessing this went in after CLJS built one, so now there are 2 in the compile / transpile chain.
One of the consequences of nothing in life being simple any more!
Maybe you're doing it wrong. Just make blockchain backend, run it as a serverless process on k8 and voila, can't be simpler.
Thank you oh wise one. I had no clue
https://news.ycombinator.com/newsguidelines.html
Do you see Trolley evolving to include a cart to allow multiple product purchases?
Definitely, yes. Right now we're focussing on making Trolley as lightweight and easy to get started as possible, before pulling in more features.
I'm really interested in your feedback on how Trolley stacks up against its' competitors; if you had some time to drop me a line on rg@trolley.link I'd love to talk to you in more detail.
Our pricing is also MVP so if you think there's something I'd have to do there to win business from you (or people in your position) then I'm keen to understand that too. I'm already aware of use cases like agencies building sites for their clients that might need an alternate pricing model :-)
Thanks!
That means that it works where Stripe works, and the money flows to your bank account through Stripe.
https://stripe.com/gb/payments
(Trolley never sees your card details or touches your money; the only pieces of Personal Information we ever see are email addresses and shipping names & addresses.)
What Trolley adds on top of Stripe is that we handle the integration code for you so you don't need a server or to pay for a back end developer, and we make it super easy to put a payment button on any website that triggers the whole process :-)
We detached this subthread from https://news.ycombinator.com/item?id=18083428 and marked it off-topic.