- Getting Started
- Tutorials
- Reference
- API Reference
- Basic Payment
- Authentication
- Card Account
- Virtual Account
- Bank Account
- Customer
- Billing Address
- Shipping Address
- Corporate
- Merchant
- Cart
- Airline
- Tokenization
- Recurring
- Recurring Migration
- 3D Secure
- Custom Parameters
- Async Payments
- Webhook notifications
- Risk
- Point of Sale
- Response Parameters
- Card On File
- Chargeback
- Result Codes
- Brands Reference
- API Reference
- FAQ
3DS SDK Standalone
3DS SDK makes it easy to implement native 3D Secure 2 authentication in a mobile application.
NOTE: This guide is specific for the cases when Open Payment Platform (OPP) is not going to be used for some reason. Otherwise, refer to one of the integration types with MSDK.
3DS SDK provides the following features:
- Collecting and encrypting user's device data
- Performing security checks
- Performing challenge process (including presenting UI and communication with ACS)
Features that are NOT included into the scope of SDK:
- Performing authentication request to the 3DS Server
Requirements
Import libraries
Initialize the 3DS service
Initialization phase includes fetching actual config data from the Server, collecting device data and performing security checks. All these actions are done in background thread, so start it whenever you want, it won't affect UI thread. It’s recommended to run initialization on checkout process start or even on application start.
We also recommend to look through the Customization guide to check advanced features of the 3DS SDK.
Create 3DS transaction
After shopper entered card details and clicked Pay, use 3DS service to create 3DS transaction for the specific payment brand. Store a reference to the transaction, it will be needed later to initiate challenge process.
Send authentication parameters
Calling getAuthRequestParams()
will encrypt shopper device data and other important information needed for the 3DS Server to authenticate a transaction. It will return JSON string which should be sent to the Server.
E.g. Platform expects it as threeDSecure.deviceInfo
parameter in the payment submission request.
Display processing view
It’s also required to show appropriate processing view while communicating with the Server. You can use processing view provided by the SDK.
Handle authentication response
If card is enrolled for the 3D Secure 2, Server will return 3DS authentication status and client authentication response which is required for the challenge flow.
E.g. Platform parameters looks like:
<Result name="clientAuthResponse">{"messageType":"AuthResponse","messageVersion":"2.1.0",...}</Result>
<Result name="transactionStatus">C</Result>
Check authentication status
First, check the authentication status, it's one character string, see the meaning of possible values below:
Status | Description |
---|---|
C | In-app challenge required; additional authentication is required using the CReq/CRes. |
Y | Authentication/account verification successful. |
N | Not authenticated/account not verified; transaction denied. |
A | Attempts processing performed; not authenticated/verified, but a proof of attempted authentication/verification is provided. |
R | Authentication/account verification rejected; issuer is rejecting authentication/verification and request that authorization not be attempted. |
U | Authentication/account verification could not be performed; technical or other problem as indicated in ARes or RReq. |
D | External challenge required; decoupled authentication confirmed. |
Depending on status, start challenge or finish the checkout process:
Frictionless flow
Frictionless flow means that authentication is done. The payment will be completed or rejected depending on authentication result and system configuration. Request payment status to get the result of the transaction.
Challenge flow
For the challenge flow you will need to pass clientAuthResponse
received from the Server to the 3SD SDK and start the challenge.
The SDK will take care of all communication with the ACS while performing the challenge, as well as prompting the shopper as needed for the required input. When the challenge process is complete, control returns to the app in the one of the ChallengeCallback
events. See how it can be implemented in the sample code below.
At last, request payment status to finalize the checkout process, and you're done!