The second Payments Services Directive (PSD2)
introduces new rules around Strong Customer Authentication (SCA)
to make payments safer, more secure and protect consumers from fraud. This means most online payments in the UK and EEA will require SCA.
However, the legislation also introduces SCA exemptions that aim to minimise friction when a transaction is low risk.
The goal with transaction optimisation is to understand how issuers are adapting to PSD2
and recommend the route with the highest authorisation success to maximise conversion,
whether the best course of action is to authenticate
a customer using 3D Secure, or
whether you should proceed directly to authorisation,
and possibly which SCA exemption is best suited.
Transaction optimisation and payment fraud both need to be enabled on your account before transaction optimisation can be used.
Please speak to your account manager about enabling these.
Authentication or Authorisation
Authentication provides an extra level of security during checkout, however authenticating customers can sometimes
negatively impact conversion. Some customers may abandon the checkout when presented with a
3D Secure challenge and the 3DS flow is
prone to timeouts or errors.
3D Secure 2 (3DS2) supports frictionless authentication and
SCA exemptions. It also allows over 100 data points to be sent to the issuer, which aims to
improve the customer experience by avoiding disruptive challenges.
Therefore, it is preferable to only authenticate when you are concerned a customer is a fraudster,
or when an issuer is going to enforce authentication anyway. The challenge is knowing whether an issuer
is going to enforce authentication.
You could just attempt to avoid authentication by going directly to authorisation and use an SCA exemption,
but if the issuer does enforce SCA you’ll get a soft decline and have to go back and authenticate the customer,
and then perform a second authorisation. This may be undesirable because each attempt adds additional latency to
the payment process. Furthermore, there may be cases where the customer prefers to be authenticated
and this option has the best chance of success.
Ravelin’s transaction optimisation will optimise your low risk traffic, providing recommendations
for the best chance of transaction success.
Transaction Optimisation flow
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#ececff',
'noteBkgColor': '#fff6de'
}
}
}%%
sequenceDiagram
participant PAYMENT_PAGE as Payment page
participant BACKEND as Merchant backend
participant RAVELIN as Ravelin
participant GATEWAY as Payment Gateway
PAYMENT_PAGE ->> BACKEND: Attempt payment
BACKEND ->> RAVELIN: Request payment fraud and transaction optimisation recommendation
Note over BACKEND,RAVELIN: v2/checkout?score=checkoutPreAuth&transactionOptimisation=true
RAVELIN ->> RAVELIN: Transaction runs through payment fraud and transaction optimisation models
Note over RAVELIN: TRA is performed as part of the payment fraud model
RAVELIN -->> BACKEND: Payment fraud and transaction optimisation recommendations
alt If payment fraud = Prevent then no transaction optimisation recommendation is provided
BACKEND ->> BACKEND: Stop processing
else If payment fraud = Review then no transaction optimisation recommendation is provided
BACKEND ->> GATEWAY: Authentication Request
Note over BACKEND,GATEWAY: Recommendation: 3DS challenge preference set to 'No preference' to help balance payment fraud risk, liability shift, and chance of frictionless authentication
GATEWAY -->> BACKEND: Authentication Response
else If payment fraud = Allow AND transaction optimisation = Authenticate
BACKEND ->> GATEWAY: Authentication Request
Note over BACKEND,GATEWAY: Any exemption and challenge preference will also need to be included
GATEWAY -->> BACKEND: Authentication Response
else If payment fraud = Allow AND transaction optimisation = Authorise
Note over BACKEND,GATEWAY: Skip straight to authorisation request, including any exemption preferences in the request
end
BACKEND ->> GATEWAY: Authorisation Request
opt If issuer soft declines authorisation request without prior authentication
GATEWAY -->> BACKEND: Authorisation Response
Note over BACKEND,GATEWAY: Payment gateway informs client of issuer soft decline
BACKEND ->> GATEWAY: Authentication Request
Note over BACKEND,GATEWAY: Set 3DS challenge preference as 3DS mandated. Some payment gateways will send straight to 3DS following a soft decline without the client needing to send a separate authentication request. In this case, the additional authorisation request is not required.
end
GATEWAY -->> BACKEND: Authorisation Response
BACKEND -->> PAYMENT_PAGE: Transaction outcome
BACKEND ->> RAVELIN: Authentication and transaction outcome
Note over BACKEND, RAVELIN: Data must be sent to improve future payment fraud and transaction optimisation recommendations