Search
Close this search box.
Search
Close this search box.
Search
Close this search box.
Search
Close this search box.
 

Payment Aggregation

Can becoming a Payment Aggregator help grow your platform?

A 2024 Guide

Get in touch!

We’re absolute pros at dissecting platform needs and providing aggregation solutions.
 

 

Becoming a Payment Aggregator

A Payment Aggregator or Facilitator [Payfac] can be thought of as being a Master Merchant-facilitating credit, debit card and ACH transactions for sub-clients within their payment ecosystem. The Payment Aggregator can quickly onboard a new merchant (typically a user of the SaaS offering) and they can begin accepting payments almost immediately. The Payment Aggregation model is particularly attractive to SaaS platforms that offer some form of payments acceptance where the ability to onboard a new user in a simple, unobtrusive way becomes a client acquisition tool.

We’re here to listen

Let’s discuss your aggregation needs. Get in touch!

 

Topics

What is Payment Aggregation? Payment Aggregation versus ISO and Payment Processor True Payment Aggregation, Hybrid Aggregation or Payments Partnership: Which is the best fit for your application? Pros and Cons of Payment Aggregation How do you become a Payment Aggregator and another possible solution? Payment Aggregator Providers. What makes for the best Payment Aggregator solution Payment Aggregator Case Study Next steps to become a Payment Aggregator Additional resources on Payment Aggregation

Need a Closer Look?

A more thorough examination of the payment aggregation model can be accessed in our white paper section here Learn More

Payment Aggregation or Payment Facilitation is a fairly recent addition to the payments landscape

PayPal was a pioneer in providing payment acceptance tools for marketplace sellers. Many of these sellers would have found it difficult and confusing to apply and obtain their own merchant account. It is likely many would not have qualified or been approved for a merchant account as many were not traditional businesses but rather an individual buying and selling. PayPal [history here] offered a simple way [in the beginnings it wasn’t so simple] to enroll and start processing payments. The key differentiator is that PayPal offered a payment acceptance option where it was previously not possible. This “master merchant” model initially was prohibited by credit card associations [MasterCard and Visa] and credit card acquirers e.g., Vantiv, Wells Fargo, Elavon etc. PayPal grew rapidly and ultimately there is a lot of money to be made so gradually the attitude toward the aggregation model changed. It was very much the “horse is out of the barn” and the  card associations we forced to look at this new business model. When Square first launched you saw a very similar dynamic: Square acted as the Payment Aggregator and really took frictionless onboarding to a new level-buy your reader at Walgreens, fill out form online and in same day start taking payments. very powerful client acquisition tool and was a huge part of their rapid growth. Vantiv became the first acquirer to actually support and develop tools for managing the complexities of simple onboarding and risk controls as well as payout tools for sub merchants. Vantiv is still considered the leader in the aggregation space. With the significant rise of SaaS platforms offering embedded payments there has also been an increase in the number of acquirers offering a payment aggregation solution as well as technology plays to improve areas where traditionally the legacy acquirer platforms have weaknesses [e.g., chargeback management and funding]. This makes for a very attractive time for SaaS platforms looking to leverage Payment Aggregation to both drive new revenue streams and create a better end user experience.

How is Payment Aggregation different from a traditional merchant account via an ISO or Payment Processor?

Paypal/ Stripe/Square underwrite and provision the merchant accounts themselves and  fund their sub-merchant’s payments. MOST importantly, PP, Stripe and Square assume the risks involved in payment processing including fraud loss, chargebacks and non payment.  There is a tremendous amount of money, work, scrutiny and compliance to becoming a true Payment Aggregator. A traditional merchant account provider will obtain information from the business owner that makes them comfortable enough to assume payment risks. Most businesses we speak with are better fits for Hybrid Payment Aggregation or Hybrid PayFac or a Payment Partnership. One of the biggest advantages that Payment Aggregators have is their ability to set up a new customer almost on the fly as opposed to the merchant account provider that may take days to approve an account. There is then additional time ensuring the payment gateway or application using the payment processing has all the appropriate merchant account credentials provisioned. The PayFac model eliminates these issues as well.

Here are some pros and cons of Payment Aggregation:

The disadvantages to the Payment Facilitator model
  • Potential risk of financial loss
  • Customer support burdens
  • Integration demands
  • Approval process to become a PSP can be somewhat burdensome
  • Compliance with KYC/PCI and potential tax reporting
The advantages to the Payment Facilitator model
  • Speed of boarding process: Being a Payment Facilitator allows you the ability to setup sub-merchants very quickly, removing a choke point to new client acquisition.
  • PayFac Model: Right for you?
  • Customers love that it is so easy to get the account going with no paperwork or documentation burdens. This dramatically improves the client boarding process.
    Payment aggregation as business model

    Payment aggregation as business model

    Buy a Square reader at Walgreens, go online and create your account and within 30 minutes you can be swiping payments. That’s a very attractive acquisition tool.
  • Merchant Control: Sub-merchants are under contract with you, the Master Merchant.
  • Flat fee structure: Easy to understand flat fees for your merchant customers. No needs to understand interchange tables.
  • Earnings: Master merchants are able to earn money from network and transactional fees, and potentially float. This is the big one for most SaaS platforms contemplating going the aggregation route. FinTech has seen massive investment and the main attraction is recurring revenue. As long as people are taking payments revenue + profit is being generated. Think about a regular business selling widgets. Unless those widgets are razor blades the purchase frequency can be months or years. Contrast that with a business taking payments. You can see the allure of the payments business and why SaaS platforms look at payment aggregation.
Revenue is derived simply from the difference in buy rate from the processing networks and the sell rate charged to the end customer. For illustration, if a Payment Facilitator knows their true overall cost amounts to 2.4% of processed volume and they sell at 2.9% their margin is .5% of dollars processed. If they process $10,000,000 per day that works out to $50,000 in revenue per day. Very attractive business model and you might say sign me up.

Not so fast…

There is still the risk exposure that must be examined. Any business that chooses the PSP model will likely face loss from fraud, going out of business, non-fee payment, etc. It is possible an end user signs up for your SaaS offering with the intention of committing payment fraud–it does happen. They are enrolled in your ecosystem and process $10k or even $100k using stolen card data. Who is on the hook for that loss? If you suspect it’s you and your application you would be spot on. Going into payment aggregation without an understanding of your risk exposure is a fast way to lose your shirt. Mitigating risk and using technology to identify potential fraud is massively important. Your aggregation partner should provide automated risk assessment tools that minimize your exposure. These tools will do most but not all of the user vetting. You still need to know your customer and be aware especially when first onboarding of potential fraud. Most payment aggregation platforms offer controls to measure velocity, funding, reserves etc. In addition, small dollar average ticket merchants that do very few transactions per month are typically not profitable. A merchant that does three $40 transactions per month might generate $4 in revenue. If acquisition, boarding and support cost an average of $40 per merchant, the ROI is almost a year to break even. So thought must be given to your target user base: Do we have enough users so that payments volume will generate ROI? As the PSP you will also be front line for payment related support and when money is on the line you know people want service ASAP. There must be thought given to the support burden when pursuing the PSP model. The more you “know” your client base and the potential for dollar loss the more informed your decision will be. Thought should be given to documentation and support systems that allow for as much self service support as possible. So it for you? Definitely a decision your business needs to give a lot of thought to. If fast/easy client boarding is a must the PSP model is very tough to beat. There is of course the risk mitigation that MUST be addressed. There are certainly cases where payment processors have gone down because they did not properly mitigate exposure. Customer service burdens are also a part of your decisioning. Typically you will also have an integration timetable to ensure the account provisioning, application process and KYC [know your customer] obligations are programmatically correct. From our experience the #1 question to ask is: Will payments revenue be a primary profit driver for our business? If yes then becoming a PSP or aggregator is definitely worth looking at. If however, easy client onboarding is primary objective and you make revenue from other areas eg subscription fees, then Hybrid Aggregation is a better fit. In Hybrid Aggregation your costs and ongoing obligations are MUCH reduced. Of course the cost of this is less revenue from payments. You have read this far-that likely means you are thinking about payment aggregation for your application. A quick conversation can save you hours of time searching for the answer you may want to hear. You can also check out “What can go wrong with Payment Aggregation

The numbers

It is also very much a numbers game. Your hard costs should be explored up front. Integration, compliance, support, admin costs should all be looked at. Once you have an idea about costs it’s now about:
  • Number of clients
  • Payment frequency and $ amounts
  • Will aggregation allow you to acquire customers more quickly?
  • Based on payments data from either your usage or similar businesses try and peg where your costs will be
  • Appropriate sell rate
Run the numbers and decide how many clients it will take to break even. You should know both your client acquisition costs and lifetime value. This will provide insight as to whether going down the Payment Aggregation road makes sense.

How do you become a Payment Aggregator?

 
  After you have decided what Aggregation solution is the best fit your next steps vary. Full blown Payment Aggregator 1-Register w/Sponsor Bank. The Sponsor bank/processor [eg Vantiv] underwrites your business for their potential risk [fraud, negligence, reputational].  You and your business will be vetted to ensure all seems on the up and up. Think applying for a large mortgage. 2-Approval by Sponsor. You are officially approved and move on to integration/testing.  You will want to be thinking about compliance [PCI/KYC] options as well as ongoing risk mitigation. 3-Technology platform integration: You make sure data flow, onboarding, funding risk controls are all in place and operating 4-Sponsor bank issues credentials to make systems live. Testing moving real money around to monitor flow and system performance. 5-Go to market. The fun part-you either batch onboard current clients or turn on customer acquisition tap. 6-Refine. You will learn a LOT in first weeks/months. What is working and what needs changing. Start to finish this can take 6+ months and significant $ investment – easily $100k+ If all of that seems too much time, effort and money then you consider Hybrid Payment Aggregation. In this model the path to aggregation is less onerous. You can sign contracts, integrate, test and go to market in as little as 3 weeks. Typically there is a catch and that is you profit margins are reduced. This does not necessarily have to be the case. Much is dependent on the applications a-Potential volume b-perceived risk exposure and c-company’s financial strength. So don’t discount this pathway-it can be a very attractive middle ground. How to become a Payment Aggregator A  Checklist for choosing your Payment Aggregation Partner

Another option?

There is also and alternative to becoming a Payment Aggregator while still being able to offer fast account set up. You may find a Third Party Processor with slick API’s for merchant account onboarding that offers a hybrid blend between traditional re-selling merchant accounts for a TPP and acting as a Payment Facilitator. Advantages are no risk, no support and much lower implementation costs. You still gain revenue benefits without admin burdens. It is unlikely you would be able to provision accounts as quickly as if acting as the PSP, but this may be the best fit for you. Especially if you want to focus on your core product but realize payments can play an important role is business growth [and revenue generation]. In summary payment aggregation isn’t for everyone but that’s not what is important. The question is “Is it right for you”? That’s a question best answered by having a conversation with you guessed it: Agile Payments. Our strength is creating partnerships that help your business be more profitable.

Payment Aggregator Case Study

A property management firm specializing in condo and homeowner association applications needed to process monthly association fees on behalf of their many clients. In this space it is common to have one entity manage many properties. Having those disparate associations apply for a standard merchant account crates significant friction.  So much so that the application process proved to be a barrier to adoption. By implementing the managed Payment Aggregation model they were able to instantly onboard associations and provide reliable payment solutions. All without significant time, money and risk. In their case they went from initial discussions to integration and implementation in a matter of weeks.