💸 Becoming a Payment Facilitator - why do it & what does it entail? 💳
What happens when you become a Payment Facilitator (PayFac), what is the contractual framework and how does that impact your business? Let’s get stuck in for our latest deep dive.
Have you ever paid for something on an online checkout and seen those MCD/Visa/Amex/JCB/Diner’s Club logos as you select the ‘pay by card’ option?
Have you ever gone to a market and tapped paid by card on the merchant’s phone or other Point-of-Sale (POS) device (think Zettle, SumUp, etc)?
Then you have (perhaps, unknowingly!) played your part in a payment facilitation setup, a structure by which payment service providers (PSPs) allow their customers to accept money and grow their business.
What are some of the use cases of the PayFac setup?
E-commerce platforms (e.g. Amazon, Shopify) allowing their users (either businesses or individuals) to sell goods on the platform.
Invoicing businesses which help their clients issue invoices to their own end-users
Travel & holiday booking companies (e.g. Airbnb, Booking.com) which process and hold payments from individuals for their holidays before transferring those payments to their ‘hosts’ who list their booking on the platform.
Fintechs (e.g. Revolut, Qonto) who want to offer their clients the ability to enable card payment acceptance for those clients’ end users (either online or via another method such as POS acceptance), where the fintech does not have an acquirer licence itself.
🧩 What are the possible structures for this set up?
There are two main approaches, depending on which type of acquirer you choose to partner with.
In-House model (the ‘Traditional approach’): a company from one of the use cases above (fintech/e-commerce/travel platform) contracts with an Acquiring Bank/PSP and goes through the process of becoming a PayFac itself, to allow its own customers to accept payments from their end users.
E.g. fintech X wants to allow its restaurant/market seller clients to accept payment from people buying a meal/buying meat and veg at the daily market they’re present in.
E.g. travel platform Y wants to allow the clients who’ve listed their hotel/apartment on the platform to more easily receive payment from their customers who make bookings.
The company (X or Y) is often a regulated institution and can build their own white label approach that integrates the payment acceptance.
Reliance model (the ‘Stripe approach’): offered by players such as Stripe where a company contracts with a Stripe (or similar), relies on Stripe’s licence, and embeds the payment experience in their app using that provider’s technology.
The remainder of this article focuses more on the In-House model, but will at times touch on comparisons between the two.
💳 What is a Payment Facilitator? What does a PayFac do?
Before we begin, let’s be clear on what exactly a PayFac is and why it’s something essential to the payments universe today. Going back to first principles, the answer is quite self explanatory: it quite literally facilitates payment. On behalf of whom? Well, on behalf of the payment facilitator’s clients. Visa’s own documentation describes it (fairly) succinctly: “a payment facilitator is a third party agent that may:
Sign a merchant acceptance agreement on behalf of an acquirer.
Receive settlement of transaction proceeds from an acquirer, on behalf of a sub-merchant.
A sub-merchant is a merchant whose payment services are provided by a payment facilitator. Aside from rules that require an acquirer to sign the merchant agreement and settle, all Card Scheme merchant requirements apply equally to a sub-merchant.”
To translate this to a relatable scenario, let’s take a fintech providing a bank account or payment account to its clients:
Having focussed initially on products that allow its customers to make payments, it now wants to expand its product range by adding payment acceptance methods for its customers so if you have a shop (or any business) selling goods you can accept in person payments by card using your fintech account (this is all part of the fintech wars to become your primary account provider).
To implement this product, your bank/payment account provider (unless they themselves have a licence as an Acquirer) needs to become a PayFac, a legal/regulatory status that is governed predominantly by contractual rules determined by the Card Schemes (Visa, Mastercard, Amex, JCB) rather than EU or national regulation.
As with the last APC post on card processing (and actually most topics in the payments universe) I find it easiest to set things out visually with a diagram:
The key participants in this model are:
Acquiring Bank/PSP: The financial institution (bank or PSP) providing banking or payment services to the PayFac.
PayFac: The financial institution (bank or PSP) providing banking or payment services to the Sub-Merchant and working with the Acquiring Bank/PSP to enable card acceptance for its Sub-Merchants.
Sub-Merchant: The business (a customer of the PayFac) accepting the payment, using a card terminal or mobile acceptance device provided by their PayFac.
Customer: The consumer or business making the card payment.
Issuing Bank/PSP: The bank or PSP that issued the card being used by the Customer.
Card Scheme: Networks like Visa, Mastercard, Amex, or JCB, which set transaction rules and facilitate processing.
Card Processor: A third party (e.g., Marqeta, Enfuce, Monext) that literally processes the card payments, managing transaction authorizations and settlements if the issuer lacks processing infrastructure (some PSPs act as card processors, so you can in theory have PSPs involved at Acquiring Bank, Card Processor and Issuing Bank stages of this framework).
The steps involved in the transaction are:
Customer initiates payment by paying for something (e.g. a coffee) at one of the Sub-Merchants of the PayFac.
PayFac routes the transaction to the card processor which then sends the transaction for approval to the relevant Card Scheme (if the Customer’s card is a Visa card, then the relevant Card Scheme will be Visa).
Card Schemes send the transaction to the Issuing Bank/PSP for authorization.
Authorization response from Issuing Bank/PSP flows back through networks to PayFac.
Funds settle from Issuing Bank/PSP to the Acquiring Bank/PSP and then to the PayFac (the latter step, the payout, will be settled according to the contractually agreed timeframes between the Acquiring Bank/PSP and the PayFac).
PayFac distributes funds to Sub-Merchant (minus transaction fees due to PayFac and/or the Acquiring Bank/PSP).
📚 What rules is a PayFac subject to? What’s the legal framework?
The legal framework is as follows and requires a lot of Risk, Ops and Legal/Compliance effort to set up right. All of this in turn impacts the Product and Tech team who is developing the user flow:
Card Scheme rules (Mastercard, Visa, Amex, JCB, Diners Club, etc):
These are the scheme rules that apply to PayFacs (such as those of Mastercard or Visa).
Acquiring Bank/PSP contract with the respective Card Scheme
The Acquiring Bank/PSP contracts as a “principal” member of the relevant Card Scheme enabling it to accept card transactions for itself and also for entities such as PayFacs contracting with it.
PayFac contract with Acquiring Bank/PSP
A services contract between the PayFac and the Acquirer Bank/PSP setting out the conditions on which the latter agrees to provide card transaction acquiring and settlement services to the former.
This contract “back-to-backs” in large part the obligations the Acquirer Bank/PSP has with the Card Schemes.
Sub-Merchant contract (aka payment processing T&Cs) with PayFac
The contractual T&Cs that a PayFac puts in place with its own customers (the Sub-Merchants) to regulate usage of the card acceptance (aka payment facilitation) service.
This contract will differ depending on the type of card acceptance you are offering (e.g. Tap to Pay terms will be different from POS terms) even though both forms involve payment facilitation.
🚧 What risks should you be aware of?
Having studied this in a number of contexts in the past years, the PayFac setup is complex, full of requirements from both the Card Schemes and the Acquirer Bank/PSP and is extremely operational in its nature. It requires full-on engagement from the Product Counsel or Legal team member to ensure these Card Scheme and other contractual requirements are mapped out and implicated teams are made aware of the need (whether it’s for Product / Tech development or for operational and risk monitoring of the setup). The Card Scheme rules are complex, the Acquiring Bank/PSP will also have their own requirements based on their risk assessment of you and your customer base and there is a large amount of risk information to manage.
There’s also a lot of obligations you need to map onto your current practice before you can be confident to launch a product that isn’t going to get you burned by the Acquiring Bank/PSP or Card Scheme at some point down the line. This is exactly the zone in which a good Product Counsel operates - deciphering the complexity into practical actionable steps (below is an example of the way I tried to structure it one of the first times I looked into the setup).
⚙️ Key Operational Points of Attention
There are too many operational details to go into in one post but picking out a few noteworthy points of attention:
🏦 Reserve Account structure:
Some Acquiring Banks/PSPs requires immobilisation of a % of cash in a dedicated reserve account to hedge against the possibility of fraud, chargebacks and other risks.
Fixing that % level will be a matter of negotiation between you and the Acquiring Bank/PSP as well as a business decision as to how much cash you can/are willing to immobilise.
Often the PayFac contract states that this reserve amount can be reviewed and increased at regular intervals by the Acquiring Bank/PSP. Sometimes it’s even defined as a dynamic % based on a calculation you don’t understand (and won’t be revealed to you by the Acquiring Bank/PSP). While this represents a logical approach to a situation and risk profile which is always in flux, pay attention to this. Any increase should be capped at a % that you and senior management + Risk teams are comfortable with. You should also have a healthy buffer (e.g. 30-60 days) before the cash actually has to be present in the reserve account, to give you more room for manoeuvre with your cash management.
📈 Sub-Merchant Agreement signature for Sub-Merchant exceeding USD 1m in annual transaction volume
This implies you need to monitor on a Sub-Merchant-by-Sub-Merchant level the revenues each Sub-Merchant is receiving on its account. Again, technically this is feasible and setting a rule flagging when the USD 1,000,000 mark is attained via card acceptance probably mitigates the risk but it requires bandwidth from Ops, Product and Tech teams to monitor this, anticipate the threshold being breached and then put in place the Sub-Merchant Agreement, ensure it is signed by all relevant parties and that the Sub-Merchant complies with the greater obligations set out in the Sub-Merchant Agreement.
As the Legal team member you also need to have anticipated this in your customer payment acceptance T&Cs, stating explicitly to your customers that when this USD 1,000,000 threshold is reached, they will be required to sign a new agreement (and failure to do so will result in their acceptance service being switched off).
🌍 Mastercard and Visa can request Acquiring Bank/PayFac provide written certification by Sub-Merchant attesting to its location and compliance with the location rules
The possibility that as an Acquiring Bank/PSP you can be obliged by the Card Schemes (MCD, Visa) to contact individual Sub-Merchants to obtain written certification of these merchants’ compliance with location rules is potentially very burdensome.
How do you do it operationally, what if the merchant doesn’t respond? Do you suspend their account? How many clients do these requests relate to? One or two clients may be acceptable, if you scale that to thousands, it becomes a nightmare.
💲 Settlement funds sent from Acquiring Bank/PSP to PayFac may only be used to pay Sub-Merchants pursuant to Sub-Merchant Agreements
Practically this is doable but requires an extra operational setup to allow you to identify and segregate client funds received from the Acquiring Bank/PSP before passing them on to the Sub-Merchant’s main account. Operationally it adds a layer of complexity that adds cost and risk to the business and requires thought/reflection before putting in place.
🕵️ PayFac must monitor on an ongoing basis the activity, use of trademarks/logos of the Sub-Merchant for purpose of deterring fraudulent + other wrongful activity (minimum merchant monitoring standards set out in the Card Scheme Security Rules and Procedures manual apply to this)
This concerns monitoring of customers which goes beyond the normal KYC, anti-AML and transaction screening measures to encompass a broader set of criteria and failure to do this can result in fines from the Card Schemes and/or Acquiring Bank/PSP or even exclusion from the ability to offer these services.
This presents a potentially nightmarish level of granularity in monitoring the behaviour of your customers and I’d query whether businesses are actually able to meet this bar (and what risk the logos part of it really protects the Card Schemes from).
🔍 Onboarding with Card Schemes as a PayFac
Offering payment acceptance services as a PayFac requires that you register as a PayFac with the Card Schemes and go through a whole series of classic onboarding requirements (even if you already work with the Card Scheme in other contexts) adding to the layers of bureaucracy.
In addition to the operational and contractual ramifications of becoming a PayFac, from a legal perspective, the PayFac takes on responsibility for the actions of its Sub-Merchants under the Card Scheme operating regulations, as well.
🚵♂️ If it’s so cumbersome, why do it?
The answer (somewhat obviously) is that the potential reward outweighs the risk. Offering card acceptance encourages card usage which boosts interchange revenues (which particularly in a B2B context are a significant source of payment company revenues). The payment acceptance market alone in Europe is estimated to be worth between $25-40 billion and c. $100 billion globally. Capturing a part of this market is crucial to the future success of many of Europe’s fintech champions.
Both models, the In-House Model and the Reliance Model, are complex to implement but the In-House Model also allows you, as the PayFac, to own more of the end-to-end user experience with your customer (albeit you are reliant on a 3rd party Acquiring Bank/PSP for the precise speed of payout…but this can be optimised operationally over time working with your Acquiring Bank/PSP).
There is no requirement, for instance, to re-KYC your customers, as there would be in the Reliance Model (despite its name, the party on whom you are relying has their own regulatory licence to think of, so they have to be satisfied with the KYC process you are using).
However, from a technical perspective in an In-House Model you still need to split the funds per Submerchant and take off the fees you charge them during the payout process (i.e. the process by which your customers receive their money).
Under the Reliance Model on the other hand, you don't need to manage the payout split and the pricing (the split is automatically done by the provider you’re relying on (e.g. Stripe), they send the net payout individually to the Sub-Merchants' account at the PayFac. The PayFac will also get the fees charged directly on its account hosted by the provider’s platform.
🌟 What are the essential steps for a Product Counsel advising on a PayFac scheme setup?
See this as a chance to shine: it’s an area where lawyers have an advantage (they’re used to processing large volumes of (often complex) information and synthesising it for others); this is a chance to show how valuable it is to link the legal understanding with the product understanding and business goals.
Map out all the rules: take the time to read and map the Card Scheme Rules and contractual requirements, and flag points to your teams working on this that could impact their own work (see the screenshot example above ☝️). It’s largely common sense coupled with understanding of the business.
Map any contractual provision onto Card Scheme rules: often the contract with an Acquiring Bank/PSP is a back-to-back of Card Scheme rules). Card Scheme rules are hard to negotiate as they’re imposed by Card Schemes on Acquiring Banks/PSPs. Items that are not based on Card Scheme rules are usually easier and open to contractual negotiation. So focus your energies where you can make a difference.
Meet proactively with Product, Risk, Ops teams: you should understand what’s possible and ensure that you are there for questions during the development phase.
Advocacy with senior stakeholders: to make sure they understand what this product launch entails and how it will require significant resources (but also the opportunity that it offers the business).
Common sense goes further than you think: always have a common sense read of any documentation/contracts/exchanges with the partners. Always think “what will this entail me or my teams doing” and “does this increase risk to the business in any way (whether legal, operational or financial)”? One of the privileges of being a Product Counsel is that you are often the gateway between the product and the rest of the business - so make sure you work with your peers to drive things forward, master the details and deliver a successful (and rapid) product launch!
If you want to discuss any elements of this piece feel free to contact us at associationproductcounsel@gmail.com or join the discussion in the comments/on LinkedIn.