Introduction

Our previous blog highlights the payments challenges Vertical SaaS businesses face while onboarding large clients, such as complex integrations with multiple processors, the need for modular payment workflows, and adapting to evolving regulations.

We also discussed the criticality of pre-built integrations, modular payment workflows, and scalable solutions as key strategies to address these issues.

In this blog post we shall cover in detail, the second important aspect of Embedded Payments 2.0 - solving for multi-processor setup and payment routing.

Why would Vertical SaaS business have to offer multi-payment processor setup to clients?

Global expansion

Global businesses need local payment processing capability to improve payment success rates by reducing transaction declines due to cross-border issues. In addition to this, local acquirers have better insights into regional payment preferences, regulations, and fraud detection, helping businesses reduce costs related to currency conversion and cross border fees.

So if a global business is generating significant revenues from a few critical countries, it is quite natural for the business to have local acquirers in such countries.

Nature of business

For specific unregulated or high-risk sectors such as gaming products or charity donations, it might happen that working with a single processor could be too risky from a business continuity standpoint. Hence multi-processor setup is a necessity.

Reducing cost of processing

When payments are routed within the same bank acquirer (which issued the card to the consumer), fees associated with the network scheme (visa/ mastercard) can be avoided. Typically for a 100 USD purchase, the network fee will be approximately 0.25 USD.

Onus routing, also reduces the transaction latency and decreases the likelihood of declines, as the processing stays within a familiar banking system. Hence, to leverage such benefits, enterprise businesses would tend to enter into payment processing partnerships with those specific banks whose cards are very dominant in the payment method mix.

Sample Routing Rule:

Managing volume commitment to multiple payment partners

Businesses would enter into multiple contracts with payment partners to maintain favorable pricing agreements, meet minimum volume commitments, and diversify processing risks.

By spreading transactions across different partners, businesses can optimize costs, maintain strong relationships with various payment providers, and ensure continuous payment processing even if one partner faces issues.

Sample Routing Rule:

Poor authorization rates with single payment processor

Authorization rates can fluctuate due to various reasons - technical downtimes, timeouts, rate limits, fraud declines. A multi-processor setup is a way to enable the business to test a payment processor's performance and optimize payment auth rates.

Solutions

Allow businesses to self-configure processors

The Vertical SaaS platform shall provide businesses with the ability to configure multiple payment profiles and configure payment processor credentials against such profiles. A business may have different payment profiles basis their use case to differentiate payment processors with respect to:

• Sales channels such as App, Website and Direct sales
• Multiple product offerings or product brands
• Business segments - B2B business and B2C business and many more such use cases.

And the Vertical SaaS platform should also provide a dashboard interface enabling businesses to self create payment profiles and configure processors against each profile.

Rule based routing and volume based routing

Payment routing rules should be super versatile and intuitive for the businesses to create. The rules should be constructible on any payment related dimension.

It may happen that in most such routing requirements, the business may wish to use non-payments related data to pivot a routing logic. Hence, it is important to allow routing rule configuration based on additional metadata passed in the payment request to extend the coverage.

Uplift authorization rates for businesses through smart retry workflows

In a multi-processor setup, there are two types of retry scenarios which the business might benefit out of. Such scenarios are applicable when the payment fails due to network timeouts, technical declines, fraud declines and other generic decline errors from the primary processor.

Scenario 1: Retry with the same payment processor with an alternative payment request data.

Scenario 2: Retry with a different payment processor with same payment request

Retry with a different payment processor with the same payment request data. In case of a technical decline with the primary processor the payment can be retried with the fallback processor. As shown below, when multi-processor setup is enabled a payment failed with the main processor (Bank of America) could be retried with Stripe.

While performing such retries it is quite critical to execute retries for the relevant error codes passed by the cards scheme. Here are some of the error code categories and corresponding retry strategies.

In a Network Tokenized transaction, the underlying card network actually detokenizes the network token, and sends the Clear PAN number along with more metadata (including fraud score) to the issuer for processing. Hence it is possible that some issuers become overly cautious, and start rejecting transaction with

• Using the fraud scores to reject the transactions
• Avoid the path of liability shift at any cost (in spite of card schemes clearly mentioning that the additional metadata does not signify authentication)

Hence, as shown below depending on the type of failure, the payment will have to be retried with two strategies (a) detokenize and retry with the same processor, or (b) retry the same payment request with an alternate processor.

In the next blog post we will talk about the criticality of managing cost observability for Vertical SaaS businesses.