Software developers have discovered that revenue from payment processing is another source of profits from their software. Often, they pursue a well-known payment processor and proceed to integrate it into their API. Unfortunately, many software developers never learn the inside story of how profits are made and how much money they are leaving on the table. That’s where we can help.
We help software developers get a better deal from processors.
Essentially the software developer is using the services of a special type of payment processor, called a payfac or payments facilitator. The developer is not becoming a registered payfac, which is very expensive and takes a long time to set up. Rather they are using the services of a registered payfac for a fee. Sometimes this is called “Payfac in a box” or “Payfac as a service.”
I’ve been doing lots of comparisons of payfacs’ and third-party processors’ offers to software developers. A payfac or processor provides a rate and fee quote to the developer so the developer can mark up the rate for their end user. The trick has been analyzing and comparing their rate and fee proposals when each one sets their pricing very differently.
Processors quote pricing to software developers in two ways. The first method is commonly used by payfacs, which is expressed as a rate and a fee. For example, a common fee quote is
- Rate: 2.9%
- Fee: 30 cents per transaction
- A percentage of the profits that go to the developer
Another method for quoting pricing to developers is a document which is called Schedule A. Schedule A typically quotes pricing in terms of a pass-through of interchange, dues, and assessments plus fees that go to the processor. The markup for the processor is a combination of
- Rates, expressed in basis points (which is multiplied by dollar volume of processing)
- Cents per transaction (for each transaction that is authorized)
- Non-transaction account fees, such as an account on file fee or PCI fee
- Incident fees, such as chargebacks
As you can see, an analysis of what the processor is billing as the cost of transactions goes off into the thick weeds pretty quickly.
But wait, there’s more! As an added twist, the processors sometimes require that they share in the profits from processing. The amount the developer keeps is commonly called a “Share” or “Residual Share.” It’s usually stated as something like Share = 65% for processing volume under $5 million processing volume. At $5 million processing or above, share =75%. This means that the software developer keeps 65% of the net profit as long as their clients’ processing is under $5 million. Above that, the software developer keeps 75% of the net profit.
So you can see that there is something of a mind-bending complexity to understanding what you’re paying for processing. Then you have to determine how you’re going to bill your customers for processing. There are competitive factors, standard models, and all-in billing models.
One factor that often doesn’t get enough attention is the level of support the developer will get from their processing partner. Some processors have very good integration tools and APIs, but they expect you to figure it out on your own. They figure if you’re big enough to be in the game, you’ll have the resources to get it done on your own. Other processors take more of a hand-holding approach. If this is your first time integrating payments, you might do well to work with a processor who can give you the help you need.
Regardless of what approach you take, you need to get paired up with the processor that’s right for you. There are dozens of choices and a lot is riding on your decision. If you’d like to discuss our process for guiding you to the right choice, let us know.