I became involved with a SaaS startup last August. Stripe was the natural choice of payment processor. It’s been a learning experience. Rather than mindlessly recount the myriad benefits of using Stripe, I want to provide some of my personal experiences with more nuanced cases that may help others better utilize Stripe for their businesses.
Selectivity of Payments
Our business has a high churn rate and, generally speaking, what you would probably classify as low payment integrity. We have a relatively high percentage of failed payments after the first month. In any subscription-based business, this can be a huge problem. Early on, we were able to identify that our rate of failed payments coming from pre-paid cards was extreme (more than 40% of second-month charges failed presumably due to insufficient funds). Our team had little experience with prepaid cards, and we were perplexed by the frequency in which they were used. The conclusion that we reached was that there is a portion of the population that uses cards such as pre-paid Visas for online purchases in lieu of having access to checking accounts.
Unfortunately, these customers were a pain to deal with. Many payments after the first month’s would fail and there was also a high rate of payment disputes. In order to mitigate this issue, we simply disallowed pre-paid cards. This requires a custom-coded solution rather than Stripe’s copy-and-paste code, however, we found it to be totally worth it. Stripe will return the card type after creating a customer object but before allowing payment. At that stage, we throw an error to the user. Our team receives an email immediately and, if the user does not convert (meaning they don’t have another payment method), we’ll often follow-up. We do miss out on roughly two new would-be customers per week, but we’re comfortable with this tradeoff.
Fixing Payment Failures
Into our second and third months of business, we noticed that a high number of our recurring subscriptions were failing to post payment. As we investigated, we did notice a number of insufficient fund errors, but there was more often a generic error code. We spoke with some of our customers (luckily, some early users were people we knew personally) and they confirmed that they hadn’t called their banks or canceled their cards or anything. What the issue ended up being was that we weren’t asking users for enough info at signup. We were collecting the bare minimum–name and credit card info–which is sufficient for single payments but is often caught by bank’s fraud detection systems when charged as a recurring subscription. Changing our Stripe payment modal to collect address and zip code immediately fixed this issue.
Even when you’re doing everything right, payment disputes are a normal part of doing business. In addition to immediately reversing the payment, Stripe also charges the merchant a $15 fine. Stripe tending to side with the customers is nothing new, eBay/PayPal are also notorious for this. As a small business just starting out, it’s hard not to feel bullied or wronged. Granted, when running a SaaS business with little human effort required, it doesn’t feel as painful but losing hard-earned money always hurts.
We win over 60% of our payment disputes and this number is steadily increasing. At first, however, mainly because we had no idea what we were doing, we lost an embarrassing amount. Stripe provides guidelines on how to prevent chargebacks. As we’ve become adept at dealing with customers, we’ve found that offering refunds even when a customer is clearly wrong is sometimes appropriate. An unfortunate reality is that certain disgruntled customers will always dispute payment due to buyer’s remorse, and so it’s really important to provide clear terms and conditions. This is a bit anecdotal, but we also suspect that as our number of successful payments and happy customers has grown, Stripe has become more likely to side with us. Another useful strategy is that customers will often contact customer support when feeling buyer’s remorse but then will validate their account information, making a fraud charge preposterous.
CRM and Affiliate Programs
Stripe has a brilliant API. It made rolling out our affiliate program seamless. There are two features that don’t get much attention but that have allowed us a great deal of flexibility. First, the ability to create and track coupon code usage is so easy. Maybe I’m behind the times, as there have always been coupons when shopping online, but the backend is gorgeous and we’ve never mistakenly withheld payment to any of our affiliates. It is worth noting that coupon codes can’t be applied selectively. So, if you have a code for 20% off, it will automatically be valid for all of the plans you offer and there is no way to alter this behavior. Of course, this can be mitigated in the backend code, but I don’t see much of a reason why it can’t be set up by non-technical users.
Another feature that I use and tend to abuse is the ability to set metadata for customers and subscriptions. We mostly use it as a failsafe way to link account information in the event of database failure. This flexibility can be abused if not used carefully, but we’ve been able to use it pragmatically to boost the robustness of our systems.
I have found Stripe to be worth the high fees. It is a comprehensive platform that strikes a balance of being easy to use for non-technical users, customers, and engineers. I look forward to sharing more experiences as time goes on.