Payment processing fees are an open target for business and finance teams to save costs. While it might not seem like there are many avenues to do so, the opportunity is hiding in plain sight. This is specifically true in case of apps that use multiple payment processors. How can paying for multiple processors cut costs?
In the majority of the cases, you would start by setting up the right team having the required capabilities. The team would have 10 - 50 members (depending on volume, markets etc). And they would use 1 or 2 Payment Processors for accepting the payments.
This is a great way to start accepting payments but as your transaction volume grows, your payments stack could collapse on its own weight. With growing volumes and increasing payment diversity, you would need to integrate with Multiple Payment Processors to provide a width of payment options to your customers and reduce your dependency on a single payment processor (to have near 100% uptime). The list of Payment Processors will only increase if your company serves multiple countries. The integrations are not a one-time activity, your team will have to maintain these integrations. As a result, your payment team size, infra cost etc will increase drastically and suddenly you might end up spending a fortune to maintain your payment stack
There are broadly 3 categories of costs when it comes to Payments -
Transaction Processing - These are the typical fees that would be charged by Payment Processors. If you are completely reliant on a single Payment Processor, then you will have very less bargaining power to negotiate on these rates.
Product Development & Maintenance - These costs will go towards the team of PMs, Engineers, Architects, Customer Support and Designers that you will need to integrate and maintain the Payment Stack.
Infrastructure & Compliance - These are the costs that will be charged by your cloud vendor like AWS to compute & store the data points. Additionally you will need to invest in compliance/ legal depending on the country you are operating out of.
Assuming that you are doing 1Mn transactions monthly with an average ticket size of $50, your overall cost for maintaining the payments stack will be ~$1.7Mn (which is ~3.5% of your revenue). Below is the approximate breakdown of your overall payment charges -
What if there was a way to outsource your payments stack without losing control over your operations?
This is exactly what a Payment Orchestrator does. A good Payment Orchestrator, also termed as Aggregator of Aggregators (AoA), works as an extended payments team for the companies and provides them with a reliable payments stack. Through a Payment Orchestrator, merchants can connect with any number of payment processors with a single API integration.
2 ways to set up your payments stack
When you have the luxury of integrating with multiple payment processors, you can reduce the transaction processing costs easily by 20% mainly by -
In addition, you will get a ~2.5 - 4% uplift in Payment conversion that will directly impact your top line. The increase comes from -
As you are no longer managing the integrations of Payment Processors, your Product Development & Maintenance costs will reduce by 80%. Similarly your infrastructure & compliance costs will also reduce by 80% as everything will be managed by the Payment Orchestrator.
Yes, the Payment Orchestrator will charge you a nominal fee that will typically be in the range of ~$100K for the assumed volume of payments.
So, by investing ~$100K, you get an overall cost savings of ~$552K along with additional revenue savings of ~$1Mn giving you a ~1800% return on your Payment Orchestrator Investment.
We are currently converting the spreadsheet into an interactive tool that you can use to make your own calculations. Do share your feedback on the approach used to calculate this RoI from orchestration. We have not yet touched upon the stage at which you should consider integrating a second processor. Here’s an analysis of Stripe’s processing fees and how it varies with your ticket size or transaction volume. For example, if you process a high transaction volume but with a low average ticket size, you might end up paying up to ~20% in processing fees. This is when you might want to seriously consider scaling your stack with an orchestrator.