At Agile Payments we take, well, an agile approach to solving the needs for your payment integration solution. For payment integrations to software applications we work collaboratively to discover :
When it comes to researching and making a decision for payments integration and how payments will be facilitated to your software user base, there are a number of possibilities to explore. Commonly, there are two mindsets, one that comes from the business side of things and one that comes from the developer side. On the business side, usually, a stakeholder with lesser or no coding involvement at all tends to look more at how a payment integration will affect their user base in the long run, as well as how the integration will enhance their bottom-line. On the developer side, possibly a stakeholder, but with a great deal of hands-on involvement with the application coding, they commonly look towards providing multiple payment integrations – much more of an agnostic approach to payments facilitation. The facilitation possibilities are the same but likely looked at from different viewpoints. Assuming all below have an API that meets the application’s needs, the facilitation possibilities are:
While there can be some subtle differences on a case-to-case basis, a payments partnership is an agreement with a processing organization to share revenue in return for the leverage the merchant organization brings by way of their application-using market base. While there can be other things provided by the processing organization outside of their typical duties like customer support, the processing organization might also participate with marketing support, survey creation, mobile application development assistance or tweaking existing systems to meet the needs of the user base. And then there are things that occasionally arise that can be specific to a single SaaS organization.
It’s a recurring theme that we are constantly confronted with; an SaaS organization will contact us and they have heard from various sources that they should consider becoming a Payment Facilitator. In many cases the organization has already started down the PayFac path and have received proposals. There’s certainly nothing wrong with that. In fact, in some cases going the PayFac route is completely warranted. While there is more than one benefit to becoming a PayFac, generally speaking the main driver for organizations opting to go the PayFac route is frictionless boarding. On the Payments Partnership level, boarding can potentially be streamlined, yet the SaaS organization is removed from becoming an actual payments company as in the PayFac model. Generally speaking, organizations who opt to go the Payments Partnership route are driven more by price sensitivity – the sell price to their user base and/or potential profit to the SaaS organization’s bottom line. And those two drivers don’t have to be exclusive of each other. That’s were leverage can play a big role.
Leverage can be measured a couple of ways; existing transactional volume and application potential. The first, existing volume is easy to measure. Application potential is a bit trickier and might take into account organizational funding, stakeholder history, where the application is at in development and a review of it by the potential processing partner, market awareness of the potential processing partner, market data provided by the SaaS organization – and quite simply, an educated guess. But on to how much leverage does your organization have? That takes some discussion – at high levels. We will tell you this: More than 90% of the stakeholders we talk to undervalue their leverage. In one case, we discussed various processing routes with a very large organization who already had some loose partnership agreements in place. Their user base exceeded 2,000 using businesses of their SaaS application. It was high transaction volume and low risk business. Their initial focus was on PayFac or Payment Aggregation, but once our discussion progressed and all the nuances, requirements and most important goals were assimilated, it quickly became more likely that a payments partnership could be a better choice – and that both their revenue potential could increase while supplying their user base with better processing rates than they were currently enjoying.
Developers love Stripe. Great API and easy to integrate. Aggregation services also greatly reduce the friction to onboarding, and in many cases that’s a significant factor. Costs will be slightly higher than typical merchant accounts, but the reduction in friction is an attractive calling card. On the flip side, what happens if your application grows to a level that requires better rates? Have you tried to transfer card data from an aggregation service to another processor? Good luck. Other factors that should be explored are how would increasing processing volumes be affected, account holds and most importantly, what kind of customer service do the users of your application get when they need answers about payments processed? Taking the agnostic approach alleviates those concerns to a degree because your application users are responsible for obtaining their own account from the aggregation service provider. But is that really the answer to a successful payments partnership and the best solution for you application users? If we think an aggregation service best meets your needs, we’ll be the first one to let you know.
Keep in mind that we’re mainly discussing software applications that were developed for and utilized by a certain market sector on this page. Integrating to a processor who would be providing your application users a merchant account to process means, in this particular facilitation case, that every application user who would be requiring the ability to process payments (within the application) would be required to complete a processing application and be underwritten. On the surface, this appears to have more friction – a barrier to entry for your application. That honestly depends on a number of factors. In many cases, a particular industry lends itself to extremely fast underwriting. SaaS application-specific boarding can be arranged, assuming there’s partnership potential. In some cases, the positives far outweigh any friction that users might incur. Superior support, recurring payments adoption plans plus implementation assistance from the processor, recurring revenue to the application stakeholders, lower processing fees, and support of the application’s business itself.
It happens every day; Stakeholders and researchers contacting us because they want the ability to easily on-board their clients. 95 times out of a hundred it’s not the right fit. For the 5%, it’s perfect. 99 times out of a hundred, the person inquiring has no real idea what’s entailed in becoming an aggregator. What they do know is that they have read, heard or been told that if you are an aggregator [Payment Service Provider] you can have frictionless boarding. That’s certainly true. It’s the compliance, expense, risk mitigation, legal work and staffing concerns that they didn’t know about. If you think you’re one of the 5% that aggregation works for, great! Give us a call and we’ll be glad to get you started. If you’re unsure or not fully aware of what’s involved, a good place to start is right here: Becoming a Payment Service Provider.
We think the best way to think of Hybrid Aggregation is to think managed payment aggregation; in other words, think the above aggregator example, but eliminate the initial expense, underwriting and risk mitigation concerns, compliance and legal expenses by having a specialized payments firm manage those aspects for you. The benefit is frictionless boarding. You can read a bit more here on Hybrid Payment Aggregation.
In this facilitation model we’re referring almost exclusively to ACH Payments (e-checks). Software applications that have using companies with recurring payments needs, almost always can benefit from employing ACH processing. Costs are lower and bank accounts don’t expire or get closed near as often as credit card accounts. However, underwriting can be tricky in some cases. We have been in the ACH business for over 17 years and seen third party processors come and go. The vast majority that are no longer there is because they had poor underwriting procedures and incurred significant losses. That has led to much stricter underwriting across the industry. To make things worse, many ODFI banks have very strict policies that prohibit certain types of transactions, some you wouldn’t think would be considered high risk. Example, many ODFI banks prohibit ACH transactions for any kind of loan payments – even if it’s a small bank or credit union who is applying with the third party processor. In some instances, you may have a great banking relationship, but they lack the ACH processing tools and ACH API. We’re perfectly capable of integrating to almost any bank, allowing you to leverage some awesome ACH technology, but originating through your own ODFI relationship. Whatever your application is or what your needs are, give us a call or contact us and let us assist you in determining the best SaaS Payment Partnership model for arriving at the best possible payment partnership.