Exploring payments partnership possibilities for software applications
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 gather as much information as you are willing to provide and try to tailor the right payment facilitation, ideally meeting and exceeding your requirements. In some cases, application stakeholders or those empowered to researching a payment integration aren’t fully aware of not only the types of payment facilitations possible, but haven’t considered what can be a large list of their accompanying issues.
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, they tend 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 looks 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:
- Utilizing a payment aggregation service.
- Standard merchant account.
- Becoming a payment aggregator yourself.
- Hybrid Aggregation.
- Third party processor-to-bank integration.
Utilizing a payment aggregation service
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.
Standard merchant account
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.
Becoming a payment aggregator yourself
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.
The downside – processing costs will be higher than if you were to become a payment aggregator yourself. If you don’t know the costs involved, let us help you examine what might be the best fit for you now, and as you grow. You can read a bit more here on Hybrid Payment Aggregation.
Third party processor-to-bank integration
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 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 facilitation model for arriving at the best possible payment partnership.