This page explains how to add cards to your existing iOS Drop-in integration.
Requirements
Select the server-side flow that your integration uses:
Requirement | Description |
---|---|
Integration type | Make sure that you have built a Sessions flow iOS Drop-in integration. |
Setup steps | Before you begin, add cards in your Customer Area. |
API reference
You do not need to send additional fields for cards. To see optional fields that you can send for all payment methods, choose the endpoint you integrated:
- /sessions: This is the default with Drop-in v5.0.0 or later.
- /payments: If you implemented an additional use case.
You can send additional fields for specific use cases. For example showing debit and credit cards separately.
Drop-in configuration
//Create a payment method object for cards. let paymentMethod = paymentMethods.paymentMethod(ofType: CardPaymentMethod.self) //Create a configuration object for the cards Component. var cardComponentConfiguration = CardComponent.Configuration() //Set additional parameters on the configuration object. cardComponentConfiguration.localizationParameters = //Optional custom localization parameters.
Optional configuration
If your integration uses iOS Drop-in v5.0.0 or later, you can optionally include the following when you configure the Drop-in:
Parameter name | Description | Default |
---|---|---|
showsHolderNameField |
Set to true to show the field for the cardholder name. | false |
showsSecurityCodeField |
Set to false to hide the security code (CVV/CVC) field. | true |
allowedCardTypes |
Array of supported card types that you recognize. | Values from AnyCardPaymentMethod . |
billingAddress.requirementPolicy |
Set to true to collect the shopper's billing address and mark the fields as required. | false |
billingAddress.mode |
Sets which billing address fields to show in the payment form. Possible values: - full: show all billing address fields. - none: do not show billing address fields. - postalCode: show only the postal code field. |
none |
billingAddress.countryCodes |
Array of allowed country codes for the billing address. For example, ['US', 'CA', 'BR'] . |
nil: all country codes are supported. |
koreanAuthenticationMode |
For Korean cards, sets if security fields show in the payment form. Possible values: - show: show the fields. - hide: do not show the fields. - auto: the field appears for cards issued in South Korea. |
auto |
socialSecurityNumberMode |
For Brazilian cards, sets if the CPF/CNPJ social security number field shows in the payment form. Possible values: - show: show the field. - hide: do not show the field. - auto: the field appears based on the detected card number. |
auto |
Showing debit and credit cards separately
Drop-in can show separate payment forms for debit cards and credit cards. Here are example use cases for this feature:
- In Brazil and Finland, many shoppers use combo cards that can make both debit or credit transactions. If you use separate forms for Debit Card and Credit Card the shopper can choose the type of transaction.
- To accept card payments in Sweden, local legislation requires you to show the debit card payment options before the credit card ones.
Choose which server-side flow your integration uses:
When you make a /sessions request from your server, include:
- splitCardFundingSources: Set to true.
The following example shows how to do this for a shopper in the Netherlands, making a EUR 47.00 payment.
curl https://checkout-test.adyen.com/v69/sessions \ -H 'x-api-key: ADYEN_API_KEY' \ -H 'content-type: application/json' \ -d '{ "merchantAccount": "YOUR_MERCHANT_ACCOUNT", "countryCode": "NL", "amount": { "currency": "EUR", "value": 4700 }, "splitCardFundingSources": true }'
Combo cards
For debit transactions, we highly recommend using 3D Secure and Automatic Capture due to some issuers' restrictions.
Sweden
To comply with local legislation, set countryCode
to SE in your request. Drop-in shows the payment form for Debit Card before the one for Credit Card.
Card brand recognition
When the shopper is entering their card details, Drop-in tries to recognize the card brand. When successful, Drop-in renders the brand icon and the corresponding input field for the card security code (CVC, CVV, or CID).
Co-badged cards
Co-badged cards are rendered by Drop-in according to the co-badged card regulations for the applicable regions. This means that Drop-in renders all supported brands, and allows the cardholder to choose their preferred brand.
Stored card payments
Adyen's tokenization service allows you to securely store shopper's card details for payments. You first need to create a token.
Supported from Drop-in v5.0.0 and later.
Creating a token
Include the storedPaymentMethodMode
parameter in your /sessions request. Possible values:
Value | Description |
---|---|
disabled (default) | Do not store payment details. |
askForConsent | If shopperReference is included in the request, display a checkbox in the payment form that the shopper can select to store their payment details. |
enabled | If shopperReference is included in the request, store the shopper's payment details without showing a toggle. For example, use this for a page where the shopper enters their details for a subscription service that charges the shopper on a recurring basis. |
If you or the shopper chooses to store payment details, your instance of AdyenSession
creates a token when the shopper pays.
Making a payment with a token
When the shopper pays, your instance of AdyenSession
includes the shopper's stored card details. You can also use tokens to make shopper-not-present payments for subscriptions or contracts.
Accepting credit card installments
If you want to accept credit card installments, include in the /sessions request, include the installmentOptions
object which includes the following fields:
Field | Required | Description |
---|---|---|
values |
An array of the number of installments that the shopper can choose. | |
preselectedValue |
The preselected number of installments in the payment form. | |
plans |
An array that shows the types of installment plans that the shopper can choose. Possible values: regular and revolving. If not included, the default is regular. |
Test and go live
If your client-side integration isn't ready, you can test API requests with encrypted card details by adding a test_
prefix to the test card details.
Before making live card payments:
-
Test your integration using our test card numbers. You can check the status of test payments in your Customer Area > Transactions > Payments.
-
Add the cards that you want to accept in your live Customer Area.
-
Before you can start accepting card payments in the live environment, you need to assess your PCI DSS compliance and submit the required Self-Assessment Questionnaire A document.