I implemented Stripe for BCC, too, as an experiment. (I was going to milk a blog post out of it, but all my A/B tests so far have been pushes versus using Paypal, so it wasn't important enough to write before Christmas and I've been swamped since.)
It is every bit as easy as Justin says. BCC's integration was in production in 3 hours, including the wholly-new purchasing flow that my site required to support it. No hitches since then at all.
P.S. I am not unhappy in any way about Paypal, I just experiment with things all the time.
Yep. Technically speaking, I got three null results: not enough evidence to reject the null hypothesis (that A was about equal to B).
Specifically, I tested
1) Paypal + Google Checkout (my previous arrangement) vs. credit card (Stripe) signups alone
2) PP + GC + CC vs. CC
3) PP + GC + CC with in-application upgrade messages pushing insta-gratification CC-based upgrades vs. plain PP + GC + CC with in-application upgrade messages dumping them to the purchasing page like I have done for the last 3 years
n.b. These are my results but they may not be your results. It is entirely possible my credit card form design (which I flagrantly stole from Twitter Bootstrap) is just bad, depressing CC signups, or the UX disimprovement crushed the favored-payment-method improvement, or something else entirely. Test test test.
Are you measuring, for this specific AB test, the number of conversions? Revenue? Profit? (Admittedly they should all trend in the same direction with the exception of profit, which might depend on how well each company's imposed costs work for your situation.)
I didn't understand "a push" at first : It's a blackjack term : "In the case of a tied score, known as 'push' or 'standoff', bets are normally returned without adjustment; however, a blackjack beats any hand which is not a blackjack, even with value 21. Blackjack vs. blackjack is a push."
Stripe is easier to deal with and Stripe is also much faster than PayPal.
Stripe gives way more flexibility in billing.
However in order to use that flexibility I think it's better to dump the whole subscription model and don't even use IPN.
I think all subscription management should be handled in-house.
Yes, main subscription use-cases are handled ok in Stripe plan/subscription model. But there are so many edge cases that dealing with external subscription model is way too hard (too hard in Stripe and even harder in PayPal).
For example, what if customer does not upgrade the plan, but downgrades?
How would proration work in that case?
Or what if Stripe cannot charge credit card for a day or two because it's over the credit limit? When do I cancel premium membership? How do I reinstate premium membership if card started to work? What if user managed to resubscribe again using different credit card, but user's previous subscription started working after that and I got IPN about successful payment?
What if the card is permanently unchargable and how do I differentiate between permanent problems with credit card from temporary problems?
My solution to that is to always initiate payment from my web site (or from my backend service for recurrent payments). Do not delegate charge initiation to Stripe subscription.
> For example, what if customer does not upgrade the plan, but downgrades? How would proration work in that case?
Stripe deals with the prorata and credits the customers account next billing cycle.
> what if Stripe cannot charge credit card for a day or two
Stripe re-trys at time intervals you specify
> What if user managed to resubscribe again using different credit card
Stripe handles the connection because a subscription and card is attached to a customer object. Stripe will intelligently tie all this up and only charge the customer once even if two cards are entered.
> What if the card is permanently unchargable
After a specified number of failed charges stripe will send you a separate webhook at which point you know this is a completely failed card. Simply send the user an email and ask them to re-enter card details. If the card authenticates stripe will tie things together and correctly charge for the subscription.
> Stripe handles the connection because a subscription and card is attached to a customer object.
That all sound good in top-level theory.
In practice that would mean that I have to reattach new credit card to the same customer object in Stripe.
I didn't even research if it's possible, but if it is - that's a different API call. Different than API call for signing up new customer.
Updating credit card on existing customer makes it harder to allow customer to return back to customer's previous credit card ("Use my previously entered Visa credit card ending by 1234").
How about the case when:
- Payment delayed.
- I removed premium membership from user.
- Stripe subscription finally charged old user's credit card, but my system did not receive IPN notification yet.
- User resubscribed again with new credit card.
- Then my system receives old credit card charge IPN notification.
What should my system do in that case?
What if my user decided switch to PayPal and still has Stripe subscription stuck in the limbo?
What do I do when I receive that we-were-able-to-charge-that-stubborn-credit-card IPN if user already paid by other means?
Do you see how these "Stripe-to-my-system subscription synchronization" issues are getting very ugly very quick?
This post is exactly why I use Spreedly (for my subscription product), because writing code for all the edge cases would cost me a metric truckload more than the pittance I pay them every month.
The problem with Spreedly is that I still have to do a lot of stuff on my side.
Spreadly would just give me some hooks, but then I have to handle these hooks myself.
For example, I need to put on hold premium benefits of temporary non-paying users. Spreedly (or Stripe for that matter) cannot do it for me.
I don't know if Spreedly can send notification email to my users (Stripe cannot at that moment), but even if such notification can be sent, there could be issues with email deliverability or with mismatch between my website name and spreedly "from" email field.
User expresses the intent to upgrade or downgrade on my web site.
In order to communicate that intent to Spreedly/Stripe/PayPal I have to make a call that reflects that intent.
If the change is as simple as switch to another plan - then it may make sense. But if it's an edge case (e.g. discount), then I have to use more complex version of API.
If I go through all that complexity anyway - why not just communicate with my own database and drop third-party dependency whenever possible?
Fortunately with Stripe it's quite possible: I just charge credit card whatever the right amount is at whatever the right time is.
That's it. No researching Stripe/Spreedly/PayPal subscription model. No dealing with arbitrary restrictions of these models.
Another problem with Spreedly is that it does not support Google Checkout (most of my existing customers are from Google Checkout - my first payment processor).
So I need to maintain all my Google Checkout customers myself anyway without any Spreedly help.
Bottom line: if you want to polish subscriptions UX for your customers - handling subscriptions in-house is the only viable long-term option. (Keep only subscriptions in-house. Payments processing should be outsourced).
Yes, it takes time. That's the cost of doing subscription business.
Any chance you looked at Saasy or any of the others on the matrix? Tr http://saasy.com/matrix.php Trying to choose a vendor now. I've heard good things about Spreedly also.
Agreed. Pricing is too important to let someone else set all the rules. I'm not saying that Stripe did a bad job with their subscription system, but I think it's a mistake to let someone else make all the decisions when it comes to such a critical aspect of your business.
For example, I personally don't like prorating costs. I want my customers to be able to make changes and play around with the new features before deciding to pay. I also don't like the idea of having a few plans and forcing every single customer into one of them. I want everyone to use the software how they want, and pay based on that usage. These are important business decisions that would be impossible (or at least very difficult) if I used a pre-made subscription system.
Luckily Stripe makes it incredibly easy to roll your own subscription system.
We certainly understand that for some specific billing situations, Stripe's subscriptions API may not be a good fit. That said, we've tried to accommodate as many use cases as possible, and I just wanted to make sure you knew we have a prorate => false flag that you can pass when switching subscriptions. We also have a concept of usage-based charges (invoice items). Your larger point of course still stands (that there are always going to be edge cases and custom billing logic).
I think the best approach for you would be to keep one or two simple subscription cases and suggest your other customers who ask for edge cases to implement their own subscription system.
I wish you gave me that "do it yourself" recommendation - that would save me a lot of time (trying to squeeze what I need into subscription model that Stripe has).
Now that I do subscriptions in-house only - I don't even need to know what Stripe web-hooks are, what are all these possible subscription models and what are their limitations. Just two simple calls: one to create stripe customer and another to charge it when I need.
Has Stripe fixed their webhooks so that they re-POST when the endpoint is down? They can't be compared to IPN until they implement it reliably... without that you have to manually reconcile Stripe's data with your own database to be sure you haven't lost a post during brief downtime, network glitch, transient application or proxy error...
> Setting up a merchant account usually takes weeks and requires hours of paperwork to be filled
That's a bit of an exaggeration... I've worked with 3 different merchant service providers underwritten by 3 different banks, and none of them took more than 2 days to approve an application, and the applications were like two pages long... 10 minutes to fill out. Names and socials of the principals of the business, estimated ticket size and monthly volume, description of your business, signature, date, send.
If you have the volume, that extra percentage point Stripe will shave off your gross sales is a lot to throw away.
They're a neat company with a neat API, but they're firmly in the "backup plan" category for me.
> Has Stripe fixed their webhooks so that they re-POST when the endpoint is down? They can't be compared to IPN until they implement it reliably... without that you have to manually reconcile Stripe's data with your own database to be sure you haven't lost a post during brief downtime, network glitch, transient application or proxy error...
We're working on this right now. It's part of a larger redesign of our webhook system that we started right before the break, and we should be able to launch it pretty soon. Our webhooks are the last somewhat legacy part of our product, so I'm pretty happy that it's getting reworked.
I will also concur that Stripe is very easy to add to a site, test, and turn on billing. I just spent almost 8 hours building a stock photo site for my wife and I to use (http://sleepybird.us/sedonaredrocks - written in Clojure :-) and I don't think that the Stripe part of it took more than 90 minutes total, largely because I found a Clojure library for Stripe and everything just worked.
One of the reasons we formed a US LLC (we're Canadians) when building Appifier was to work with Stripe. They're simply the best way we've found to handle online payments without the headache.
I can confirm that at the moment our experience (other than some foreign ownership headaches that were promptly resolved by their support staff) has been entirely positive. Integration was a breeze and the reporting is top notch.
I'm also based in Canada (Mtl) and I has been waiting for months for their international support.
What were the other reasons (if you wan to share)? I'm interested in the experience of making US companies from Canada and what are the time and money expenses this generates.
One big reason we went US was to avoid Bill 101 and all the language restrictions it entails. It was going to really slow us down. We also like the access to US capital that setting up in the States allows for.
An LLC is an amazing thing that we don't have in Canada. It provides limited liability while freeing you from the governance requirements that a corporation has. As a bootstrapped startup, it really sucks to have to deal with endless paperwork to keep your corporate veil in order.
Carl Mercier posted a really good blog entry from a local Quebec perspective, check it out:
To clarify, you added stripe as a new payment option and you're running both in parallel now right? I didn't think there was a way to get your old PayPal subscribers moved over.
Yes. I made stripe the main payment option and left paypal as a second option. There is no automated way (that I know of) to move customers from paypal to stripe.
We're working on it! We want to make sure we get it right. But I do want to mention https://stripe.com/global for anyone not in the US that wants to be notified when Stripe gets to their country.
Don't many users already have PayPal accounts, though? I'd happily spend twice the development time if it meant users were less likely to leave the checkout page because they already had an account and wouldn't have to type as much.
A little more dev work upfront can improve your conversion rates from then on, basically. Heck, I pay with PayPal instead of direct debit/credit cards when both are offered just because typing the PayPal password is easier than filling out all the card and address info.
AnyFu looks like a GREAT site. I've wanted access to subject area experts in the past for specific issues, but didn't want the delay involved with finding a long-term freelancer on oDesk or eLance. Plus, the quality is often sub-par. Best of luck to you. I signed up, and am excited to hear more.....
"To get going the only new stuff I needed to add was a credit card form .."
One difference between PayPal and Stripe is that PayPal allows you to accept payments without hosting a credit card page. It would be great if Stripe could offer this kind of feature.
One alternative to PayPal, with hosted payment pages and IPN, would be WePay.
Can you create subscriptions with Stripe on the fly? My wife runs a subscription business but pricing is based on the products the person chooses so my subscription rate is always variable. When I first looked at Stripe it seemed like I had to have subscription + prices created beforehand.
They have an API to create new subscriptions on the fly yes. It's very easy. I have a similar situation. I used the API to create about 150 subscription plans that cover all my alternatives.
I guess I should have made it clearer that I converted the site to use stripe as the main payment processor but people can still pay with paypal if they want.
SaaSy.com works with vendors in most any country, supports 10+ global currencies, handles global taxes, order pages are translated into 20 languages, and basic integrations take 12-72 hours for the store to launch.
Why do I have this scummy feeling about Dwolla? Was it something I read? I have this feeling that they're going to evaporate as soon as sites start taking Dwolla payments and there's a reason for them to be targeted by criminals... will 25 cents per transaction really cover the fraud-prevention excellence they need to develop?
Dwolla did some questionable things with chargebacks last year [1,2], and you may have heard about that.
Unfortunately, it was apparently in reaction to scammers. The scam, I think, was to transfer money from your bank to Dwolla, move it from Dwolla to TradeHill, buy Bitcoins, slightly launder the Bitcoins by transferring them to yourself in another account (with Tradehill or Mt Gox), and sell them. You can do that all in a few hours, easily with thousands of dollars.
Then go to your bank and say that the Dwolla transaction was fraudulent. Dwolla gets stiffed by the bank, and has no recourse. So they started hitting TradeHill with chargebacks. I think they did it before their Terms and Conditions said that they could do chargebacks. (In fact, I think I remember reading somewhere that a feature of Dwolla vs. Paypal is that there would be no chargebacks.) Now, I believe their Terms say that they can do chargebacks.
You may also have heard about how some people's Dwolla accounts were vulnerable when they used the same user name and password on Dwolla as they did on Mt Gox. Mt Gox was hacked [3], and it was (supposedly) VERY easy for people to have their bank account cleaned out via Dwolla. Since people link their bank accounts to Dwolla, if a thief gets their Dwolla password, then the thief can simply transfer money from the bank to Dwolla, and then from Dwolla to a Bitcoin exchange (like Mt Gox). Then launder them as above, and you have yourself thousands of dollars.
I should note that it's likely possible for people to get their bank accounts emptied via PayPal as well (hence all the Paypal phishing attempts), but it's more difficult to launder Paypal credits, since you can't easily convert from a Paypal credit balance to cash like you can with Dwolla (thanks to Bitcoin).
But overall, I have a favorable opinion of Dwolla.
The Dwolla story is a great one - young, successful serial entrepreneur takes aim at a market dominated by just a few old school players (and I'd lump PayPal in as old school too) and in a few years is processing tens of millions of dollars.
The team is reinventing transaction processing.
Seems to me like a company that would appeal to the Hacker News community but whenever I bring it up, I get down voted. I don't understand why.
I really think this is the case of their website design not giving a feeling of quality... Their design is OK... but I bet if they could give the site a softer look and have it convey a feeling of assurance/reliability - they'ed have a much better product... I realize design is a small part of the equation, but it goes a long way in gaining trust in the brand... Right now their site gives me the feeling of "stodgy corporate", slightly sketch... they need to fix that... stripe in comparison gives me the feeling of "cool", "reliably", "smart"... i'm just one dude though... who has been regrettably using authorize.net - so take it with a grain of salt...
There's nothing wrong with Authorize.net. Well documented, easy to implement API, automatic billing or charge-by-reference, reliable service, not overpriced... Why would you regret it?
As my service has evolved and newer payment options have emerged braintree, stripe... I'm just probably jealous envious of the coolness of those services... but you're right - authorize.net has not yet failed - good point.
It is every bit as easy as Justin says. BCC's integration was in production in 3 hours, including the wholly-new purchasing flow that my site required to support it. No hitches since then at all.
P.S. I am not unhappy in any way about Paypal, I just experiment with things all the time.