Switching from Authorize.net to Stripe

When DNSimple first launched, we selected Authorize.net as our payment processor. I used them on previous projects and was able to get set up with them quickly, especially since we were developing directly to Chargify, a recurring payment service. Over the next 4 years, Authorize.net served us well, however ever since Stripe came to be we looked at it longingly, knowing that transitioning from one payment provider to another would likely be a challenge. This year we did some analysis of the fees we were charged with Authorize.net and our merchant bank, and compared it with the fees we would pay with Stripe, and discovered that we could save a significant amount of money, to the tune of several thousand dollars each month, by switching. Additionally we'd get the added benefit of Stripe's amazing interface and excellent customer support.

Initial Research

Making the decision to switch was not easy. There is little documentation available about how to move from Authorize.net to Stripe, and most of it is outdated, so the decision had to be made without a complete understanding of what could go wrong. I knew that Authorize.net would need to export our customer payment profiles (which they call CIM data) and that I'd need to provide that information to Stripe, who would need to import it.

Initially the documentation I found indicated that Authorize.net would send this information in physical media, but it turned out that they now have a process for delivering it electronically. They also require that one of the corporate officers signs a document indicating that they are responsible for the payment data from the point that they receive the export and that Authorize.net is not responsible for any data breaches at that point. The good news is that I was able to sign this document and attach it directly to the Authorize.net support ticket as opposed to having to go through crazy hopes with mail or faxing the document.

Setting Up

In the week leading up the export, I worked with both Chargify and Stripe to understand the potential problems that could occur during the transition and what options were available to make the experience as seemless as possible for our customers. I definitely did not want to get in a situation where all of our customers would have to re-enter their payment data.

One of the frustrations during the process was that Authorize.net schedules all of their exports on Friday, but does not guarantee that they will actually deliver on the Friday. They state that they may send you the data the following Monday. This means that any transition must take into account a minimum 4-day window where cards that were in Authorize.net will not exist in Stripe, and thus cannot be charged. Based on the advice from Chargify, we pushed all subscription renewals that were scheduled from Friday to the following Tuesday back until Wednesday. We also disabled any plan changes that would have caused a prorata charge, since these would also fail.

Another decision we made was to allow non-recurring charges to be submitted to Chargify knowing they would fail. Our system has the concept of invoices that can be marked as failed and retried later. We let those invoices fail and customers could either a.) enter new payment details, which would end up in Stripe, causing the next invoice retry to succeed, or b.) wait for us to retry the charge later. We ran into one snag because we usually do not let you make a new charge if you have an outstanding invoice, but we quickly suspended this rule for the duration of the transition.

The Switch

On Friday morning, Chargify switched our processor configuration from Authorize.net to Stripe, causing all new payment details to appear in Stripe. The combination of immediately placing new customers in Stripe along with delaying old subscription renewals worked out quite well. New customers never saw any issues and neither did most existing customers.

Friday came and went without any news from Authorize.net. The fact that they did not update the support ticket for the export indicating that we'd need to wait until Monday was quite frustrating. I even posted to the ticket to get an update at the end of the day Friday, but received no response. When the success your customer's business is on the line then it is important to communicate with them regularly and clearly. With Authorize.net I always felt that they would provide as little information as possible.

I contacted their customer support on Saturday through their chat and was told that the ticket was scheduled for review on Monday. It's too bad this information isn't on the ticket, because that would have made it easy for me to follow along. I also had to coax out the timezone of the office executing the export, which turned out to be in the US Pacific timezone. The customer support representative indicated the ticket would be reviewed on Monday by noon, Pacific time, and that if I did not receive a response then I should contact them again.

Monday rolled around and I finally received the export package at 12:45 PM Pacific time. They sent two separate emails, one with the link to a service where I could download the files after creating a new account, and one with a code used to open the zip file containing customer payment data. I would have preferred it if they had used GPG to encrypt the email with the code, but that was not an option. Once I had the data I sent it along to Stripe, who began processing the data. Stripe had the data imported first thing Tuesday morning and was in direct contact with Chargify, sending along data to map the old CIM identifiers to the new Stripe identifiers.

The Importance of Communication

Establishing communication between Chargify and Stripe was the best decision during this process, because they were able to communicate without me getting in the way. I am very thankful for the hard work of both Michael from Chargify and Eeke and Andrew from Stripe. They maintained open lines of communication and worked efficiently to make sure that the data was imported and relinked in time for the subscription retries that started again on Wednesday.

One interesting gotcha that we ran into was that Authorize.net contained some bad postal code data in their exports. Simone lives in Rome and his postal code begins with 00. The Authorize.net data only sent the last 3 digits of his postal code, omitting the leading zeros. Pro-tip: store postal codes as strings, never as numbers. Another hiccup was that Authorize.net omitted 23 payment profiles from their export. We think these may have been entered into the system sometime between when they started the export and we switched payment providers, but it's hard to be sure.

In conclusion, moving was a challenge, but it is possible. If you're considering switching from Authorize.net to Stripe, hopefully this post will help you in the decision-making process.

Share on Twitter and Facebook

Anthony Eden

I break things so Simone continues to have plenty to do. I occasionally have useful ideas, like building a domain and DNS provider that doesn't suck.