3D Secure
Client-Side Implementation
Additionally, add the following Maven repository and (non-sensitive) credentials to your app-level gradle.
- Groovy
repositories {
maven {
url "https://cardinalcommerceprod.jfrog.io/artifactory/android"
credentials {
username = 'braintree_team_sdk'
password = 'AKCp8jQcoDy2hxSWhDAUQKXLDPDx6NYRkqrgFLRc3qDrayg6rrCbJpsKKyMwaykVL8FWusJpp'
}
}
}
Specify a merchant account
If you would like to use a merchant account ID other than your default, specify the merchant_account_id
when generating the client token.
Using 3DS
Drop-in UI
First, make sure to include our Drop-in in your project. Next, declare a URL scheme in your AndroidManifest. This allows your app to switch to a browser to complete the 3D Secure verification workflow and return.
To use 3DS2, you will need to create a ThreeDSecureRequest
object with relevant customer and transaction data in order to minimize the need for issuing banks to present authentication challenges to customers. This object must contain the following fields:
amount
versionRequested
(You should passThreeDSecureRequest.VERSION_2
here)
And should contain as many of the following fields as possible:
email
billingAddress
additionalInformation
Custom UI
To make sure your app can complete a 3D Secure verification, declare a URL scheme in your AndroidManifest. This will allow Android to return to your app from a browser-based verification flow.
Add the following to your app-level build.gradle
file:
Next, create a ThreeDSecureRequest
with relevant customer and transaction data to help minimize the need for issuing banks to present authentication challenges to customers. This object must contain the following fields:
amount
nonce
versionRequested
(You should passThreeDSecureRequest.VERSION_2
here)
And should contain as many of the following fields as possible:
email
billingAddress
additionalInformation
Verify a vaulted credit card
First, on the server, generate and return a payment method nonce for the vaulted credit card.
Validation errors
Braintree will evaluate any fields passed against Cardinal's documentation. You will receive a validation error from Braintree if a field is incorrect.
Advanced client-side options
We expose additional information about the authentication request that you can use for more advanced UI flows or risk assessment. You should be aware that making such assessments may result in accepting the liability for fraudulent transactions.
These parameters pass through the client-side first and should not be trusted for your server-side risk assessment. They should be used for UI flow only.
liabilityShifted
indicates that 3D Secure worked and authentication succeeded. This will also be true if the issuing bank does not support 3D Secure, but the payment method does. In both cases, the liability for fraud has been shifted to the bank. You should go on creating a transaction using the new nonce.liabilityShiftPossible
indicates that the payment method was eligible for 3D Secure. IfliabilityShifted
isfalse
, then the user failed 3D Secure authentication. In this situation, the card brands recommend asking the user for another form of payment. However, if you have server-side risk assessment processes that allow for it, you can still use the new nonce to create a transaction. If you want to use a nonce that did not pass 3D Secure authentication, you need to set therequired
option tofalse
in your server integration.- If both of the above values are
false
then this card was ineligible for 3D Secure. You can continue to create the transaction with the new nonce. However, liability shift will not apply to this transaction. This case may be useful if you would like to ask the user for additional verification (AVS, etc).
Using 3D Secure with a CVV-only nonce
If you want to use a CVV-only nonce when creating a transaction with 3D Secure, you will need to pass a 3D Secure Authentication ID together with a CVV-only nonce when creating a transaction, creating a payment method, or creating a customer with a payment method
Using 3D Secure Data-Only
To use use the 3D Secure data-only protocol for a given cardbrand, add the dataOnlyRequested
boolean, and check for the resulting status in the onLookupComplete()
callback:
Using 3D Secure with Google Pay
We support 3DS for Google Pay non-network tokenized cards.
Google Pay cards can be tokenized in one of two ways:
- A non-network tokenized card is a standard credit card. Access to the card's primary account number (PAN) makes 3DS verification possible.
- A network tokenized card is a generated virtual card with a device-specific account number (DPAN) that is used in place of the underlying source card. These cards cannot be used with 3DS.
Drop-in UI with Google Pay
If 3DS was requested, Google Pay cards that are non-network tokenized will automatically be processed for 3DS verification.
Custom UI
Using accountType for combo cards in Brazil
When processing Brazilian cards domestically, customers with combo cards should be given the opportunity to select the account type of their card. To do this, generate a UI for this selection and reflect that choice in the 3D Secure call, as well as the corresponding transaction, payment method or customer API call.
Next Page: Server-side →