Rules-Based Payer Authentication
Rules-based payer authentication enables you to specify rules that define how transactions are authenticated by a 3D Secure card authentication program. For example, you can decide to turn off active authentication for transactions that would otherwise require customer interaction to avoid degrading the customer experience. However, you may decide to authenticate customers from card-issuing banks that use risk-based authentication because the authentication is performed without customer interaction.
To enable your account for rules-based payer authentication, contact your Cybersource sales representative.
|
|
Depending on the card type and country, active mandates supersede |
By default, when payer authentication is enabled on your account, authentication is attempted on all transactions.
For transaction types that are not bypassed, you may be required to complete authentication.
You can enable one or more of the following authentication transaction types. Any transaction types that are set to bypass authentication return the response flag SOK. If you receive response flag DAUTHENTICATE from the enrollment check, you must complete validation even if no customer participation is needed.
|
Authentication Type |
Description |
Test Case Example |
|
Active Authentication |
Customer is prompted to authenticate. |
Test Case 1: Visa Secure Card Enrolled: Successful Authentication |
|
Attempts Processing |
Customer is prompted to enroll in a 3D Secure card authentication program. This transaction type provides full 3D Secure benefits. |
|
|
Non-Participating Bank |
Card-issuing bank does not participate in a 3D Secure program. When enrollment is checked, this transaction type provides full 3D Secure benefits, including fraud chargeback liability shift for customer “I didn’t do it” transactions and interchange reduction of 5-59 basis points. |
|
|
Passive Authentication |
Customer is not prompted to authenticate. This transaction type provides full 3D Secure benefits when passive authentication is completed. |
|
|
Risk-Based Bank |
Card-issuing bank uses risk-based authentication. The likely outcome is that the customer is not challenged to enter credentials. Most authentications proceed without customer interaction. This transaction type provides full 3D Secure benefits. |
|
|
|
By default, API responses that are specifically associated with rules-based payer authentication are turned off. Contact Cybersource Customer Support to enable these API responses when rules are triggered. |
Bypassed Authentication Transactions
When card authentication is bypassed as a result of your rules-based payer authentication configuration, you can receive the following value for enrollment checks:
npa_enroll_veres_enrolled = B (indicates that authentication was bypassed)
When a transaction involves a card-issuing bank that supports risk-based authentication, you may receive the following authentication path responses, depending on whether the card-issuing bank deems the transaction risky:
npa_enroll_authentication_path
l= RIBA
The card-issuing bank supports risk-based authentication, but whether the cardholder is likely to be challenged cannot be determined.
l= RIBA_PASS
The card-issuing bank supports risk-based authentication, and it is likely that the cardholder will not be challenged to provide credentials; also known as silent authentication.