How to prepare for sending out an RFP

This document is meant to provide potential customers a framework to evaluate payment processors.

PRELIMINARY QUESTIONS

Every business is unique and they vary by factors including their business strategy, their capabilities, their total processing volume, and more. To start, there are a few questions you should ask yourself to understand the different options you have around integrating a payments processor.

Question 1 is the most important and your answer will determine your next steps. Not all processors are alike because each one addresses a different need. 

What is your true business objective with payments?

1. Simple payment enablement: Your business needs to get up and running as fast as possible.You don’t want any customization to your business - you just want simple payments fast. Skip straight to the “Pricing” section below. There are a number of providers who can enable payments for you at a very low price.
2. Maximum revenue over time: Your primary focus is on engagement, driving users to your platform. Payments is more about how your users experience your business via merchant onboarding, the payer experience, and customer support.
3. Risk management: You either operate a risky business or you are aware how quickly various forms of payment risk can affect your bottom line. You want a processor who can protect your business as it grows.
4. Feature demand: You want to enable a particular feature of payments above all else. Maybe you want a mobile point of sale (mPOS) solution so your merchants can accept payments in stores, as well as online. Maybe you want a push-to-debit solution to enable your merchants to get access to their cash immediately.
5. Monetization: You know other ecommerce businesses are using payments as a revenue stream and you want a partner who has experience delivering this solution.
6. Data: Payments is not your end game. You want to control access to the transaction data on your platform. Perhaps you want to offer your users analytics, or maybe you want to offer small business loans. To do this, you need a provider who enables you to monitor and understand the data.
7. Partnership: You want to accept payments but you don’t have a long-term vision for whatyou want to do in the future. You do know, however, that you want a partner - an expert who will provide you with technical and business resources, who will navigate your issues and identify areas to grow your business and who will answer your emails when you run into problems. You want a company who will actively think about what’s in your best interest, long after you’ve signed a contract.

Now that you have thought about what your objective may be, Questions 2 and 3 focus on what resources you have. If you want simple enablement, these questions should be easy. Often, however, a business which wants a more integrated solution underestimates the time and complexity required to build a payments system that suits their specific needs.

How involved do you want to be in the integration process?

Do you have the time and resources to support a customized integration?

1. Simple enablement: Not involved and no resources needed.
2. Integrated without help: I want to be involved and I have the ability to integrate with minimal support.
3. Integrated with help: I want to be involved but need support, including after integration.
4. Payment Facilitator: I want to become my own PayFac.

Beyond your business’ resources, you should be aware that there are different levels of brand exposure. As your payments solution becomes more white labeled, your business will increasingly bear the brand risk if things go wrong. The security burden is tied to brand exposure - more customization will require a greater burden on you.

How much brand exposure are you comfortable bearing?

How much of the security burden do you wish to handle?

1.  None: I want a solution where the payments provider is the user-facing company for transactions.
2. Some: I want a solution where some payment processes that a user encounters appear to be with my company, but the ultimate responsibility lies with the payment provider.
3. Balance: I want a provider that can help me with the risks and also allows me to appear to be the processor.
4. All: I just need a processor on the back-end and I will assume almost all exposure.

Often overlooked, these last preliminary questions play an important role. Businesses often underestimate the cost involved in using their own compliance and customer support systems.

Do you have a compliance system in place?

How much excess customer support capacity do you have?

Your answers to the above questions will shape how you think of the different integration options that exist and the different providers who can help you.

MERCHANT OPERATIONS

Onboarding

You need to ask yourself how integral payments is to your onboarding flow. If it is, this section will require more of your time and you may be interested in a custom onboarding process.

When do you want to collect the Know Your Customer (KYC) information?

This can be done during the initial merchant sign-up to help with verification, or delayed to reduce friction and improve engagement.

Do the merchants remain on the platform website for a better experience and customization or do they get taken somewhere else, an approach common with a minimal viable product (MVP)?

A platform can also use an embedded iframe, which can be customized, to gather the necessary merchant information.

How fast can the onboarding be?

And how does the onboarding process affect the user experience?

Most providers offer one at the expense of the other.

Reporting

Merchant reporting - does your payment processor offer a merchant support center for your merchants?

Can it be hosted on your platform?

Payment processors should offer webhooks to allow you to monitor transactions from each stage of the process. Your payment processor should provide you bulk reports, including transaction and settlement reports, so you can take the data and render it in your own application.

RISK AND COMPLIANCE

Risk Management

Since risk management responsibilities can change depending upon your processor, it is best to ask who will be responsible for the following issues?

1. Merchant risk: Where merchant identity is valid but the merchant does not reliably deliver agreed upon goods and services, resulting in a high chargeback rate.
2. Buyer fraud: Where a fraudulent payer purchases goods or services using stolen credit cards from a valid merchant.
3. Collusion fraud: Where a fraudster impersonates a valid business and pays him or herself using stolen credit cards.
4. 419 scams: Where a fraudster overpays and asks for payment back to themselves or a "subcontractor."
5. Account takeover: Where a fraudster takes control of a merchant account via phishing, password guessing, or malware; redirects settlement of legitimately-earned funds to their own bank account.

   Other questions to ask a processor offering risk management:

   What information does your processing company use to verify merchant and payer information I provide?

   What percentage of transactions do you manually review?

   What is your auto-decline rate?

   Can you tailor your signals and rules to my company’s accounts?

   How quickly will my merchants be able to receive their money from transactions?

   Keep in mind that risk management pricing depends on your individual business, including the merchants you support. A payment processor will always ask for a list of your Merchant Category Codes (MCC) to determine what sorts of merchants use your platform

Compliance

Ensuring your system complies with federal laws, bank rules, and card network agreements is a difficult and time-consuming process.

You should ask each potential vendor whether they handle each of the following compliance issues or whether you will have to?

1.  KYC
2. Anti-Money Laundering (AML) and Bank Secrecy Act (BSA)
3. Suspicious Activity Reports (SAR)
4. Office of Foreign Asset Control (OFAC) Specially Designated National (SDN) and other anti-terrorist lists
5. Sanctioned country enforcement
6. Acceptable Use, including network compliance
7. Terminated Merchant File (TMF) or MATCH file
8. Subpoena responses
9. Tax withholding and reporting (e.g. 1099-K)

PROCESSING AND SETTLEMENT

Methods of Payment

Processors offer similar payment solutions. The two dominant types are credit cards and eChecks (ACH). It is also worth considering whether the processor supports mobile wallets, including Apple Pay, Android Pay, and Samsung Pay. Some even support cryptocurrencies like Bitcoin.

Processing

The mechanics of processing are similar across processors. That is because processors rely upon the same network of card networks and banks to take funds from your clients and route them to you. Processors should be able to conduct both one-time and recurring payments. It is also helpful to use a processor who provides automatic updating of credit card accounts, especially if you rely upon recurring payments.

Money Transmitter License (MTL)

One area that differentiates payment providers is whether they have money transmitter licenses in the United States, and if so, in which states. This is important for businesses where you want the payment provider to hold transaction funds. Partnering with a company that has a MTL allows transaction funds to be held in escrow and enables you to pay merchants over longer time horizons.

Settlement

Another area that differentiates processors’ costs is in settlement, because some processors include settlement in their pricing and some do not. Therefore, it is important to clarify whether a processor supports settlement (i.e. payouts). If so, you should determine what types they offer. The most common are ACH transfers and physical checks, but some platforms request wire transfers and push-to-debit (e.g. Visa Direct, Mastercard Send).

SUPPORT AND ADDITIONAL CAPABILITIES

Support

There are two different types of support: integration support and customer support. Integration support will differ based on several factors, including your processing volume. Integration timelines will depend upon your processor, but are mainly determined by your ability to support integration. Regardless, it is important to determine if a processor is offering dedicated integration support in the form of an integration engineer.

Often overlooked or ignored, a payment processor’s ability to provide responsive service-level agreements (SLAs) is a critical component of their offering. The reason? Companies considering a new processing solution or doing payments for the first time often underestimate the time involved and the complexity of supporting payments. For one, it requires your existing customer support function to gain payments expertise. Secondly, money is a significant friction point for all businesses, and your merchants will be much more sensitive to problems they encounter and will show your business little patience. You should take an honest assessment of your existing customer support needs and consider whether payments customer support is something you can take on or whether you need extra help.

Some other questions to consider:

1. Does the use of a mPOS or POS solution change the compliance or security burden on me?
2. Which terminal integration is right for my business (SDK or cloud)?
3. Which payment methods for card present transactions does the payment processor support?
4. What type of card present hardware do I need, which ones does the processor support, and how does the hardware change security vulnerabilities?
5. What is the process of acquiring the hardware? Do I go through the payment processor or the hardware provider?

Security

Your payment processor should be a Payment Card Industry Data Security Standards (PCI DSS) Level 1 compliant organization, meaning it has met card network security standards for processing high volumes of transactions. How much of a security burden you take on will be determined by the type of integration you prefer. For example, if you want to store credit card information on your servers (i.e. sending information to your provider via server-to-server API calls) and therefore be “in PCI scope,” this will require more compliance on your part, including regular system audits and penetration tests.

You should also consider whether the payment processor supports tokenization, how often the processor independently audits their systems, and what security standards the processor has for its servers.

Some processors offer point to point encryption (P2PE), a designation by PCI, indicating encryption between point of sale payment and the processing system. Before P2PE, a credit card swiped at a mPOS or POS could have its information stolen when the card information is sent to the issuing bank to verify authenticity. P2PE indicates whether a mPOS or POS system uses encryption to prevent such information theft.

Card Present: mPOS and POS

Omnichannel payments is a reality and a payment processor’s ability to offer mobile point of sale (mPOS) and point of sale (POS) solutions is important for some customers. Payment processors should be able to offer at least two types of integrations: a mobile software development kit (SDK) that supports iOS and Android and a cloud-based integration via APIs.

You should consider several issues when evaluating payment processors:

1. Who will the payment processor support? Only you, or you and all your merchants?
2. What is their advertised SLA? How quickly can they respond?
3. How will you communicate with the payment processor?
4. Where is the customer support located?
5. Does the payment processor offer customer support training? 
6. Does the payment processor offer extended coverage outside of normal business hours?

A final point about security that you should consider is the processor’s ‘up-time,’ the percentage of time that processing flows normally. Due to a variety of factors, including server issues, a processor’s ability to process payments fails. The best processors should have very strong up-time - above 99%.

Geography

Payment processors differ in their ability to support your operations in different countries. Moreover, their capabilities will likely differ depending on the individual country. If you are interested in a processor that can support multiple geographies, you should inquire whether the processor contracts with a vendor to support that or whether the processor themselves has a local entity in country, has in-market acquiring, and has treasury capabilities (i.e. settlement) in each market it supports. Payment processors may also require multiple different integrations for additional countries and may also have different card present processing capabilities depending upon the country.

PRICING

Buy Rate

Payment processors incorporate interchange and card assessment rates that will be consistent for your type of business, your typical merchants, and the methods of payments users of your service employ.

Payment processors also have common pricing for routine payment activities, including chargebacks and settlement.

To offer you pricing, a processor will need to know a few key things about your business. First, a processor will need to understand your business’ pay mix, i.e. what the most popular payment methods (e.g. credit, debit, ACH) are on your platform and what percentage they represent of your business’ total payment volume. Second, processors will need to know your card mix, which is the percentage of your credit card transactions that occur with Visa versus Mastercard versus American Express. Third, a processor will also need to know your merchant category codes (MCCs). MCCs indicate to the processor what type of merchants use your platform and will be key to understanding the riskiness of your business.

Once you have the requisite information, consider what type of pricing works best for you. Keep in mind, not every processor offers multiple pricing models.

• Blended Rate: Processors will charge your business a combination of a percentage fromthe total volume of your transactions as well as a nominal per transaction charge. A blended rate is simple; most processors offer it as standard.
• Interchange Plus (IC+): Some processors can charge you a percentage on top of interchange, or “interchange plus.” IC+ is less widely used, but is becoming more common. It can be good for you when you know your pay and card mix really well. It ensures you won’t pay too much but it also ensures the processor doesn’t lose money either.
• Revenue Sharing: A revenue sharing pricing model is an agreed upon split of total platform revenue. This is the least common pricing model. Usually, it is an option for platforms at significant scale.

The reason processing costs will differ based on the payment processor is because payment processors vary in what they are providing and what they will do for your bottom line. For customers who just want to enable payments, they want to be the lowest buy rate possible. But the buy rate a processor offers, after a certain point of scale, is a direct reflection of both the services provided as well as the benefit to your business. A processor that offers you UX customization, tailored onboarding, complete risk coverage, daily customer support, mPOS solutions, and compliance assistance will be priced higher than bare-bones processing support. Furthermore, a processor akin to the former description is not more expensive just because it costs more to build such a solution, but because of the impact it will have on your revenue. For example, a leading risk management solution will reduce your payment auto-decline rates and chargebacks - both mean more money for you. More rudimentary risk solutions force you to bear either greater losses or higher auto-decline rates.

Merchant Pricing

Merchant pricing is a final consideration. Many customers are unaware of the potential to monetize payments by taking a cut of the buy rate. Some customers decide not to monetize because they are trying to offer their merchants the lowest rate possible. Regardless of your preference, a payment processor should be able to work with you to determine a different rate.

A) Profit Sharing: Another less common model is the split of payments profit. This is also more common for platforms at a certain scale.

B) Loss Provision: There is not always a separate pricing system from buy rate, IC+, or revenue sharing, but whether the processor bears or doesn’t bear losses on your platform is something you should consider. It is not always easy to determine the level of loss from different types of risk on your platform. You should ask if it’s an option to start out with the processor bearing loss and shift that burden over time.