Stripe is Currently Risky for Nonprofits (…but Stripe is working on it…)
March 14, 2021
To start off, we want to clearly state that we’re big fans of Stripe. We use them extensively ourselves and bend over backwards to recommend them to clients. The API is top notch, their tools are super useful, and their fraud detection is unmatched.
All that to say, the following is meant to be constructive criticism, due a situation we recently dealt with and legitimate concern for some nonprofits.
Historically, we’ve often recommended Stripe to smaller nonprofits, due to trust. If you used them, you could be certain that they’d do the right thing as issues came up. The primary struggle has always been stolen credit card validation against donation forms. If any fraud attempts succeeded, as long as it was quickly caught and refunded, there were no issues. For small organizations with little-to-no technical chops, this was a vital concept, especially when compared to other legacy gateways.
Back on Apr 1 2020, Stripe instituted changes to the refund policy. Nonprofits could no longer simply refund fraudulent charges as they happened, as Stripe started keeping the original transaction fees. If you’re flooded with tens or hundreds of thousands of attempts, and many of them pass, this becomes costly.
That change forced organizations onto Stripe Radar — Stripe’s machine learning platform that detects and blocks fraud. To be super clear, Radar is an amazing product that works really, really well. Very rarely does anything slip through. So our recommendation then became “turn on Radar and you’re golden”.
But then in Nov 2020, Stripe instituted another policy change. For clients paying the full 2.9% transaction rates, Radar would continue to be free. However, anyone getting a discounted rate (IE, most 501c3 organizations are on a 2.2% plan), Radar would be $0.05 per hit. This creates a damned if you do, damned if you don’t situation. Nonprofits incur fees if they don’t use Radar (refund fees), but now face massive fees if they do use Radar and are flooded with fraud attempts.
Organizations obviously need to implement best practices: captcha, rate limiting, sanity checks (like expected form submission time), Cloudflare, firewall rules, hooking into IP/ASN blacklists, etc. But again, for small nonprofits with no technical chops, that’s not usually feasible, unless they’re using a 3rd party platform with those concepts baked in already.
Stripe needs to be sustainable and profitable, and we’re not against the fees in and of themselves. However, a situation came up that exposed a massive issue with this setup. Essentially, all risks have been shifted to the nonprofit’s court, offloaded from Stripe itself.
A small nonprofit that typically receives a nominal amount of transactions each month was suddenly flooded with stolen credit card validation. That resulted in so many attempts that they racked up an $8,000+ bill from Radar alone, all in the span of a few days. Not a single one of those transactions actually succeeded (Radar works…), but the bill was purely from the attempts against Radar to begin with. That would have essentially wiped 6 months of their online funding (and emptied their bank account), right in the middle of COVID really hurting their bottom line. To be fair, best practices needed to be implemented. But again, for small organizations, that’s not always feasible.
On their behalf, we immediately reached out to Stripe Support, thinking that this was a simple, no-brainer ask that could be rectified in any number of ways. Support used to be super helpful and no-nonsense. But, the response was a terse “sorry, that’s really unfortunate, but that’s our fee structure and this organization was notified of the policy change in Nov.” That was it.
Yes, they were notified, and yes, they understand the fees, and yes, they’re happy to pay in general. But nonprofits often don’t understand the technical implications, especially when the risks are not explicitly given in non-developer terms. Stripe instead essentially allows this to operate as a runaway train. The sane choice would be a circuit breaker pattern. If they see a nonprofit, who typically processes one single transaction every few days, suddenly get flooded with thousands of failing attempts, temporarily disable their account. Reach out, request changes to their donation form (and recommend 3rd party tools), and re-enable the account once everything is fixed up. The temporary downtime would be far worse than the huge bill.
In a panic, we helped them start a flurry of attempts to reach someone over Twitter, etc, getting nowhere. We eventually threw a hail mary pass by directly emailing one of the executives that has been active on Hacker News. Thankfully, he was able to fully refund everything, make suggestions, and was amazingly helpful and open to further dialogue.
Stripe is now supposedly reworking the Radar billing policies as a direct result of what happened. For that, we’re obviously grateful, and we hope to continue to be a part of the feedback loop. But until that happens…
We’re at a point where we can no longer recommend Stripe as the default choice for simple donation forms, UNLESS you can guarantee that you’ve covered the bases mentioned above. Only if you’re able to prevent as much nefarious attempts as possible up-front, you’re temporarily better off looking at alternatives without the fee structure.