Why did we switch from Braintree to Stripe?

We recently switched from Braintree to Stripe. Read on to hear about the ups, the downs and the key takeaways for us and the team. Why did we make the move? Buckle up, it's time to find out.

You already know the outcome of this story from the title, but a few months back we switched Payment Service Provider (PSP) from Braintree to Stripe.

Sounds simple. But damn, it was pretty complicated. Before we go and jump into the specifics, let me give you some broader Deekit-related context.

 

The Deekit founders

 

Our founding team, Kaili, Kristo, Asko and Erki, had a very clear approach from the beginning. At Deekit we shouldn’t build things ourselves if someone is doing it well already. We strive to find options that are ‘out-of-the-box’. Our team is small and we want to be all-in on improving what’s important to us. We don’t want features taking up capital or operational expense that aren’t integral to our product.

Payments as a whole were a common thread for the founding team during their time at Skype. Kaili built the entire Payment Operations team, who made sure payments were always up. Kristo worked on the back-end on quality assurance and security. Asko did a ton of work with PCI and making sure credit card payments were stored correctly and Erki initially did all of the Skype webstore.

It’s fair to say they know their stuff.

Skype was ahead of it’s time in many ways and payment processing was no different, it was all in-house. This meant that we knew from the beginning how resource-sapping payments are…

 

Decision time

 

Deekit were a part of the Techstars London cohort in the Summer of 2015. At this point we already had the whiteboard – but it was free.

 

The team at Techstars Demo Day!

Working out how we were going to charge people for Deekit was at the forefront of the team’s thoughts. Kristo, our CTO, was the guy to do the initial evaluation of service providers,

“I was looking for something new. Something that meant we didn’t have to run our product catalogue in-house. I didn’t want to spend too much time in traditional business talks about payments either. The flow I was looking for was that we sign up for the service, add the development documentation and we would be good to go.”

Resources, like in any startup, are precious at the start! Time is one of those resources and screw spending all of the Deekit team’s on calls with onboarding executives and sales guys (no offense).

 

You’re busy, but why not try our online whiteboards? 🚀

 

Introducing Braintree

 

We knew about Braintree as they were pretty much the first service to come out with an easy-to-get-started SaaS payment product. PayPal had acquired them too, who the founders knew well from their Skype days as they too were a part of EBay. It looked pretty solid to us for a few reasons:

 

  1. We only needed to integrate with one API (Braintree’s).
  2. Credit card and PayPal payments were enabled off the bat.
  3. Their development documentation was solid and comprehensive – a must when integrating a new service provider.
  4. We heard from others in the space that they had great onboarding.

 

The final point is really crucial here.

During Techstars the Braintree guys were super helpful. We talked through that we needed recurring payments. They told us this was totally possible with Braintree. They had comprehensive documentation so the team could implement easily. We ran through with them that we were considering two pricing models:

 

  1. Fixed team sizes and pricing – this was a bit more of an old school model. But the idea was that you paid a certain amount for teams within a range. So teams up to 10 users paid a certain price, between 10 and 50 another and so on.
  2. Dynamic pricing based on users – Slack were doing this at the time where you per user and the price keeps increasing as you add more people to your plan.

 

Risto, one of our engineers, did some digging into the documentation and was working it out. He knew at the time that,

 

“The BT subscription model was a bit different in that they don’t have a ‘seat’ based model. You have to do all of the pricing calculations yourself. This means if you want your pricing to be seat based you have to work out: members x plan price + discount + tax etc in some cases”

 

We had this in mind but we actually thought pricing would be fixed rather than dynamic, so their setup worked for us. We spoke to them about further and they confirmed the setup. It all sounded good to us and we were able to get a pretty solid discount due to our time in Techstars.

We were sold.

Business sense was made and Braintree seemed like a solid option to us. Woo!

 

Implementation

 

The time finally came around in the Summer of 2016 to start planning the integration. All went well and it all seemed pretty straight forward to the engineering team. We had a goal of having payments set up by October.

As with anything, there were a few problems to begin with.

 

  1. we had decided to go with a dynamic pricing model

 

In the time between Techstars and implementation we had changed our intended approach. The fixed price model seemed a little outdated to us and dynamic pricing was the way to go. This was possible in Braintree, but required some work from our end. We couldn’t simply add the quantity together of the team, instead we had to calculate this and renew the price ourselves. We thought this was no biggie, but there was more…

 

  1. pro-rata pricing wasn’t a thing

 

SaaS customers presume you have a pro-rated model in today’s world. If you invite a 2nd user to join your plan in the middle of the month, you expect to pay half of the usual price. Period.

Braintree couldn’t do this which was frustrating for us – and shortly for our customers too. So we had to make this work ourselves. We calculated all of this in-house which meant more tracking, more storing and tons more operational expense, which did not align with our core values. Although tax integration was great with Taxamo, due to the additional calculations on our side we had to re-calculate this too!

 

  1. the discount model was time-based

 

We hadn’t really thought through what we wanted to offer in the future when we initially planned payments. But now it was clear we wanted a discount model. Unfortunately for us, the only one Braintree provided was a time-based one.

Instead of being able to offer money off your bill or a percentage discount, we had to offer a discount of months on overall package. If we wanted this we would have to do the calculations ourselves. You might not think of this as a deal-breaker but it was pretty inflexible for our marketing team. Doh!

 

  1. We didn’t have plan flexibility

 

It’s always been important to Deekit to support people in (or involved in) education and non-profits. Our Education discount was always coming. We wanted the application process to be as automated as possible too. But adding an 85% discount to teams had to be done manually in Braintree it seemed.

To run you through it, the application came in, Kaili reviewed and okay’d it, Kristo had to update this on the database side and only then could the user go into the payment flow. A lot of work huh?

 

Going live (but with annoyances)

 

We had made the decision to go with Braintree and done all of the hard work required to implement it. We felt that all of this should have been automated by a PSP but alas, we were here. At least we had the payments live and users could enjoy what our paid plans had to offer!

But there was another problem…

We decided we wanted to implement a referral program but  Braintree didn’t have an out-of-the-box solution to help us here. We had to work with another service provider to make this happen, an additional overhead we didn’t want.

 

Execute, execute, execute!

 

We also wanted to experiment. Our marketing team were keen to test some different free trial offers, but Braintree is slightly laborious on this front and meant they needed the help of Erki and Risto on the regular. Risto ran us through the reality,

“With Braintree there’s a big limitation in that you have to create a subscription with a payment method. You can still have a free trial but you have to handle the ‘trial days’ calculations yourself”

It became a lot of effort to make small changes and we lost a lot of our flexibility and iteration speed.

 

Considering a change

 

Kristo and Risto sat down and reviewed the situation. Small issues had become bigger ones over time and most of the work we’d done should have been handled by the PSP we thought. It’s horrible admitting defeat but this was necessary at this point. We didn’t have a ton of subscriptions yet as payments had only been live for a few weeks so if we were going to make the switch to another provider now was the time.

Stripe had gathered a lot of momentum in the SaaS space by this point and we knew it was a solid solution. It seemed like the logical alternative. We were considering it for a few reasons:

 

  1. Other SaaS businesses were using it – we never intended to re-invent the wheel with payments. We wanted to adopt what worked. Other SaaS businesses we knew and loved like Slack and HubSpot were using Stripe.
  2. We got feedback from other founders – we reached out to other founders and engineers we knew who were using Stripe and they spoke highly of it. So far so good to us.
  3. Not as much engineering – Unlike Braintree, for our dynamic pricing model Stripe appeared easy to integrate.
  4. Pro-rata pricing – when a new member joined they were charged pro-rata unlike on Braintree.
  5. No credit card on free trial – our marketing team wanted the flexibility to test this and with Stripe they got it.
  6. Better discount functionality – this isn’t perfect as only one discount can be applied per account, but it worked better for us than the Braintree alternative.
  7. Simplified operations – across Deekit things would be much simpler. Less maintenance, more possible features and easier debugging. In Stripe you get the whole “event history” of what changes were made, with inputs and outputs, unlike with Braintree.
  8. We could actually use it – although Deekit is very Estonian, we are actually based in the UK as a business thanks to Techstars. UK businesses can use Stripe, unlike our Estonian counterparts. So we felt pretty lucky. If you’re interested I’d definitely suggest checking if Stripe is available in your country.

 

It’s worth highlighting that this potential change had some downsides though:

 

  1. We’d lose PayPal – Stripe doesn’t have PayPal integration so we’d lose it. Like anyone, we don’t like losing payments options for customers.
  2. We would need time – operational expenses here would accrue and we’d need to allocate some engineering time to making the switch.

 

It’s important to mention too that throughout this process we learnt a lot about what Deekit needed in a payment provider. The business evolved and we started to think about campaigns, referrals and other features we wanted to build. On one hand we should have considered all of this before committing to a provider, but we were so far down the product rabbit-hole that we were fully focused on building the whiteboard itself.

We thought all of this through over the Christmas period of 2016, a time when we always take a couple of weeks off to decompress. When we came back, we knew the change was necessary.

It was time to move to Stripe.

 

The Switch

 

We already had all of the Braintree logic on the back-end so we had to deal with that. All of the customer data had to be moved over to Stripe, which we had to be really careful with. Anyone’s that’s worked with payments before will know that regulations are tight. You don’t want to risk moving any of the data yourself and for the most part you don’t really see it anyway as the PSP’s take over. However we still had to be cautious.

 

 

It actually took us a little longer to migrate than expected. We initially planned to be live in less than two weeks, but it took us around four and we were fully switched over by the end of January 2017. The extra time was needed for the migration of existing users mostly. We wanted to make sure there were literally no service interruptions.

When we got stuck into Stripe in February we started to realize how easy it was to work with. Not just for our engineers, but for everyone across the business. Everything was on their platform. Our marketing team were more than capable of setting up a plan or new discount themselves as there was nothing happening on the back-end of Deekit now.

We still had to deal with tax externally which is a little annoying. But alas, the pro’s for us definitely outweighed the cons.

Maybe the differences between Braintree and Stripe are due to their starting points. Braintree was born due to eCommerce demands while Stripe was created for SaaS. Although Braintree were doing their best to catch up, they just didn’t have the same roots as Stripe. The roots that we needed in our payment provider.

 

What would we have done differently?

 

We have a history of overthinking from the Skype days. Naturally as Skype was a much larger operation it required more thinking through.

This approach is tough to change when you go into full startup mode.

We had thought through so much when it came to the immediate demands of Deekit, but we hadn’t thought it through in a future business sense. We hadn’t really asked what Deekit would be in a couple of years time and how our payment provider should meet those needs.

For this reason a lot of the problems that we found with Braintree were definitely our own doing, and not a reflection on Braintree as a service.

We should done a much better review of documentation beforehand, with our expected business logic in mind. We should have understood the trade-offs and also nailed our demands. We didn’t do this that well.

For us, small mistakes at the beginning grew into a culmination of issues later on. On their own they were easy to get over but when we put the time spent on all of them together they were a big problem. We should have been able to avoid this, but hindsight is a beautiful thing.

 

In conclusion

 

Risto’s biggest takeaway from the whole thing:

 

“Before integrating any payment flow make sure you understand the whole flow and the different payment states trialing -> active -> unpaid -> cancelled. For Braintree there is a flow chart. For Stripe there is one too. Both payment providers have REST API’s so make sure to play through the payment flows before starting actual coding.”

 

Kristo summed it up perfectly from a business perspective,

 

“We really wish we didn’t have to switch providers but we’re glad we did. It’s going to help us so much going forward. It ill mean less hassles, less overheads, lower technical expenses and increased time for the team to spend making Deekit the best real-time whiteboard on the market – which is our main goal”.

 

Braintree is definitely a very sound payment provider for startups. We found them to be helpful throughout and they offer amazing perks for growing companies with Blueprint. Kristo actually asked them if there were any strings attached with signing up to Blueprint. They said we could leave at any time and they came through on that promise. We were more than impressed by this.

Also on overall reflection, it’s worth noting that Stripe isn’t perfect. They haven’t gone truly global yet so if you’re not in a country they work in, you will have to resort to other providers. We hope they address this so other businesses can get the benefits we’ve found.

Both Stripe and Braintree are capable of helping your business. For us, Stripe made sense but for others we’re sure Braintree will provide the goods.

Just make sure you do your research.

Ready to see our collaborative online whiteboards? 😍