Read a condensed guide to SCA and understand when SCA applies and when it does not.
Issuer performed risk and identity check, giving both liability shift and SCA compliance.
Enable 3DS in our Payments API
Add 3DS authentication as part of an orchestrated Payments API request.
Use our standalone 3DS API
Send a separate 3DS authentication API request and receive a response with the authentication details. Apply this in our Card Payments API or other payment gateways/acquirers as part of external MPI.
Worldpay performed risk checks and granting of TRA (Transaction Risk Analysis) exemptions. Reduce 3DS checkout friction.
Enable SCA Exemptions in our Payments API
Ask for an SCA Exemption to be applied automatically as part of our Payments API.
Use our standalone SCA Exemptions API
Send a separate SCA Exemptions API request and receive a outcome containing a granted exemption. Apply this in the Card Payments API.
SCA is an EU regulation under the second Payment Services Directive (PSD2). The aim is to add more layers of security to online payments and reduce fraud.
To meet the requirements under this regulation, the user needs to authenticate with two or more factors:
- something the user knows - PIN, password, answer to a security question
- something the user possesses - mobile phone, physical card
- something the user is - fingerprint, facial recognition
SCA is an EU regulation that can be met using different technology approaches. 3DS is the most commonly used technology solution to meet this by asking the customer to authenticate.
Payment methods such as Apple Pay or Google Pay, instead meet these SCA requirements by ensuring two of the factors above are met through their own authentication. There is an exception in the case of Google Pay when the payment is not stored as an android device token and must go through 3DS.
Additionally, whilst not part of the EEA and therefore not SCA mandated, countries such as Japan and India have mandates on the use of 3DS authentication specifically. As a result, they are considered 3DS mandated countries.
| Country/Group: | When: | |
|---|---|---|
| EEA (European Economic Area) | 31/12/2020 | Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia Finland, France, Germany, Gibraltar, Greece, Hungary, Iceland, Italy, Latvia, Liechtenstein, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden |
| UK | 14/03/2022 | GDPR was in place before it left the EEA and is part of UK law |
| Monaco | 31/12/2020 |
SCA applies to countries in the EEA (European Economic Area) and is required for certain transaction types.
| Scenario | Description |
|---|---|
| Customer Initiated Transaction (CIT) | Online card payment where the customer is present |
| Recurring order - setup of agreement (CIT) | Applies to the first Customer Initiated Transaction (CIT) in a Merchant Initiated Transaction (MIT) series, for example:
|
| Add card to account | For example: add a card to Amazon/eBay account without an initial payment |
| Scenario | Description |
|---|---|
| lowRisk/lowValue (See SCA Exemption) | Under certain conditions you can bypass the need for 3DS whilst still remaining SCA compliant
Note Liability is shifted to the Exemption provider (e.g. Worldpay) instead of the issuer for this case. You should only request exemptions for Customer Initiated Transaction (CIT) where no initial card storage is taking place. For example:
|
| MIT (Merchant Initiated Transactions) | Recurring payments where the customer is not present, do not require SCA The initial setup of the agreement which is CIT, is in scope see table above |
| MOTO Payments | For example: telephone, in-store |
| One Leg Out | If the issuing bank or acquirer (e.g. Worldpay) is outside the EEA (European Economic Area) |
| Corporate Payments | Virtual cards, used for things such as booking travel |
| Whitelist (trusted Businesses) | Cardholder can whitelist a merchant to avoid future 3DS checks |
Liability shifts to the issuer if:
- 3DS authentication is successful using either a frictionless flow (issuer only performs a risk check) or
- a challenge flow (additional identity check), and the proof of a successful 3DS authentication is applied to the payment request (successfully authorized)
Liability shift itself happens at the point of the payment, not the 3DS authentication. A successful 3DS authentication does however make this highly likely.