Online Enterprise Payments 101: How Modern Processors Generate Value

and how the main players are architected inside.

I think it’s essential to understand how the online payment chain works to fully grasp how (modern) acquirers can generate value by charging a take-rate on your payment transaction. I’ll put a particular emphasis on Adyen, linked to my prior post.

Being an acquirer is a bit like playing the role of a mediator in a complex situation where nobody wants to take responsibility for their conflicts. Picture yourself in a scenario where you're trying to reach a single opinion among tens of thousands of parties who speak different languages and frequently change their views. This is what payment acquirers deal with every second.

For an even more comprehensive reading, check Sophia Goldberg’s “The Field Guide to Global Payments”, an ex-Adyen who is now building some cool stuff in the wallet world.

The main players in the payments chain are:

• Issuing bank: the bank that issues the customers’ card. The issuer is responsible for allowing/denying a transaction, extending credit, and collecting the balance at month’s end.

• Payments gateway: a software that analyses, encrypts, and transmits transaction data from a merchant’s website account application to the payment processor securely, which connects to the issuing bank to request authorization, and then authorizes the transfer of funds when its authorization is approved. Gateways also often connect to fraud engines, non-card payment methods (“APMs”), and other vendors (e.g., CRMs, ERPs, customer authentication vendors). They can also provide token vaulting and accounting/reconciliation formatting & reporting between acquirers, issuers, networks, and merchants.

• Payment processor: the system that obtains the payment information from a payment gateway to redirect requests to /from card networks and issuer banks. Processors may or may not be acquirers also. Most payment providers often outsource processors.

• Acquirer / Acquiring bank: a financial institution that is the merchants’ bank partner who processes payments on their behalf and is a licensed member of the card networks. They are in the money flow to acquire settled transactions and push those funds to the merchant via a processor. An acquirer can also be the gateway and operate its own processor. Acquirers are members of the card networks and are generally liable for their merchants’ actions and transactions.

• The networks (“schemes”, “rails”): the networks (Visa, Mastercard, UnionPay, etc.) connect acquirers to issuing banks, provide a clearing house function, set the rules of engagement, determine transaction fees, and aggregate funds, so not every issuer has to talk to every acquirer (and in different ways). They provide the rails and rules for card-based payments to occur.

Using the abovementioned basis of definition, payment providers often bundle/unbundle activities of the roles of acquirer/processor/gateway and are often presented as:

• Payment service providers (PSP): a company that combines the functions of both a payment gateway and a payment processor and can connect to multiple acquirers or be an acquirer itself. Non-acquirer PSPs don’t fund their merchants – funding (settlement) is done by the acquirer; hence, they are not liable for financial risk in this case. If the PSP is an acquirer, it is usually financially liable. Many PSPs are PayFacs, which often serve marketplace verticals so that they often retain the function of onboarding, KYC, and fraud risk for their sub-merchants. Hence, these are liable for fraud & money-laundering actions on their behalf.

• Orchestration providers (“advanced gateways”): Those are payment gateways that add extra value for merchants by owning a complex routing logic between PSPs for better authorization rates or pricing. Volumes that go through these providers are also called “unbranded volumes”. Rather than a merchant building multiple PSP integrations to maintain routing logic in-house and then directing different transaction types to each PSP, they can outsource this process to the orchestrator.

• Independent sales organization (ISO): The job of an ISO is to get & resell small merchants to a connected PSP (for gateway and/or acquiring services). The PSP, in return, offers commissions to the ISO, so ISOs are useful as a go-to-market tool for large acquirers/PSPs. ISOs are not financially nor KYC-wise liable for their merchants.

• Payment facilitator (“PayFac”): A PayFac is a master merchant account to which the acquirer allows the PayFac to board sub-merchant accounts under the main account. They have a direct relationship with merchants, are responsible for onboarding compliance, and are liable for those merchants’ transactions and activity. A PayFac boards smaller merchants within their systems, which allows for faster speed to market and scales of economy for payment fees. At the same time, the PayFac has direct relationships with an acquirer rather than each merchant. The PayFac is liable for the actions of their sub-merchants (fraud & AML-wise). Notably, the acquiring rules from the Networks require local domestic sponsorship and entities, so PayFacs or master merchants must have a market or domestic entity wherever they provide payment services to sub-merchants. This can allow much broader distribution for PayFac’s merchants, who would otherwise need their own local entities to process in each relevant country. Many PayFacs are more than just a payment partner for their sub-merchants, often offering other services (e.g., booking platforms, subscriptions, etc.). A Payfac can also be a merchant of record (MoR), an entity responsible for reconciliation, managing disputes, disbursements, and funds, and often guarantees returns of goods, customer service, and order fulfillment. Some marketplaces are MoR PayFacs, while others are just “pure” PayFacs¹. The advantages of being a MoR are more control over customer experience and better negotiating terms with schemes and issuers, as the MoR takes more risk relative to PayFacs. PayFacs shares its acquiring and/or gateway fees with its sponsor acquirers. This is basically what Adyen does with the Platforms side, where Adyen shares its core payment fees with the PayFac merchants in exchange for being the provider of the non-payments platform services (onboarding, KYC, customer authentication, expense management, card issuing, payouts, etc.).

A typical card transaction involves 5 main steps:

• Pre-authorization: Information from website/mobile UI is sent over encrypted to the merchant’s application, which decrypts, assesses fraud risk (through a 3rd party fraud risk provider or its own system), and takes it over encrypted again to the merchant’s payment gateway.

• Authorization request: Payment gateway converts the message from XML/json format to ISO8583 format over to the payment processor, who sends it encrypted to the card networks, who routes the transaction to the relevant issuing bank.

• Authorization response: Upon authorization, issuers place what’s called an “authorization hold” on that shopper’s account for the amount requested. An authorization hold is typically good for seven to thirty days, depending on the issuing bank and the merchant category (e.g., hotels versus retail).

• Capture/clearing: Imagining that the merchant sells physical goods, it shouldn’t set the funds in motion until they’re ready to ship the products. You could request funds immediately for digital goods, like streaming or digital downloads. This request to set the funds flow in motion is known as clearing or capture. As the merchant sends the products in the mail to the customer, they then request their PSP to capture the approved funds. The gateway sends the capture to the networks through the processor, generally a batch file sent out a few times a day.

• Settlement: In the case of card transactions, the funds flow from the issuer through the network, the acquirer, and then to the merchant. Outside of card networks, funds can flow from the payment method to the merchant – sometimes directly or sometimes through an acquirer.

The whole authorization-settlement process described above, in the US, can take two to three days for Visa and MasterCard, and five days for American Express. This is one example of huge international variability: in Brazil, for example, the settlement delay is thirty days – where acquirers can offer their merchants a way to receive the funds faster – securitizing receivables.

The approval process of a transaction is visibly dependent on the synchrony of the message routing, encryption, and decryption, among merchants (including merchant’s bank account / merchant’s website/ customers’ mobile device), gateways, processors, acquirers, networks, and issuers, amid a myriad of different payment methods². This whole chain combines multiple types of systems of each player that must communicate with each other following strict, regulated & ever-changing technical rules. This complex web is one of the key reasons why authorization³ rates are much lower in online transactions relative to offline instances - on average, 10-20% of online transactions are refused, while in-store (POS) transactions have very low decline rates (<2-3%).

Most refusals result from false declines (those where the shopper is legitimate and using their own, legitimate payment credentials)⁴. Here are some of the points of complexity and inefficiency along the chain that contribute to the state of low auth rates and overall inefficiency in the online payments chain:

1. High fraud incidence: Whereas in offline instances, fraud is very low (<0.05%), in the online environment, they average c.0.3% of total transactions, reaching >3% in some countries. Fraud management is a high-profile problem because the merchant often transfers the liability to schemes and banks (attribution varies by region, business, and regulation), who can fine merchants or lift interchange prices should the merchant mismanage its fraud rates (merchants generally pay 1-2% of revenues in fines every year⁵). That is probably the main reason why risk models within schemes, issuers, and acquirers are rigorous and variable, as each one tries to defend its systems and liabilities according to its environment. But fraud protection is a constantly moving target as fraudsters adapt and get sneakier. It is a balancing act – a certain amount of fraud is accepted as a cost of doing business. Zero fraud means you’re blocking valid transactions and losing revenue. Fraud, then, is not just costly in terms of lost goods but also missed revenue through “false positives” and the necessary investment into fraud teams, tools, and procedures – or outsourcing that to PSPs.

2. Processor compatibility & communication with issuer, networks, and gateways’ risk systems: After the payment provider validates the transaction, it can still be rejected by the issuer due to a i) myriad of technical mismatches between the payment information, the payment provider, the schemes, and the issuer, or ii) by risk misjudgments from the issuer.

   After sign-up & validation, what variables ensure success in the transaction? Declined transactions are often sent to customers through error codes or simple messages such as “Your payment was not authorized; Error code: XXX”. In summary, refusals happen due to i) technical errors (e.g., system downtime), ii) bad routing choices (i.e., when acquirers need to choose the best scheme rail to maximize approval chances), iii) false positive checks by banks (e.g., deeming a good shopper as a bad shopper), iv) outdated card details, v) insufficient funds, and vi) additional authentication required by some issuers. The complexity around the diagnostics of refusal reasons exists basically because the approval depends on how the issuer’s bank and the credit card schemes’ systems respond to each type of transaction. These systems are often 30-40 years-old infrastructures stitched together in a long thread, making it difficult for the payment provider to tell what exactly is making the transaction to be declined. There are hundreds of different error codes, whose root causes for declines (even within error codes), such as “do not honor”, vary depending on the issuer, region, merchant, scheme, transaction value, customer account’s balance, time of the day, etc. This happens in a world with 25,000+ banks, 50+ different card networks (each being a wrap-up of dozens or hundreds of different systems built in the last century), and 3,000+ alternative payment methods. Not only do issuers & schemes have high variability, but most acquirers, processors, and gateways themselves were also built decades ago, dedicated to POS systems, with old tech and M&A’d altogether (Worldpay, for example, has c.70 different systems tied together) - what adds even more complexity. That leads to c.65% of enterprises not receiving detailed raw response codes on failed payments. As a result, the job of the payments processor is to properly “pack” and route the transaction data to send it to the rails with the highest chances of approval, and to “unpack” the transaction message with minimal data loss from the rails so it can understand why the transaction has been declined and what to do about it.

Here are the main ways in which the issuer-bank-PSP complexity creates inefficiencies in the transaction flow:

• Incompatibility of banks and acquirers’ risk models relative to a particular type of transaction: Each bank has a specific set of rules to judge if a transaction is not a fraud. These systems commit errors. Moreover, banks frequently update their risk models, and they do that without telling the payment acquirers what they have changed. These updates are motivated by things ranging from high fraud incidence in certain transactions in some regions to things like adaptations to Visa’s updates (who does it regularly every quarter with documents >700 pages long). In some instances, the technical complexity in those systems is so high that issuers themselves can’t even know what makes a transaction to be declined. As a result, PSPs can only solve this complexity through real-time experimentation. A typical case are subscription payments: 9% of subscription invoices fail at the first attempt. While it may happen because the customer truly can’t pay the invoice, it frequently can be solved by retrying the invoice at a different time. That’s because risk appetite from banks varies by day, time, and country, which often mismatches when the PSP will make the charge or the merchant’s time zone vs. bank time zone (e.g., Microsoft US invoicing a client in Brazil). Modern PSPs can smartly retry invoices based on the related issuer bank risk models to increase approval chances – for example, it may be that the customers from a certain country are typically paid at the end of the month, so it can be helpful to try again in the last day of the month. In other cases, a solution might be retrying at times of the day when the bank is more open to approving recurring transactions. 41% of those failed invoices can be recovered with a smart retry technology⁶.

  This is where speed of adaptation / iteration / launching is especially important: Share-gainer PSPs often adapt quicker to new regulations and are seen as “launch partners”. A great example of a good adaptation move was Adyen launching a Dynamic 3D Secure product globally in just two months. It also involves being able to quickly release patches on Visa / Mastercard updates (such as new V/MA fees introduced every 6 months⁷, new fraud rules for certain types of transactions, new rules of what to do with free trial customers, new rules around chargebacks for a certain region, etc.) – there is always a new update from a certain scheme or issuer that can drastically impact the merchant’s authorization rates. Those PSPs that can advise and test tactics around a changing landscape are the ones who can sustain an excellent service since most payment teams can’t keep up to date with increasing complexity – and even when they try, they might not be reacting the best way possible to a new rule. It is better to handle it over PSPs as they see way more transactions in way more regions and know how schemes and banks work, so they tend to have better ideas on how to navigate. That is obviously valid for market launches and payment method launches as well. PSPs with the best track record of quickly launching (with quality and full feature coverage) capabilities in a new market and new payment methods are the ones viewed as “future-proof” providers.

• Complexity of transaction request message: A transaction request is like a file that has information such as transaction amount, merchant ID, issuer ID, region ID, rail ID, time, etc. The problem is that those messages are built with highly variable ID storage methods and templates, which vary by issuer. The bottom line is that each message has c.4 million possible combinations of telling the same thing, but just a handful of those will be accepted by the issuers/schemes. Moreover, retrying ad-eternum in those cases is not a good idea, as too many retries can be recognized as potentially fraudulent transactions by the schemes or the banks, which may lead to potential fines for the PSPs or the merchant. Modern PSPs are applying advanced machine-learning algorithms to optimize those tests and maximize the chances of approval with the least risk involved in the process.

• Shopper’s account status within issuers’ databases: Changes in billing addresses and card expirations are common reasons why an acquirer may have trouble double-checking its information with the bank - as banks often lag in updating that info - which ultimately leads to declines. For context, 3% of cards expire monthly, but only 38% of checkouts provide real-time card validation⁸. Seemingly an easy task, updating account information is a considerable source of error as most banks fail to keep their records updated. Even more, they may issue error codes pointing to problems like “do not honor” or “insufficient funds” in spots where the real problem was that the account was just not updated or the card was expired. As a result, “Do not honor” codes can be resolved c.40% of the time with simple account updates. Modern PSPs can now enable those updates in real-time on behalf of the issuers, often using advanced ML to optimize decision trees, regressions, and other techniques within error types, per bank, per card, per region, and per customer.

• Variability of authentication appetite: Certain banks prefer certain kinds of customer authentications. This means that certain banks will require two-factor authentication ranging from text messages to 3D-Secure⁹ for varying types of transactions, and it is the PSP’s job to optimize that relationship to boost authorization rates. Sometimes, applying the right “challenge” to the customer increases auth rates, even if it increases friction. In some cases, it isn’t.

Other ways of reaping lost dollars outside inefficiency in the payments chain:

Optimizing shopper conversion

Outside the problems mentioned relating to communications between the payment players alongside the value chain, there are also equally critical possible optimizations within the PSP-website/mobile/app layers, which is one way of optimizing shopper conversion.

Conversion is the number of shoppers who add items to their cart versus following through into sales. If done right, conversion optimization with data-informed decisions can be an innovative way of increasing successful transactions as much as technical authorization rate efforts. For context, 20% of customers abandon checkout pages because of too much friction. However, the ways to reduce that friction widely vary. There is no one-size-fits-all answer: merchants and PSPs must look individually and see what happens commonly. There are cases where, in the checkout page, i) if you drop the CVC field, it increases auth rates by as high as 1%, ii) if you put the CVC, auth increases, iii) if you fix error code messages (i.e., show the right ones), auth rates increases. It is also important to optimize checkout experiences in every device, given the rise of mobile and tablets, as it involves showing the right payment methods, screen fit, best button positions etc. Each merchant has a specific checkout flow that must be treated differently. It is common to read cases in which a creative consulting service from the PSP is responsible for 0.5-1.5% incremental auth rate increase alone. As a result, PSPs like Adyen come up with crowdsourced ideas (from the billions of transactions it sees) to help merchants increase conversion, as there is always something to optimize.

Insight from data analytics

Modern PSPs like Adyen can use the data they get from merchants to optimize their exemption decisions by judging the customers’ habits on the platform, testing new features, and troubleshooting errors. That means treating high-value customers differently from low value when it comes to programming when to double authenticate them, when to defer a payment retry, when determined error codes happen, who to offer loyalty points etc. Detailed data can also be used to feed the merchants’ systems of records (CRM, ERP, etc.) to help them designate targeted strategies for each different audience within the customer base. For context, 41% of merchants do not receive any actionable analytics from their payment providers with their payments data. Also, 40% of merchants do not receive transaction data that integrates with their own internal data systems. A good example of payment data analytics is Adyen’s unified/omnichannel commerce platform, which I will elaborate on in a later post.

In the end, the more data insight you have, the more inefficiency you can cut, the more conversion you reap, the more value and ROI you deliver

We’ve seen that the requirements to i) ensure authorization and processing performance, ii) enable global payments, and iii) optimize conversion and do fast launches, all rely on the same pillar: being able to look through data. Data quality is more important than scale for better auth rates¹⁰. In the enterprise space, scale used to be the primary goal of a PSP as it ensures lower pricing – it tackles the cost side of the ROI calculation for the merchant. However, new technologies have been able to get rid of the inefficiencies of low auth rates and cumbersome processes, which lifts successful transactions and lowers the total cost of ownership – which means that it can now strongly tackle the value side of the ROI calculation. That value (data quality) component is what makes legacy providers lose share. This is why Adyen has been able to deliver much better value despite being a tenth the size of its peers in its early days. Here is how:

The authorization rates are ballparks from customer interviews and executives’ comments. Note how authorization rate performance is more important than the take-rate in the ROI calculation. For example, even in the case of a bank charging a 1bp take-rate, if Adyen manages to deliver 3% better auth rates, the ROI is c.14x better because it generated $30mn more revenues even though it charged 20x more – an incremental cost of only $1.9mn. That 1bp practice is not common, it’s just an example of how it works – generally, legacy providers will charge half of Adyen’s price. Customers do realize the value. Interestingly, even in entrenched domestic instances where, for example, Chase might outperform in volumes from ChaseNet (debit scheme) or Chase Cards, Adyen needs to have only 0.5% better auth rates for ROIs to reach c.2x – while charging 4x the price. It might not be there today, but as payments get more complex with the increasing number of payment methods in the US and the increased maturity of its technology in the US, Adyen might get there.

Also interesting in this table is that the ROI illustrated only accounts for pure auth rate uplifts; it doesn’t even consider the cost savings from reduced overhead, increased agility, increased automation, etc. For context, Forrester did a report in 2018 where it estimated that these benefits outside auth rate uplifts could save USD c.2.4mn per year for merchants with USD c.2bn in TPV surveyed.

Lastly, the right end of the table is precisely what happens when you switch from a non-local to a provider with local processing - the authorization rate boost is big as a result of increased payment options, optimization of regulatory technologies (e.g., 3DS), local processing within different countries (skips many fees), FX adaptability, and better authorization rates given a highly complex web of banks / payment methods / payment rails that exist in Europe and APAC, especially.

How the main PSPs are architected

The false positives, decline errors, and conversion problems mentioned earlier can be solved by the payment provider using a large set of features, some of which can be done by gateways, some PayFacs and acquirers, some only by some PayFacs and acquirers, and some only by acquirers.

To be more practical, I will divide the main PSPs into 5 categories: i) the single platforms, ii) the “retrofitted” acquirer PayFacs, iii) the “advanced” gateways, iii) the traditional PayFacs (gateways or acquirers), iv) the “retrofitted” legacy acquirers, v) the legacy acquirers and vi) legacy gateways.

• Single-platform PSPs: Adyen and Checkout

  These platforms in-house the gateway, processor, and acquiring functions (the “triad”). By in-housing every step of the transaction tech stack, these platforms enhance data visibility, minimize data loss (by not depending on 3rd party processors, acquirers, and gateways), and get more autonomy, speed, and control when iterating features and products to optimize the payments experience for its clients. Adyen is the “purest” in this form, as Checkout did buy parts of its tech stack (its processor backbones are from SMS Pay and Opus Payments) in the beginning before applying for its acquiring licenses¹¹. Checkout’s architecture is designed with Adyen’s in mind but with a less-under-control infrastructure, which was built on AWS (vs. Adyen operating its own data centers and private clouds, although using cloud providers for API monitoring and endpoints).

• Semi-verticalized acquirer PayFacs: Stripe, PayPal (Braintree), Mollie, Nuvei.

  These companies were traditional PayFacs, that later verticalized the acquirer function and built a processor optimization back-end to communicate with 3rd party payments processors (thus, are “retrofits”), with varying levels of optimization/verticalization depending on the player.

  • Stripe has its own gateway, front-end and middleware processing capabilities with direct credit-card acquiring authorization licenses. Outsources back-end processing services to Chase and First Data but has been increasingly verticalizing its processing functions (ditched most of FD services in 2021). API-based services & products.

  • Braintree started as a gateway, with a very well-regarded vaulting product and a simpler interface. Full stack volumes started later right before PayPal acquisition, but the platform relied on only one bank, with no product optimizations onto the acquirer processor. Until some time ago, even Braintree’s powered PayPal/Venmo checkouts would require the user to pop in and out of the website – a bad experience. In the last 2-3 years, Braintree has updated its offering by improving its full-stack processing, particularly fortifying its orchestration services. Now most of its volumes are full-stack (>80%), with most of it being orchestration (routing) volumes. It still relies on banks, but now it can route volumes across many acquirers – which is a great improvement for its international offering compared to the previous product. On international also, it has greatly expanded APMs and countries. It also improved reconciliation, treasury, and analytics. Braintree’s checkout process is now fully native with a full in-app experience. That’s helped with notable wins of very big customers who look for cheap orchestration volumes (i.e., “unbranded processing”) in the US (e.g., Spotify, Airbnb, Uber, TikTok) while leveraging Braintree’s classical better pricing for PayPal button transactions.

• Traditional PayFacs: Shopify, Lightspeed, Toast, Wix, MercadoPago, Neobanks (e.g., Revolut), Block

  • Those companies outsource the processing & acquiring’s technical and regulatory duties, often enjoying a revenue share model with their sponsor PSPs (e.g., Lightspeed uses Worldpay and Stripe for North America and Adyen for Europe; Toast¹² uses Worldpay mostly).

• “Retrofitted” legacy acquirers: Worldpay (FIS), First Data (FISV), Global Payments (GPN), Worldline (WL)

  • The retrofitted players here are generally financial institutions with roots from the ‘80s-90s, formed by intense M&A, but who significantly re-engineered its tech stacks in the past 5-7 years. The most advanced reengineering endeavor was made by Worldpay, which reportedly spent over $1B to revamp its processing tech stack to better serve its customers and compete with modern players like Adyen.

  • Worldpay: Multiple platforms, multiple companies; outsources many value-added services like secure card storage, PCI compliance validation, encryption, reporting, reconciliation, customer support, mobile payments, fraud services; uses multiple gateways and middleware layers (Mercury, Paymetric, Litle&Co, Vantiv etc.)

    First Data: Multiple platforms and multiple companies (based on JV with Wells Fargo Merchant Services Solutions); outsources many value-added services like secure card storage, PCI compliance validation, encryption, reporting, reconciliation, customer support, mobile payments, fraud services; uses multiple gateways (Payeezy, CardPointe, Clover Gateway etc.), and middleware layers (e.g., Rapid Connect).

• Legacy acquirers: 99% of the banks, e.g., JPM Chase, HSBC, Barclays, BNP Paribas, Citi, Nexi

  • The legacy acquirers are mostly banks, who traditionally held the acquiring licenses since the advent of credit card acquiring. From my diligence, most of the banks don’t try to significantly reengineer their acquiring/processing tech stacks for several reasons (e.g., high cost, not worth the revenue dollars, cultural incompatibility, etc.). An exception is JPM Chase, who started its reengineering 3 years ago and is expected to finish it by 2026 (the Helix platform), with reengineering expenses of over $700M per year.

  • JPM Chase: Multiple platforms, multiple companies, multiple integrations for global payments, M&A-wrapped technology stack; outsources many value-added services like secure card storage, PCI compliance validation, encryption, reporting, reconciliation, customer support, mobile payments, fraud services; uses multiple gateways and middleware layers.

• Advanced gateways / orchestrators: PayU, dLocal, EBANX, Payoneer

  • These platforms are the orchestration providers, whose main advantages are a highly effective acquirer routing technology, a vast integration capability with APMs, and cross-border specific offerings, such as FX services and tax handling (especially if focused on emerging markets).

• Legacy gateways: CyberSource (Visa), Ingenico, local banks

  • Legacy gateways are mostly banks and standalone M&A-driven companies that haven’t modernized their products and rely on distribution and bundle offerings to get volume and clients.

What large Enterprise customers care about

• Holistic & global payment method acceptance: large companies require all the main payment methods whenever their customers ask for it. With increasing number of payment methods around the world (e.g., buy-now-pay-later, deferred credit, wallets etc.), there is no room for large enterprises to stick with PSPs that are slow to adopt new methods or to stick with credit-card only PSPs in regions that customers are increasingly paying without cards. In fact, 50% of all online transactions are made with alternative payment methods. 59% of global online payments do not happen on cards. Accepting payments globally used to be a common request mostly for European enterprises, in which countries’ economies are highly linked to each other. However, this trend has been accelerating as nearly every business can now find demand globally. Even in countries with domestic-heavy markets such as US and Brazil, the % of companies selling globally is rising steadily. A global offering also includes multi-currency support, as enterprises that sell globally often have a hard time on FX fees with unnecessary extra-hop conversions¹³. Modern PSPs are gaining share from smaller/local banks, local gateways, and even big legacy acquirers (e.g., Chase, Barclays) largely on the back of simply offering APM integrations and enabling global local acquiring. I think this low-hanging fruit opportunity is probably going to last another 3-to-5-year cycle as still only 37% of the merchants currently offer a full range of alternative payment methods. Longer term, APM integrations and country reach per se are set to be commoditized.

• Payment acceptance performance: this is a stark difference to SME needs – as enterprises grow volumes, they start to really care about payment authorization rates and conversion. Platforms that can deliver higher authorization rates and conversion for the lower price, deliver the best value. Improvements in auth rates can range from +2-15%. A 2% lift for a SME with 1mn TPV means only 20k in savings per year, whereas a 2% lift for big companies means $20mn+. Improvements in conversion rates (e.g., converting a high LTV shopper because you added his preferred payment method) often mean new customers for an entire lifetime value. With the rise of modern PSPs that can solve these problems, merchants are increasingly seeing payments as a revenue driver rather than a cost center. This is a durable advantage that is likely going to drive PSP competition in the long-term.

• Fraud solutions: unlike SMEs, Enterprise merchants care a lot about fraud. Fraud rates as % of total transactions for a merchant sits in the 0.1-2.0% range. Fraud management is a high-profile problem because the merchant often transfers the liability to schemes and banks (attribution varies by region, business, and regulation), who can fine merchants or lift interchange prices should the merchant mismanages its fraud rates (merchants generally pay 1-2% of revenues in fines every year).

• Granular reporting: PSPs that can elaborate detailed dashboards and reconciliation reports, with detailed info around payment data have an edge over those who don’t. Enterprises that work with legacy providers tend to employ big teams and spend excessive working hours to reconciliate and double check payment info across the company.

• Chargeback support: ability to provide detailed chargeback reporting, automate disputes and consulting around reducing chargeback incidence with data. Chargebacks typically amount 0.1-1.0% of online transactions but can go as high as 2-5% on business models like food delivery and ridesharing, for example.

• Transparent pricing: This is essentially not hiding interchange and scheme fees in the markup and correctly estimating them for the merchant. Checkout.com did a survey in 2019 with 1,500 enterprises, and 48% of them were not receiving a detailed breakdown of their payment costs from the providers. This is especially bad for global companies that enjoy different fees in different regions, which are often adjusted up/down over time. These fees are driven by variables such as the card level (platinum/commercial), country of merchant and the issuer, merchant segment, transaction type (online/POS payments), etc. As said before, V/MA introduce new fee rules every 6 months. So, being able to quickly assess the impact of these fees on a transaction level needs to be done as quickly as possible in order to update the scheme fee estimation, communicate to the merchants impacted, and adjust pricing of the scheme fee components to limit the impact on the merchant’s bottom line. This can only be done when you have a processing platform that provides high-quality, transaction level data and can help clients understand the impact of a new scheme fee.

• Vertical-specific products: refers mostly to the omnichannel, marketplace, subscription and some hospitality business models (“Platforms” model), which requires specific features, such as integrated physical processing, onboarding/KYC, billings, and split payments.

Conclusion: Adyen leads as the “purest” provider, which basically explains why it's the one who’s able to deliver more value along the payments chain.

Architecture replication is possible, but it’s been proven difficult empirically over the decades. In the B2B software world, this is more visible, where we can see that the non-cloud-native companies have a hard time reengineering themselves - often adhering to “cloud retrofits” that don’t deliver the same value.

1. eBay, for example, has always been a pure PayFac under PayPal’s umbrella. It changed when it switched to a MoR model under Adyen in 2018. PayPal, for example, is the MoR for small merchants, but for large merchants like Overstock and American Airlines, they are the PayFac, and that merchant is on the shopper’s statement.

2. There are >500 different payment methods worldwide.

3. Auth rate is the percentage of shoppers successfully paying when they click the “buy” button after entering payment credentials.

4. False declines – those where the shopper is legitimate and using their own, legitimate payment credentials – led to $331 billion in lost revenue in 2018, according to a study by 451 Research. Perhaps even more painful is that 40 percent of those shoppers won’t return after the initial false decline, per a McKinsey study.

5. Mastercard, 2020

6. Sunil Dixit, Adyen EVP at The Paypers Webinar, 2020.

7. Scheme fees are increasingly being used to drive innovation and spur the adoption of new technology by parties in the payments ecosystem. The Mastercard non-token based Card-on-File recurring transaction fee and the Visa non-EMV terminal capability fee are examples of these, where an acquirer needs to work closely together with merchants to help them adopt new functionalities and technology to avoid financial penalties.

8. Checkout.com, 2020.

9. 3D Secure is an authentication protocol that provides an additional layer of verification for card-not-present (CNP) transactions. Modern PSPs can apply Dynamic 3D Secure to transactions with the help of ML, as 3D Secure puts friction in the checkout process (which can be good for the conversion of some shoppers, but bad for others - the payments team will judge it).

10. Stripe at https://vimeo.com/250373607

11. From people with in-depth knowledge of Checkout’s tech stack. Checkout also bought part of its data analytics & orchestration tech from ProcessOut, and then its identity verification technology (KYC for Platforms) from Ubble.ai – all which Adyen in-housed its own.

12. Toast charges c.250bps gross take-rate to restaurants – of which it pays c.140bps of interchange fees, c.15bps to schemes, and c.40bps to Worldpay, keeping 55bps net yield.

13. Only 28% of mid-market/enterprise merchants receive their preferred settlement currency (Checkout.com, 2019). If a PSP does not support the merchant’s settlement currency, merchants must pay 2-3% conversion rates to have the account balance in their native currency. That can essentially kill their margins, so they either do not give the option to pay with other currencies or they pass the extra cost to the consumer. In the end, having no currency support also often decreases conversion rates: per HK Express, 25% of customers would abandon a travel booking at checkout if their local currency is not available.