Now obviously we’re biased as to the reasons why you shouldn’t go and build many integrations to payments providers, but working with our customers over the last few years, we can honestly say there is a very good case to buy and not build. After all, you’re probably a SaaS company selling a product which means that your customers don’t need to build their own version of the solution you’re selling; so we believe you’ll get what we’re talking about.
I remember, several years ago now, a digital architect friend said to me, whatever you do, don’t build your own CRM, we did it anyway and looking back it’s one of the professional decisions that we made as a team that I would change. Lesson learned. And now, thankfully, we work in a world with maturing SaaS offerings available off-the-shelf.
I assume if you’re reading this you’re running/working in a SaaS business and your product has payments as a feature. You might be an e-commerce platform, or perhaps your users have invoices within your product that they’d like to get paid online. Each one of your customers wants to use their preferred payments partner and so to win and retain your customer you need to work with their payment provider.
We’ve seen our clients win more and larger customers by being able to work with their preferred payments providers.
The challenge is that the global payments landscape is ever-expanding with local payment methods, disruptive technologies and a highly competitive market to boot. Just look at the rise of GoCardless, making an outdated, clunky payment method work, or BitCoin payment gateways, making accepting the digital currency a viable receivable payment method. And the future, at least, in the UK and EU is exciting with the possibilities that open banking is bringing in terms of transforming payment rails.
So here are the 5 6 reasons why you shouldn’t build payments integrations in-house:
1 – Do you want to build and maintain an in-house team?
The first thing you need to consider is how many payment providers you think you want to work with. I suspect the answer, if it is greater than one, is that you just don’t know, it depends on demand. Well, I can tell you that on average our SaaS clients are seeing at least six payment providers being used by their customers.
You’re going to have to employ at least one full-time developer and customer support person to handle this initial work, maintain and support these integrations. Then you’ll probably want to employ a partnership person to ensure you’ve got agreements in place with payment providers.
Do you want to become payments experts or domain experts? It’s hard to be both.
2 – Every payments API is different!
What! There’s no best practice payments API out-there? That’s correct, every provider has built their own, with their own special nuances, error codes, capabilities, terminology etc. If you’re doing deeper integrations, going through certification with these providers then you’ve got a lot of work on your hands; you’ll be lucky if you can launch one new integration every two months with the team outlined in the first point.
All the market fragmentation has created a bit of a mess, there’s no cookie-cutter way to do it effectively, yes you could try and use some open-source library projects but that creates associated risks and although you’ll cut your development time down it still requires you to understand each payment provider.
We’ve homogenised all the mess into our API and platform, one language, one view, one integration.
3 – You will have to become PCI DSS Level 1 compliant
PCI compliance is a rule set imposed by the card industry, you can check our other blog posts to find out more information about it. What it means is that your system is now in scope to be audited by a third party on a regular basis. And that process is expensive, not only to pay the auditors and certifiers but to make the necessary system and internal process changes to comply. If you want to work with some payment providers they will only do so if you are PCI DSS Level 1.
Moving this dependency outside of your system is a lot simpler. You could do this by simply using payment gateway hosted processes (if they exist). But then every checkout experience is different, not branded correctly and potentially you lose control and end sales.
4 – You’ll have to build more product
Checkout screens, payment forms, merchant onboarding, views of payment data, refunds, recurring contract management, translations – the list goes on. What you really want is a way of pulling the data and populating your system in a simple way with best of breed pre-built components accessible where you need them. Add a few more people to your team and months on to your development roadmap if you do want to go down this road.
5 – Speed to market
Want to work with customers who need local payment providers in a new country? You’ll have to tell them to wait for a few months whilst you build out the capabilities with technologies that you’ve never worked with before. Hmmm… That might make it harder to win these initial customers in this new market. It’s not just speed to the global market either, there are new payment methods, legislation and opportunities within local markets.
6 – Bonus – Monetisation
Payments can present new revenue line possibilities for software vendors, this might go some way to offsetting building a payments function in-house, but it’s going to take a long time see return and negotiating favourable deals will be challenging in the early days.
We provide revenue line possibilities out of the box on some of our plans and down the road with further value add services.
Conclusion
For most SaaS vendors it’s going to come to a simple build vs buy approach, but we know that the build price is unwieldy and challenging to forecast, whilst the opportunity cost of not being able to go to market quickly is huge!
So, yes you will have to do one payments integration (into Shuttle), but why not do it into a trusted partner that helps you grow and protects you from ever-changing payments future…
Please do book some time to talk to us about the opportunities, after all you wouldn’t build your own CRM these days would you?!
