I wish stripe was in Canada.
How I Converted My Subscription Site from Paypal to Stripe in 2 Days
31–40 of 62 posts
Re: How I Converted My Subscription Site from Paypal to Stripe in 2 Days
#32"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.
Re: How I Converted My Subscription Site from Paypal to Stripe in 2 Days
#33I 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 hi…
have you seen an conversion differences in your A/B tests?
Re: How I Converted My Subscription Site from Paypal to Stripe in 2 Days
#34I 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 hi…
have you seen an conversion differences in your A/B tests?
That's the push part; implying that the tests have been about equal.
Re: How I Converted My Subscription Site from Paypal to Stripe in 2 Days
#35Stripe 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 case…
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.
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.
Re: How I Converted My Subscription Site from Paypal to Stripe in 2 Days
#36Don'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.
Re: How I Converted My Subscription Site from Paypal to Stripe in 2 Days
#37Stripe 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 case…
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 d…
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).
Re: How I Converted My Subscription Site from Paypal to Stripe in 2 Days
#38Keep an eye on Dwolla.com if you want an alternative payment system without the 2.9% transaction fee.
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.
[1] http://tradehillblog.com/2011/07/26/why-we-are-no-longer-acc...
[2] http://tradehillblog.com/2011/07/25/tradehill-audit-discover...
Re: How I Converted My Subscription Site from Paypal to Stripe in 2 Days
#39Re: How I Converted My Subscription Site from Paypal to Stripe in 2 Days
#40Stripe 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 case…
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.