Our iOS Drop-in renders the available cards in your payment form, and securely collects any sensitive card information, so it doesn't touch your server. Drop-in also handles the 3D Secure 2 device fingerprinting and challenge flows, including the data exchange between your front end and the issuer's Access Control Server (ACS).
When making a card payment with native 3D Secure 2 authentication, you need to:
- Configure Drop-in to collect the cardholder name.
- Provide additional parameters when making a payment request.
- Submit authentication results if you receive an
actionobject in response to your /payments or /payments/details request.
- If the payment was routed to 3D Secure 2 redirect flow, handle the redirect result.
Use v4.10.2 or later of iOS Drop-in to trigger the native 3D Secure 2 flow and ensure best performance. We recommend you always use the latest Drop-in version.
Before you begin
This page explains how to add cards with native 3D Secure 2 authentication to your existing iOS Drop-in integration. The iOS Drop-in integration works the same way for all payment methods. If you haven't done this integration yet, refer to our Drop-in integration guide.
Before starting your integration:
- Make sure that you have set up your back end implementation, and added Drop-in to your payment form.
- Add the cards that you want to accept in your test Customer Area.
Collect additional parameters in your payment form
For higher authentication rates, we strongly recommend that you collect the shopper cardholder name and billing address in advance in your payment form. Deliver these parameters to your backend when making a payment, because they are required by the card schemes.
Show the available cards in your payment form
For information about the supported countries and currencies for each card, refer to Payment methods.
To show cards in your payment form:
When initializing the Drop-in, create a configuration object, and specify:
configuration.card.showsHolderNameField: true. This shows the input field for the cardholder name.
If you want to set
ThreeDSRequestorAppURL, create a configuration object and specify
actionComponent.threeDS.requestorAppURL. Always use a universal link if you set
let configuration = DropInComponent.Configuration(apiContext: apiContext) configuration.card.showsHolderNameField = true // Displays the field for entering the holder name. configuration.actionComponent.threeDS.requestorAppURL = URL(string: "YOUR_APP_URL") // Optional, add a universal link here when you want to send ThreeDSRequestorAppURL
When the shopper is entering their card details, Drop-in tries to recognize the card brand. When successful, Drop-in renders the brand icon.
Make a payment
When the shopper proceeds to pay, Drop-in invokes the
didSubmit method which contains
data.paymentMethodto your server.
- From your server, make a /payments request, specifying:
Make sure to include threeDS2SdkVersion.
|channel||Set to iOS.|
|authenticationData.threeDSRequestData.nativeThreeDS||Set to preferred. Indicates that your payment page can handle 3D Secure 2 transactions natively.|
|returnUrl||Used to redirect the shopper back to a webpage for redirect and other payment flows. If you want to redirect the shopper to your app, configure a
|billingAddress||The cardholder's billing address.|
|shopperEmail||The cardholder's email address.|
To increase the likelihood of achieving a frictionless flow and higher authorisation rates, we recommend that you send additional parameters if you have the data available. Do not send placeholder data in the live environment.
channel iOS, we recommend including these additional parameters:
Your next steps depend on whether the /payments response contains an
action object, and on the
action.type. Choose your API version:
||The transaction was either exempted or out-of-scope for 3D Secure 2 authentication.||Use the
|threeDS2||The payment qualifies for 3D Secure 2, and will go through the authentication flow.||1. Pass the
2. Submit the challenge result.
|redirect||The payment is routed to the 3D Secure 2 redirect flow.
||1. Pass the
2. Handle the redirect result.
The following example shows a /payments response with
Submit authentication results
dropInComponent.handle(action) to perform the required authentication flow. After completing the action, Drop-in invokes the
didAdditionalDetails method which contains
Present the payment result
For card payments, you can receive the following
|resultCode||Description||Action to take|
|Authorised||The payment was successful.||Inform the shopper that the payment has been successful.
If you are using manual capture, you also need to capture the payment.
|Cancelled||The shopper cancelled the payment.||Ask the shopper if they want to continue with the order, or ask them to select a different payment method.|
|Error||There was an error when the payment was being processed. For more information, check the
||Inform the shopper that there was an error processing their payment.|
|Refused||The payment was refused. For more information, check the
||Ask the shopper to try the payment again using a different payment method.|
Test and go live
Use our test card numbers to test how your integration handles different 3D Secure 2 authentication scenarios.
If native 3D Secure 2 is not triggered, check that:
- Your Drop-in version is 4.10.2 or later
paymentMethod.threeDs2SdkVersionis populated and sent in payment request
channelis set to iOS
authenticationData.threeDSRequestData.nativeThreeDSis set to preferred if you use Checkout API v69 or later OR
additionalData.allow3DS2is set to true if you use Checkout API v68 or earlier