Payments contracts: a guide to gateway and acquiring services for in-house counsel

Whilst there is no doubt that payments/getting paid is a critical topic for merchants it is surprising that many merchants overlook the contracts governing the provision of payment services (i.e. contracts for the provision of gateway and/or acquiring services) (payments contract(s)), often accepting them “as is” or with little amendments because they are incorrectly viewed as standard/low risk and simple.

Nothing could be further from the truth: if things go wrong under a payments contract, then merchants may be unable to accept payments from customers meaning lost revenue and they are complex agreements, being a hybrid of a tech and finance agreement, and so involve input from various subject matter experts including commercial/tech, regulatory and data protection.  

This article sets out some of the key legal and commercial issues for in-house lawyers to consider when contracting with a supplier under payments contracts.   

NB. often there are two suppliers providing the relevant services under a payments contract: a gateway supplier for the provision of gateway services and an acquirer for the provision of acquiring services.  This means the payment contract is often a tri-partite agreement between two suppliers and the merchant customer. Unless otherwise set out in this article, references to suppliers means the gateway supplier and the acquirer.

Understand the payment set-up

It is important to spend time with the business to understand the set-up underpinning the payments contract.  Questions to consider include:

• Are you procuring gateway services and/or acquiring services?
• Do you have existing gateway supplier(s) and/or acquirer(s) (incumbents)? Do you wish to continue to use them?
• Are there any minimum commitments/exclusivity provisions in your payments contracts (either with the new suppliers or incumbents) that could create issues?
• Will you be using the suppliers to help you accept card present and/or card not present transactions from customers?
• What merchant systems need to interoperate with the gateway supplier’s IT systems (gateway platform) so you can receive the services and is the tech team aware of (and comfortable with) the implementation requirements? 
• What rights does the acquirer have to withhold settlement monies due to the merchant? Are there set-off rights for chargebacks, refunds and fees which are taken from the payments sent to you rather than invoiced and then paid by you on an agreed basis?
• How quickly should funds be settled to the merchant (e.g. T+1, T+2)? Is settlement dependant on receipt of funds by the acquirer? 
• Are you being asked to post collateral or security with the acquirer which will involve you placing a significant amount of funds with the acquirer that you cannot use for your business?

Understanding the answers to these questions is important to ensure that the services are being provided in a way which is suitable for the business.

Tech set-up

Often the payments contract will be very light touch on technology related commitments which is peculiar given how much they rely on technology.

Normally the set-up is as follows (assuming the merchant procures gateway and acquiring services):

• The merchant is provided an API to integrate its merchant systems with the gateway platform so that it can submit transactions to the gateway platform (the gateway platform then sends these transactions on to the acquirer’s acquiring platform that is integrated with the gateway platform).
• The merchant is provided access to a separate portal to view the transactions sent/received via the gateway/acquiring services.  This will allow it to reconcile this data with its own data so it can view what transactions are being processed, how much money it is receiving and how much fees it owes the relevant supplier.  This portal might be provided to access via API or web browser. 

However, the payments contract doesn’t provide much detail on the following:

• Performance warranties i.e. that the relevant technologies will perform in accordance with agreed specifications.
• If an API is provided, a clear process around what happens when the relevant supplier makes changes to the API (which may impact the integration work undertaken by the merchant which has used the API to integrate to the gateway platform) so that the merchant has enough notice to undertake any additional software integration work to ensure the API continues to be fully integrated with the merchant’s systems.
• Details of any acceptance testing relating to implementation.

In addition, there are very limited service level commitments around the availability of the gateway platform and acquiring platform and even when these commitments are provided they are subject to a number of exceptions/carve outs (e.g. service credits are the sole and exclusive remedy for the relevant service level failures).  

This links to our note above around the importance of understanding the payments set-up. If the merchant already has a number of incumbents, then it already has built-in resilience if, for example, the gateway or acquiring platforms of the relevant supplier go down and the merchant can’t use them to help it accept payments (because the merchant can then re-route transactions to the incumbents and their platforms).

Termination rights

The acquirer is a regulated entity so will often include numerous termination and suspension rights for a variety of circumstances.  Some of these termination rights can be quite hair-trigger, including for example where the acquirer believes the risk profile of the merchant has become unacceptable or in circumstances where the merchant damages the reputation of the acquirer or the card schemes.

It is important to try to narrow down the scope of these triggers wherever possible to avoid continuity of service issues.  However, it should be recognised that as regulated entities that also need to comply with various card scheme rules, the acquirer will need to impose a variety of termination rights in the payments contract.

In some situations, to help mitigate the impact of the trigger, the merchant could try to argue the relevant event should only warrant termination of a particular service (e.g. acquiring services but not gateway services) given the nature of the termination event is only relevant to a particular service (e.g. the acquirer is worried about excessive chargebacks so perhaps it can terminate the acquiring service but not the gateway service).

Security, settlement, set-off rights 

One of the key issues to get right is when the merchant gets paid and how the payments contract deals with payment by the merchant of the fees (comprising acquirer fees and pass-through fees such as card scheme fees and interchange fees), chargebacks, refunds and card scheme assessments.

You will want to ensure there is clarity around payout schedules and how long after a card payment is approved, settlement is paid to you (e.g. T+1, T+2). There is often a number of working days between a card payment being approved, settlement to the card schemes and payment then to the acquirer.

In respect of dealing with the payment of fees, chargebacks, refunds and assessments, a good position for the merchant (subject to specific preferences of the business) is:

• The value of each transaction amount is remitted to the merchant gross (i.e. with no deductions), save that the acquirer can set off from the settlement monies amount an amount equal to any assessments due and any refunds the merchant agrees to and the acquirer can set off from the transaction amount an amount equal to chargebacks if the scenario in bullet 3 below occurs.
• The acquirer separately invoices for its fees and chargebacks. 
• However, if the merchant fails to pay chargebacks properly due (including where they are not subject to a good faith dispute), then the acquirer can set off from the value of any transaction amounts an amount equal to the relevant chargebacks prior to such transaction amounts being remitted to the merchant.
• The merchant resists having to provide any security to the acquirer (to pay for chargebacks, refunds, assessments), unless it is a delayed delivery merchant (e.g. airline).  

Liability and indemnities

Typically suppliers will seek to set out a very exhaustive list of non-recoverable losses.  Merchants should keep an eye out for exclusions such as “loss or corruption of data”, “loss of use” or “replacement supplier costs” as they are some of the key losses they might seek to recover.  It is generally standard for suppliers to state that loss of profits, revenue or business are non-recoverable.  Merchants should consider mitigations to reduce any potential loss of sales as a result of problems with the relevant supplier’s systems such as having alternative replacement suppliers/incumbents in place to accept payments and/or insurance.

It is standard for a supplier to provide an indemnity for losses the merchant may suffer or incur as a result of losses arising as a result of claims from third parties that their use of the suppliers’ systems infringes a third party’s IP.  Merchants should look out for any restrictions on these types of indemnities.  For example, attempts by the supplier to: (i) make such indemnities capped; (ii) make recoverability under the indemnities conditional on complying with a conduct of proceedings clause; or (iii) limit the scope of the indemnity to only certain IP.  
The suppliers may also ask for an indemnity from the merchant in respect of losses they suffer arising from claims from third parties.  The suppliers’ position is they are intermediaries acting between the merchant and the card schemes, card issuers, cardholders and so if they suffer a claim from such third parties as a result of something committed by the merchant then they should be indemnified.  Merchants could try to cap the indemnity and limit it to losses caused by them by they may receive push back.  For example, the suppliers may state that the indemnity should cover any third party claims other than those arising because of their default.

Changes

The suppliers will seek to include various provisions giving them the ability to change the terms of the payments contract (including the fees) and the services and software on notice. This could be for various reasons.  For example:

• Changes to the legal terms and conditions because of a change in law or a change in the card scheme rules.
• Changes to the services or software because of a requirement to roll out a new version of the software underpinning the gateway or acquirer platform.
• Changes to the fees if the transaction volumes go above or below an agreed benchmark or because of changes to the interchange fees or card schemes fees portion of the fees.

It is important that the merchant has visibility on what changes can be made and what notice is provided.

For example: 

• Changes driven by legal or card scheme rules are understandable but ample notice should be provided together with a potential right for the merchant to terminate if it is not happy with the change.
• Changes to services or software should be provided with ample notice so that the merchant can make any updates to its systems that integrate with such software and to ensure that any changes to the services do not materially change the performance, functionality or security of the services experienced at the date of signature.

Use of your data

Merchants should carefully consider what the supplier can (and can’t) do with their transaction data.  For example, it is fine for the suppliers to use the transaction data to provide the services but any further use (such as using the transaction data to develop other products or services or for the benefit of the suppliers’ business more generally) should be carefully considered.

Data protection

Merchants should have a clear understanding of the role of the supplier – when exactly is the supplier acting as a controller and when is it acting as a processor under the particular services being provided? This should be clearly reflected in the payments contract and appropriate data protection provisions should be implemented, including mandatory Article 28 processor terms to the extent they are relevant. 

The merchant should consider whether there will be transfers of personal data to the supplier in non-adequate third countries and ensure that a suitable transfer safeguard is in place as necessary.

Regulatory

The card scheme rules of Visa and Mastercard impose obligations on the acquirer as the acquirer is a participant of their card scheme system. However, these card scheme rules also impose requirements on the acquirer to procure certain requirements from the merchant even if the card scheme rules do not directly apply to merchants. Such rules include not providing goods or services in prohibited categories and ensuring that chargebacks or refunds do not hit certain thresholds or if they do, certain penalties must be paid. As a result, expect the payments contracts to include obligations on the merchant to comply with the card scheme rules.  However, this is a very broad obligation and merchants should consider narrowing this to certain rules relating to them that are, ideally, incorporated into the payments contract so there is clarity as to the merchant’s obligations.

Payment services and Fintech more generally is developing at a fast pace and requires input from multiple stakeholders given its intersection between tech and regulation. The above issues are a useful starting point for a review of these types of agreements but please reach out to the Fintech team contacts below if you would like to discuss anything further.