It pains me to see all this awesome stuff (CTF, Apps, improvements) from Stripe all the time here on HN only to be reminded that I can't use it and that my only actual option is Paypal or really expensive and cumbersome merchant accounts.
I hope Stripe, Braintree or another 2.0 payment solution will launch here in Norway soon.
Just curious--how or where did you hear about Braintree coming to Australia? And do you know if it's available publicly? It's something I'd love to look at (even with the Westpac account requirement) I can't seem to find anything on it.
Have you taken a look at FastSpring? A nice, flexible system for recurring billing and one-off payments. They act as a reseller too which makes for simple accounting as you only have one direct customer: them.
We've been using them for several years, including for recurring payments on an SaaS kind of system for the last year. I have little interest in Stripe's UK arrival because I can't see anything it would offer for us that FastSpring doesn't already offer. Maybe a slightly lower fee % but that has minimal sway next to a good system that converts well and takes minimal time to configure.
Let me know if I'm missing the point, as to be honest I don't really understand all the Stripe excitement.
Thanks for the tip. The payment provider we're currently using is expensive and their order pages take between three and ten seconds to load. And since Stripe probably won't come to Germany any time soon, this might be an alternative.
I wonder why I've never heard of FastSpring before, even though I head my eyes open for information like this for a long while now.
Groovy. Not sure I'll actually use any of these particular features, but it's good to see they're moving forward.
The one feature I'm still waiting for is prorated refunds on cancellation. As it stands, they'll prorate plan changes, but not cancellations.
I actually had to change my policy on that so that I could switch off my old payment provider and onto Stripe. I can only imagine that it's not Stripe's plan to force policy changes like that onto their customers, so hopefully they have this feature in their pipeline.
These seem like good improvements, although I'm still not really clear on the benefits of using Stripe's recurring billing system rather than building your own. Given that you still have to send out your own emails and handle adjustments to the plans, it seems like basically the same amount of work either way.
I built my own recurring billing system using Stripe about 9 months ago because I need the per-seat pricing. It was incredibly easy, it gave me access to functionality that Stripe will probably never offer, and it allows me to plug in other payment providers if I ever need to.
Anything Stripe builds is going to be orders of magnitude more battle-tested and reliable than anything I could possibly build. This is such a mission critical piece of an application, _I don't want to avoid touching it as much as possible_.
Now it will take a couple lines of code to add another unit to a customer's monthly bill instead of dozens of lines of code and an extra database table. It's not too complicated, but it's enough to make it much likelier that I'd introduce a stupid bug.
For me, that's the benefit.
Context -- I'm a young programmer and don't trust my own code as a matter of course, and I'm working in a bootstrapped-to-the-hilt startup where any ounce of effort saved is gold.
"Context -- I'm a young programmer and don't trust my own code as a matter of course, and I'm working in a bootstrapped-to-the-hilt startup where any ounce of effort saved is gold."
Seeing this on a young developers resume will get you an interview immediately with me.
This sort of concern is a mature trait to exhibit. It's also risky to exhibit when around the unskilled (It's very subtle), which makes it an even more potent indicator.
Thanks spitfire, kind and encouraging words. Most of my understanding of programming as a craft I've picked up here, probably from people who are like you (and maybe you yourself).
I'm an old programmer and I still don't trust the code I write. This attitude is useful as it reminds you that NIH can be a serious disease and that your code should be focused on your core competencies.
I'd wish you luck with your career, but you've already shown you are making your own luck ... Kudos
Thanks smoyer, for the encouragement and also for the new acronym. I wasn't familiar with Not Invented Here syndrome, or at least the characterization of it.
Thanks! I checked out your profile -- Nutrivise is doing great work. Hopefully I won't need a job anytime soon, but if I do I'll definitely talk to you guys.
And I love the resume submittal via a post request. I may have to steal that idea in the future!
The new quantity option for per-seat pricing is a welcome relief. I was soon thinking of setting up N number of plans (1 User, 2 User, etc.) and this eliminates that headache.
It was actually possible to use per-seat pricing with Stripe before this without creating numerous plans. You'd just have to do most of the work in the application layer, adding/removing individual charges to an invoice when seats are added/removed, and calculating the pro-rating charges on your own. I did this for TaskforceApp.com over a year ago.
Would love to give this a go, only today did I experience yet another PayPal mishap that leaves me desperate to try something else (preferably something much better).
I tried Stripe for a while and thought it was great, but AMEX charges kept getting flagged, so I had to go back to authorize.net. How's it going for everybody else?
Stripe should write a gem or a plugin for the most common recurring billing functionalities in a SaaS app.
I imagine that many of their customers need this functionality - and while I know different apps have different needs, there must be some conventions they can adopt and enforce that will make building such a system much easier.
I imagine something like that might even drive adoption of their service - like they need anything to do that.
Chargify user here. Love chargify, hate the merchant account fees I pay each month. For subscription SaaS products, is this now a viable alternative to a merchanct account with a recurring payment service on top?
I use Recurly, which is similar to all these guys and they have a monthly fee. What makes it with paying is: Easier PCI, prebuilt code to process cards against different merchants and more code that handles the whole billing process which I don't have to write.
That is a good point; having some code to look at (or even copy) before writing my first ticketing application could have easily saved me a few hundred hours. Still, $65/mo seems a bit much. Best of luck, though.
Exactly. If you value yourself at $65 p/hour or more, that's a few hundred months of paying Chargify to break even.
I am as optimistic about my software product as anyone, but I need the break even point to be sooner than that if I am going to spend the time coding.
This is also completely discounting the fact that they probably have a more comprehensive system that you wrote, it's all they do. They keep updating it too.
Glad to see progress, but the big gotcha is that even though you can specify quantity of subscriptions, you still can't subscribe them to multiple types of plans. Seems like thats the next step...
I think stripe should make it 1st priority to invest in anti-fraud tools. Right now almost none of the frauds we had were stopped by them but rather by a 3rd party API we use.
Maybe I'm missing something, but what about a flat price + per seat? For example, what if I want to offer a three user plan for $30 and each additional user is $5?
I hope Stripe, Braintree or another 2.0 payment solution will launch here in Norway soon.