Stripe recently added a setting called "process payments unsafely" and some new Stripe accounts have that turned off by default.
While this sounds like an ominous setting to turn on, it actually is perfectly safe if you're using OwnerRez, and it's something we require in order to use Stripe as a credit card processor.
- Why Does It Have to be Turned On?
- But Stripe Says It's "Unsafe" and There Are Better Options!
- How To Turn It On
- Why Is Stripe Now Requiring This?
- Will OwnerRez Ever Support Stripe's Tokenization System?
OwnerRez stores and manages credit card information on behalf of its merchants (customers like you!). We do this for a variety of business processes like automatic scheduled payments, automatic scheduled security deposits and more. We also do this so that you can switch processors (eg. away from Stripe to someone else) any time you want without having to run around to all your guests and ask them for new credit card information.
Stripe is incorrectly painting all integrators with a broad brush here. It isn't unsafe if you're using a PCI compliant vendor like OwnerRez. OwnerRez is not only fully PCI compliant, but our systems have undergone a specific design to align with PCI best practices. We are also PCI certified and can supply that documentation at any time. We encrypt and store credit card information exactly the same way that Stripe does and use the same secure protocols that they do when using it.
Stripe recommends tokenization as its preferred integration method, but that locks you into using them as your processor indefinitely. We built OwnerRez to be vendor agnostic and we integrate with more than 20 processors and gateways. We want you to be able to seamlessly change processors at a moment's notice without having to do a lot of hard work.
If you process a live credit card on your account and you get a decline with this message:
"Sending credit card numbers directly to Stripe API is generally unsafe"
This means you need to turn on the "process payments unsafely" settings in Stripe. To do that, login to your Stripe dashboard and click on "Business Settings" on the left sidebar. The Business Settings page will load and you want to click on "Integration" next.
A small dialog box will open and ask you a series of questions. Select each checkbox and then select "Someone else built my Stripe integration" from the drop-down. Enter "OwnerRez.com" as the vendor and then click the Process button. Your answers should resemble the picture below.
After this saves, Stripe will tell you that you need to verify your phone number but you don't have to do that. Click Next and then just close the page unless you'd like to also verify your phone number. Having a verified phone number is a good practice.
It's hard to say why Stripe added this and even harder to explain why they worded it this way (ie. stigmatizing it as "unsafe").
If integrators like OwnerRez have demonstrated PCI compliance and technical competency at integration (which we have), there is nothing "unsafe" about passing credit cards via secure protocols. In fact, Stripe themselves uses the very same secure protocols and PCI regulations that OwnerRez does when they interface with interchange and the cardholders' banks.
To be honest, we believe Stripe is making this new policy for vendor lock-in and not safety. If we used Stripe's proprietary tokenization system, it would be impossible for our users to switch to a different processor. You'd have to contact all of your guests and ask them to enter their credit card numbers again. The way we've built OwnerRez, you are never locked into using one vendor whether they're a credit card processor or marketing channel or anything else. That's why we went through all the work of becoming PCI compliance - so that users could switch credit card processors seamlessly. This move by Stripe appears to be a way to scare users into staying with their tokenization system which, in turn, makes it very difficult to ever switch away from them.
As stated above, Stripe's tokenization does not provide additional security beyond what OwnerRez does because OwnerRez itself has internal tokenization. And beyond that, we are also skeptical of locking our users into staying with Stripe forever (see previous section).
For that reason, we don't have any near term plans to support tokenization.
If all of this information doesn't persuade you and the word "unsafe" is just too jolting to reckon with, we encourage you to drop Stripe as a processor and switch to one of the many others we support. There are a variety of good options.