- Get Started
- Guides
- Integrations
- References
- API Reference
- Basic Payment
- Forex
- Authentication
- Card Account
- Apple Pay
- Virtual Account
- Bank Account
- Token Account
- Customer
- Billing Address
- Merchant Billing Address
- Shipping Address
- Merchant Shipping Address
- Corporate
- Sender
- Recipient
- Merchant
- Marketplace & Cart
- Airline
- Lodging
- Passenger
- Tokenization
- Recurring Migration
- 3D Secure
- Custom Parameters
- Async Payments
- Webhook notifications
- Job
- Risk
- Point of Sale
- Response Parameters
- Card On File
- Chargeback
- Result Codes
- Payment Methods
- Transaction Flows
- Regression Testing
- Data Retention Policy
- Release Notes
- API Reference
- Support
Mobile SDK Standalone
MSDK 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.
Mobile 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
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 MSDK.
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.
NOTE: you need to provide valid 3D Secure 2 protocol version when creating transaction. Supported versions are 2.1.0 and 2.2.0.
Send authentication parameters
Getting authRequestParams
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 MSDK 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!