Dynamic 3-D Secure (3DS) allows you to bypass 3-D Secure authentication for payers where payments are deemed low risk by your external risk provider. It gives you the flexibility to selectively perform 3DS authentication on transactions while maintaining appropriate risk management. It also allows increased conversion rates through frictionless checkout for low risk payments as payers are less likely to abandon the payment process when not redirected from the merchant's website to enter their 3DS password.
When Dynamic 3DS is enabled, you can choose to:
risk.bypassMerchantRiskRules
=ALL
) and submit the transaction without 3DS authentication data:
The gateway supports Dynamic 3DS on transactions using the following integration methods:
When Dynamic 3DS is enabled, you have two options to submit an initial transaction to the gateway:
With this option, the gateway will send the transaction to the external risk provider for risk assessment.
The transaction response will contain the gateway's recommendation for the transaction (in the response.gatewayRecommendation
field) based on the risk assessment provided by the risk provider. You can use this to determine the next step as summarized in the table below.
response.gatewayRecommendation |
Next step |
---|---|
PROCEED |
You can display a message to the payer that the payment was successful. |
DO_NOT_PROCEED_ABANDON_ORDER |
Do not submit the same request again. The payment service provider, scheme or issuer require you to abandon the order. |
RESUBMIT_WITH_PAYER_AUTHENTICATION |
The transaction will be blocked by the gateway; however, you might be able to change the outcome by submitting 3DS authentication data. Perform 3DS authentication of the payer and resubmit the transaction (same card number) with 3-D Secure authentication details. If this transaction passes all 3DS Transaction Filtering rules, the gateway will process the payment. |
With this option, the transaction will not be submitted to the external risk provider for risk assessment. If the transaction passes all Transaction Filtering rules (including 3DS rules) it will be successfully processed by the gateway.
If you want to conditionally offer 3DS authentication in a Hosted Checkout interaction, set the field interaction.action.3DSecure
to USE_GATEWAY_RECOMMENDATION
in the Create Checkout Session
request.
Hosted Checkout determines if 3DS authentication is required based on the risk assessment provided by the risk provider. This is summarized in the table below.
risk.response.gatewayCode |
response.gatewayRecommendation |
Next step |
---|---|---|
ACCEPT |
PROCEED |
Hosted Checkout displays a message to the payer that the payment was successful. |
REVIEW_REQUIRED |
ATTEMPT_WITH_AUTHENTICATION |
Hosted Checkout offers 3DS authentication to the payer and resubmits the transaction (same card number) with 3-D Secure authentication details. If this transaction passes all 3DS Transaction Filtering rules, Hosted Checkout processes the transaction. |
REJECT |
DO_NOT_PROCEED |
Hosted Checkout displays a message to the payer that the payment was not successful and that they can retry with another card or payment method. |
Without Dynamic 3DS, a transaction with a Trusted Card overrides all other Transaction Filtering rules defined by you, and will be sent to the external risk provider for risk assessment. Note that a Trusted Card rule cannot override Transaction Filtering rules defined by your payment service provider.
However, when Dynamic 3DS is enabled, if a transaction with a Trusted Card is submitted with 3DS authentication data and passes all 3DS Transaction Filtering rules (defined by you and your payment service provider) then it will not be sent to the risk provider for risk assessment. Only transactions without 3DS authentication data and/or which fail any 3DS Transaction Filtering rules will be sent to the risk provider.
Copyright © 2023 Mastercard