SMART ROUTING IN CARDS PROCESSING

To process cards (Credit, Debit, Pre-Paid, Wallet etc.) transaction, it might seem reasonable for a merchant to connect to one Payment Service Provider (PSP)1, since connecting to multiple PSPs pose a lot of integration, architecture, technical challenges and at the same time is costly and time-consuming for the merchant. For a small merchant or for a merchant who is trying to foray into a particular geography it makes sense to opt for a single full-service PSP. A single full-service PSP can quickly integrate with the merchant’s legacy system thereby reducing the time to market and at the same time retains the data ownership (Card and Transaction details) thereby freeing the merchant from the onerous and costly task of PCI DSS (Payment Card Industry Data Security Standard)2 compliance. However, as the merchant scales it is economically beneficial to connect to multiple PSPs which offers the merchant more flexibility and power to negotiate on the processing fees.

Fig 1 depicts two authorization (Request and Response) flows. The top flow depicts a single Full-Service PSP arrangement, and the bottom one depicts Multi PSPs. To ensure payment acceptance and processing a merchant needs to connect to at least one PSP which consumes the request message from the merchant POS or Payment Gateway, validates it and routes it to upstream player (Acquiring Bank) which in turn routes the request payload to network providers (Visa, Mastercard) and finally to the card issuer. Despite obvious benefits of a single full-service PSP, there are several challenges that a merchant face in the single PSP arrangement. Some of them are listed below.

1.?????? Merchant’s payments processing could be disrupted if the PSP is unavailable resulting in bad customer experience and lost revenue

?2.?????? If the PSP is not available, then to address the issue of poor customer experience and lost sale, offline payment approval threshold are temporarily increased by a substantial amount (say from 20 USD to 100 USD) making the merchant liable to payment fraud at those terminals

?3.?????? To leverage vertical integration strategy, the PSPs often provide terminals (Pin Entry Device or PED3) to merchant. As a result, the card and transaction details are shared and stored in the PSP environment bypassing the merchant and the merchant has no visibility on payment processing issues at real-time. This creates significant challenge in troubleshooting and mitigating any card present payment issue at real-time.

?4.?????? It takes ~12 months to get replacement device from a PSP. As a result, many front-end locations work with broken devices which adds to security and fraud vulnerabilities

?5.?????? PED devices are costly and sometimes the PSPs don’t support any other device manufacturer resulting in downward pressure on operating margin and vendor lock

?6.?????? The PEDs supported by the PSP, don’t support proprietary use cases such as -

• Collecting customer signature
• Accepting rewards/loyalty points
• Applying for co-branded credit cards at POS

Multi PSP arrangement can address some of the challenges mentioned above. The benefits are listed below.

1.?????? When the primary PSP is unavailable, transactions are redirected to the secondary. So Multi PSP arrangement ensure a failover strategy

?2.?????? Merchant can negotiate for a better rate with the PSPs

?3.?????? Geo Location of the customer can be derived from IP address of or from shipping address. Based on the geo location, the transaction can be routed to the PSP who has local branch in the customer country. This would reduce the Cross-border fees (charged when the customer and PSP are in different countries)

?4.?????? Different payment methods have different fees associated to them. For e.g. a direct debit or bank transfer, is less costly than a credit card. Merchants should be able to intelligently route the transactions to PSPs which can handle a transaction most optimally

?5.?????? Merchant can negotiate rates, and can route transactions to PSPs based on the volume discount agreement

?6.?????? Based on historical authorization rate and transaction nature, merchant can route a transaction to the PSP most likely to successfully complete the process.

?7.?????? Smart routing engine can evaluate the risk profile of the transactions (based on Product Type or Industry Type such as Gaming or Casino) and route the transaction to the PSP that specializes in high-risk transactions increasing the probability of approval

?8.?????? Merchant can accept wide range of payment methods (cards, digital wallets, etc.)

?9.?????? Access to extensive APIs and SDKs, help merchant to embed their services across device types and platforms

10.?? Below are three sample Quantitative impact which multi-PSP has handle

a.?????? ?A single PSP typically charges a flat fee (2.9% + $0.30) for all transactions (both credit and debit). However, the debit cards processing costs are substantially lower (0.05% + 0.11) than that of credit cards and the merchant may be charged more than what it should be charged for a debit transaction. Let’s say that there are 1000 debit card transactions totaling 100K USD. Average transaction value is 100 USD. The merchant is charged [(2.9% 100) + 0.30] or 3.2 USD per transaction or 3,200 USD for 100 transactions. However, the merchant should have been charged [(.05% 100) +0.11] or 0.16 USD per transaction or 160 USD for 100 transactions. Therefore, for a 100K USD debit card sale a merchant is over charged by ~ 3,040 USD (3% impact on Gross Margin) in a single PSP environment

b.?????? For a Small and Medium Scale Enterprise, processing 1M USD per year, system down time of 24 hours can lead to lost sale of ~ 2,800 (~ 0.28% impact on Gross Margin) for the merchant. 1M USD per year implies 114 USD processed per hour (1,000,000 / 365 24) and if the PSP is down for only 24 hours in a year, then the merchant might lose 114 24 or ~ 2,740 USD.

c.?????? ?According to PYMNTS.com , 11% of the attempted authorization request end in a decline. Imagine a large hotel chain processing 160K transactions per day or a 20M USD per day. The average ticket size is 125 USD, and 11% lost sale would imply a potential loss of (11% 160,000 125) USD or 2.2M USD per day.

From the above points it is evident that multi-PSP arrangement is going to benefit a merchant from many aspects. However, to ensure that the Multi PSP scenario is optimally orchestrated, the merchant must build a smart decision engine that directs each transaction to the appropriate processor. This is known as smart routing, or intelligent routing or dynamic routing. To build a successful Multi PSP environment, a merchant must implement smart routing engine on the top payment gateway. Routing to multi-PSP at run time ensures that the best payment processor is selected for each transaction maximizing the chance of success and minimizing the cost of processing.? Based on the properties of a transaction, the smart routing engine, built on the top a Payment Gateway, decides which PSP to route a particular transaction.? Some of the rules (not an exclusive set) are as follows.

1.?????? Identify the issuer country code based on the card BIN range and chose a PSP with a local presence in that country. For example, if a smart routing engine has an option to route a transaction to Stripe or Adyen and the cardholder bank is based in Netherlands or any other EU country then the smart routing engine might decide to route the transaction to Adyen. This is done to get better processing rate and higher chance of approval.

2.?????? If the cost of processing is less for a particular PSP, then route to that PSP. For example – if JPMC Helix is a processor then the smart routing engine might route Visa Chase card transactions to JPMC Helix and all other cards transaction to other PSPs

3.?????? Incremental Authorization4 for Hotel business must be routed to the PSP that approved the initial authorization. Any deviation to this rule may lead to identify the incremental Authorization transaction as a ‘force capture’ and the network players (Acquiring Bank, Visa, Mastercard) might blacklist the merchant

4.?????? Capture5 or Linked Refund6 must be routed to the PSP that approved the initial authorization. Any deviation to this rule may lead to identify the incremental authorization transaction as a ‘force capture’ and the network players (Acquiring Bank, Visa, Mastercard) might blacklist the merchant

5.?????? When a transaction fails for what may be a soft reason (e.g., the card has expired, or the account is at its credit limit), the smart engine must retry after a couple of days

6.?????? Store and forward or SAF7 requires a special discussion when it comes to smart routing. At a high level, if the Smart Engine can’t go online due to loss of connectivity, then it stores the request payload in a SAF file, and an offline auth approval response is generated. It then tries to send the auth requests to the PSP when the connection is up. The offline auth code needs to be reconciled with the online auth response code to ensure the robustness of the system.

Consider a merchant with a Payment Gateway, 2 PSPs and a Token Service Provider. Based on the 4 entities, 16 combinations are possible (each entity can have 2 states such as ‘Available’ and ‘Offline’ and total possible combinations is equal to 24 or 16) which can be reduced to the following simplified routing table

There are a few nuances when it comes to SAF processing. Some of them are discussed below -

·?????? DCC (Dynamic Currency Conversion)8 Authorization

o?? Payment Gateway calls the Forex Rate provider such as FexCo to get the currency conversion rate and the converted amount and locks the FX rate with the FX provider based on the cardholder’s consent

o?? Post offline authorization, payment gateway persists the auth request/response data with the normal auth fields plus DCC flag, base currency code, FX currency code, FX rate / conversion rate, total converted amount, Order ID in the database

o?? For offline auth stand-in there is a threshold on the auth amount. If the auth amount is greater than the threshold then the auth should be declined

·?????? DCC (Dynamic Currency Conversion) Refund

o?? Refund is processed when the POS can’t connect based on the above table. If the original transaction is done with DCC, then the refund transaction needs to perform rate lookup for the FX currency

o?? Refund can either be against an offline auth using the device generated offline auth ID (same as Linked Refund) or can be an Adhoc Refund where a card is captured to process the refund against it and when the connection is resumed, Offline refund requests will be forwarded to PSP for processing

o?? Payment Gateway will store the offline flag, base currency code, FX currency code in base currency and the DCC flag, refund request and response code, offline flag and offline auth ID

·?????? Retry Mechanism

o?? After the connectivity is restored, smart engine will send the transaction request to PSP either in batch or single transaction mode

o?? It is mandatory to validate the card type every time the retry scenario happens for a new payment process in an offline scenario

o?? For every retry DCC check needs to be processed if it is an international card

Some Points to consider while implementing SAF -

??????? Decide on the threshold limit (Auth and Refund) for offline stand-in during a partial authorization

??????? How will offline auth stand-in be supported for incremental auth, split tender, partial auth etc.

??????? Is offline auth stand-in/auth refund applicable for all Lines of Businesses? For some risky Merchant Category Code or MCC9 such as casino or gaming offline auth may not be allowed

??????? How many times smart engine should retry before going for offline auth?

??????? Is offline payment supported by PED (EMV scenario) or POS (keyed in scenario) or both?

??????? For a hotel business, if during check out, the gateway that has been used so far is unavailable, then a retry loop will be triggered till the gateway is restored. Check out will be suspended.

Despite the benefits described above, a multi-PSP arrangement poses many challenges to a merchant.? The most important challenge is payment security. The question is which entity should own the customer data (PII in nature)? Is it the Merchant or the PSPs? If the merchant owns the customer data, then it needs to go through a PCI DSS compliance process which is time consuming, costly and not 100% full proof. If the PSP owns the data, then the smart routing process will not be effective.

One option for the merchant could be to partner with Token Servicer Provider (TSP)10 which can generate, store, verify, map token to card number or primary account number (PAN)11 and provision token as and when needed.? The TSPs can undergo the PCI process and store the PAN and the merchant can just store the token and use the token to decide which PSP to route a particular transaction. This can keep the merchant’s payment system out of PCI-DSS scope, while maintaining the flexibility to submit future transactions to substantially any PSP partner.

Merchant delivers all credit card information directly to the TSP’s vault (a PCI-compliant, facility), and receives in return a token. This token is then used to instruct the smart routing engine to deliver the card holder information to a particular PSP to process the payment. In this way, the merchant can route payment transactions to any number of PSPs, without bringing the PII into its system. Meanwhile, they retain ownership of the tokens necessary to route transactions to any processor with whom they have a business relationship.

Fig 2 represents a proposed functional flow in a multi-PSP arrangement with a smart engine and Token Vault. Payment Gateway receives the transactional data from different merchant LOBs. It validates, enriches and creates a standardized and canonical data payload and routes to Smart Engine the tokenized version of the transaction. Smart Engine (which is owned by the Token Service Provider) can then detokenize and route to PSP.

How Can Wipro Help?

With 25+ years of legacy, Wipro is positioned as a key service and solution provider in the cards and payment ecosystem. Wipro offers end-to-end platform build and implementation services across the payments value chain starting from consulting, engineering, architecting, designing, prototyping, developing, validating as well helping in creating and migrating to a next generation payment platform. Wipro has acquired Capco, DesignIT and Holmes who are pioneers in providing payment IT services to the global customers. This has strengthened Wipro’s digital consultancy specializing in driving digital cards and payments transformation.

Our Cards and Payments Practice specializes in implementation of payment hub and payment engine solutions from a wide variety of vendors - Finastra, Fiserv, ACI, IBM and others. We offer advisory services such as payments capability assessment, payments modernization related roadmap development. across the value chain for Issuing Banks, Merchant/Acquiring Banks, Networks, Processors and Large Merchants. Wipro offers Business Consulting (DeNovo Program Build Out, Product Ideation and Marketing, Risk and Fraud Management, Cardholder Support/Service Centre) and Technology consulting (Application Modernization, Product Selection and Development, Application Management & Enhancements, Digital Channel Design & Implementation) with latest trends product support like BNPL, Virtual cards etc in Time & Materials Engagements, Output Based Engagements and Staff Augmentation – Operations & Technology with Agile, Waterfall and Scaled Agile methodologies. We have large pool of cards and payment resources for channel redesign, surround system integration, data migration, testing - functional and automation testing and a pool of experienced thought leaders on the emerging industry requirements like ISO20022, Cross Border Payments, RTP, Open Banking, Blockchain, CBDC, New cards product launch including Retail/ Commercial Cards, PLCC, Co-branded, BNPL, CLICKTOPAY and Digital Wallets.? They are complemented with strong cards and payments engineering talent with platform expertise on V+, TS2, TS1, PRIME, FDR, BASE24, BAY4, COTEX and other in-housed cards platforms and peripheral products like TRIAD, FALCON etc.

Glossary

1 A payment service provider, or PSP, is a third-party company that lets businesses securely accept credit card, debit card and digital wallet payments online and in person without having to open a dedicated merchant account

2 PCI Security Standards are technical and operational requirements set by the PCI Security Standards Council (PCI SSC) to protect cardholder data. The standards apply to all entities that store, process or transmit cardholder data – with requirements for software developers and manufacturers of applications and devices used in those transactions

3 A PED is an electronic device used in a debit, credit, or smart card-based transaction to accept and encrypt the cardholder's personal identification number

4 If a credit card is authorized at a certain amount, and the transaction is edited before settlement to a higher amount, the card must be re-authorized at the new amount, or else the customer's bank will reject the transaction at batch settlement. For example, if a customer checks in a hotel and authorizes for 100 USD (per day room rate) and then decides to stay to one additional day then an incremental Auth of 100 USD should be sent to the Issuer before the merchant aims to settle the 200 USD.

5 Capture is the process by which the transaction is completed, and funds are withdrawn from the customer account, processed and transferred to the merchant account—moving the transaction status from pending to complete

6 A linked refund is a refund that is associated with and linked to an original transaction. This type of refund is typically processed by referencing the original transaction and using the same payment information from the original transaction to issue the refund. The main benefit of a linked refund is that it is faster and easier to process compared to a standalone refund since the payment information is already on file and does not need to be re-entered

7 Store and Forward capability lets a merchant process transaction offline when there is an outage or connectivity is known to be unreliable.

8 Dynamic currency conversion (DCC) is a financial service used in?international transactions , when a customer from one country makes a?credit or debit card purchase ?in another. DCC allows the transaction to be processed at the point of sale in the currency of the cardholder’s home country.?

9 A merchant category code is?a four-digit number used by credit card companies to classify businesses. A business MCC indicates the types of services or goods being sold to customers

10 A token service provider (TSP) is?an entity that generates, stores, verifies, and manages payment tokens for registered token requestors

11 A primary account number (PAN), also known as a payment card number, is a unique identifier for a cardholder's account on a payment card

?

About the Author –

Saurav has more than 18 years of experience as a transformational leader leveraging technologies, strategies, and relationships to develop innovative solutions for large corporations, maximizing performance, quality, and results. He is a SME in payments process transformation and product development. He holds a MS in Business Analytics from NYU Stern and an MBA in Marketing from AIM, Manila. Saurav is a certified Project Management Professional (PMP), a Scaled Agile Practitioner, and a certified Financial Risk Manager (FRM).? He resides in New Jersey and can be reached at [email protected]