Boosting Transaction Approval Rates: A Guide to The Tools on The Market

The Theory: One common reason for which a good customer’s transaction is declined is use of an expired or deactivated card credential. This is a particular challenge for Merchant Initiated Transactions (think about your streaming service subscription, or bill payments, where funds are automatically deducted from your account) because the customer isn’t always present at the time of transaction. Historically, merchants have relied on systems that update these credentials in batches. The typical process is as follows:²

• The merchant collates their shoppers’ card details
• The merchant sends a batch request file to the party providing the Batch Account Updater (BAU)
• The BAU service returns a batch response file with updated card details, sourced from the card networks
• The merchant updates the card details in their system

BAUs can help eliminate the issue of expired card declines, particularly with predictable billing cycles. However, the response to a batch file may take multiple days during which many good transactions can fail. This led to the development of real-time account updater (RTAU) solutions which compare customer credentials with the account updater database during the transaction flow to minimize the likelihood of a mismatch.

Considerations for Merchants:

• Balancing the costs associated with BAU and RTAU solutions with the potential reduction in falsely declined transactions
• Understanding whether BAU or RTAU is most appropriate given each merchants’ unique business needs, particularly since some solutions have the potential to incorporate RTAU technology, such as network tokenization

The Theory: Say you are a large merchant with a sophisticated approach to fraud prevention. You have a customer, Callum, who has shopped with you all his life. He is a long-standing member of your loyalty program, he orders from you once a month, and he has recently contacted you to say he is moving house and to update his address. The next time he tries to make a legitimate purchase from your online store, he is declined due to suspected fraud – perhaps due to an incongruence between his billing address and new shipping address. In this instance, you had much more data on Callum than the issuing bank, and likely would have (correctly) approved his transaction.

A ‘trusted MID’ may allow you to surmount this challenge. It involves working with an issuer to create a Merchant ID that is used only for transactions that a merchant has deemed legitimate. Trusting that the merchant can accurately make this assessment, the issuer may relax its fraud rules on those transactions and approve a higher percentage of the volume.

Key Considerations for Merchants:

• Trusted MID solutions can be complex to set up; direct connections are uncommon and often have specific requirements around historic fraud performance, technological capabilities, and relationships with issuing banks or third parties
• Performance can vary between issuing partners and merchants require granular data to conduct ongoing impact analysis
• Trusted MIDs may be mutually exclusive with other fraud solutions

The Theory: 3D Secure is a security protocol that sits with EMVCo. It is intended to add an extra layer of verification for online payments and therefore increase the likelihood of success for good transactions. There are three main ‘flows’ that a 3D Secure transaction may go through:

• Challenge Flow: The traditional 3DS flow. The merchant sends a request for 3DS, via the card acquirer and network, to the issuing bank which then prompts the cardholder for additional information, for example via text or through a pop-up window.³ The issuer uses this additional data to authenticate the customer and sends a confirmation message back through the flow. Typically, at this point the issuer becomes liable for chargebacks related to fraud for that transaction.
• Frictionless Flow: Version 2 of 3D Secure introduced a ‘frictionless’ flow. It operates similarly to the challenge flow, except the issuer does not prompt the user for additional information. This is possible when additional data points provided at the time of transaction cause the issuer to deem the transaction sufficiently low risk that they do not ‘challenge’ the transaction.
• Data-Only Flow: With specific networks and geographies, it may be possible to send the additional data associated with 3D Secure without asking the issuer to provide an authentication response. In this case, the networks handle the authentication request themselves, including their own risk data in the authorization message that is sent to the issuer.

Key Considerations for Merchants:

• The greater friction associated with a challenge 3DS flow may lead to cart abandonment
• Fees for the use or avoidance of 3DS differ by geography

The Theory: Network tokens are one way for merchants to avoid storing sensitive PAN data on their systems, by replacing this data with a non-sensitive ‘token’. With this type of token, the payment network acts as the Token Service Provider and manages the Token Vault which stores the sensitive card data.

Unlike other types of tokens, which are typically decrypted before being sent to the network, network tokenized credentials remain tokenized until they reach the issuing bank. This is claimed to reduce the likelihood of fraud, increase approval rates, and improve lifecycle management.

Key Considerations for Merchants:

• Network tokens may affect merchants’ ability to leverage other solutions such as PINless debit
• Merchants don’t always have control over whether networks tokens are introduced into their environments given their usage by digital wallet providers
• Merchants need to ensure that all partners are aware that payments data will be tokenized and solve for any dependencies on PAN data within their systems
• There can be fees or discounts associated with the use of network tokens that differ by market and integration type
• Empirical evidence on the effect of network tokens on approval and fraud rates differs from merchant-to-merchant

Given that declined transactions may be successfully retried, there are a host of industry solutions that aim to retry transactions in different ways:

• Retry with a different provider, for example a ‘fallback’ acquirer
• Retry at a different time, especially for subscription merchants where time of day or month could affect a customer’s availability of funds
• Retry with additional data, such as 3D Secure data points
• ‘Blanket’ retries, which re-submit transactions that have received ‘soft’ declines

Some providers have even launched solutions to optimize the retry process, such as Mastercard’s Authorization Optimizer, which provides a suggested time for reattempt when a card is declined due to insufficient funds.⁴ However, the fee for the provision of this information is charged to merchants on qualifying transactions regardless of whether they use it.⁵

Key Considerations for Merchants:

• There may be fees associated with third-party retry solutions
• Card networks typically charge fees to limit the number of times the same transaction is retried within a given timeframe
• Retries could conflict with other elements of a merchants’ payments strategy, such as velocity rules for fraud detection
• Fallback retry strategies may require additional routing capabilities