Cards Drop-in integration

On this page, you can find additional configuration for adding cards to your Drop-in integration.

Before you begin

This page assumes you've already:

• Built a Drop-in integration.
• Added cards in your Customer Area.

API reference

You don't 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 Components v5.0.0 or later.
• /payments: If you implemented an advanced use case, or integrated Components before v5.0.0.

You can also send additional fields for specific use cases, for example if you want to present debit and credit cards separately.

Presenting debit and credit cards separately

Select which endpoint you're integrating:

Drop-in then automatically renders separate payment forms for Credit card and Debit card. If you sent a request with countryCode of SE, Drop-in automatically presents Debit Card before Credit Card, in order to comply with Swedish legislations.

Drop-in configuration

Optional configuration

You can include the following optional configuration for cards:

Events

You can also customize your shopper's experience when specific events occur.

If you want to add optional configuration, include this in a configuration object. The following example shows how to configure Drop-in to collect the card holder name and billing address as required, and show a check box for saving card details for later payments:

const cardConfiguration = {
   hasHolderName: true,
   holderNameRequired: true,
   billingAddressRequired: true, // Set to true to show the billing address input fields.
   enableStoreDetails: true
};

If you created a cardConfiguration object, include this when creating a configuration object:

const configuration = {
  // ...  other required configuration
  paymentMethodsConfiguration: {
    card: cardConfiguration
  }
};

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-branded cards

Co-branded cards issued in Europe are rendered by Drop-in according to the European regulatory guidelines (EU IFR Regulation 2015/751 article 8). This means that Drop-in renders all supported brands, and allows the cardholder to choose their preferred brand. This functionality is supported in version 3.18.2 and later.

Recurring payments

Adyen's tokenization service allows you to securely store shopper's card details for recurring payments. To make recurring payments, you first need to create a shopper token, and then use the token to make future payments for the shopper.

Create a token

To store shopper's card details, set enableStoreDetails to true when creating an instance of Drop-in. This will show a check box to your shopper for saving their card details for future payments.

If the shopper chooses to save their card details when making a payment, the onSubmit method from Drop-in will include state.data.storePaymentMethod. Pass this to your server.

To create a token, include in your /payments request:

• storePaymentMethod: The state.data.storePaymentMethod from your front end.
• shopperReference: Your unique identifier for the shopper.

Show a stored card in your payment form

To show a stored card in your payment form, include in your /paymentMethods request:

• shopperReference: The unique shopper identifier that you specified when creating the token.

If you don't want to show previously stored payment methods in the Drop-in payment method list, set showStoredPaymentMethods to false when creating an instance of Drop-in.

Make a payment with a token

When the shopper selects to pay, Drop-in calls the onSubmit event, which contains a state.data.

1. Pass the state.data to your server.
2. From your server, make a /payments request, specifying:
   • paymentMethod: The state.data.paymentMethod from the onSubmit event.
   • shopperReference: The unique shopper identifier that you specified when creating the token.
   • shopperInteraction: ContAuth.
   • recurringProcessingModel: CardOnFile.
   https://docs.adyen.com/payment-methods/cards/ios-drop-in#payment-request-with-a-token

   Payment request with a token

   curl https://checkout-test.adyen.com/v67/payments \
   -H "X-API-key: [Your API Key here]" \
   -H "Content-Type: application/json" \
   -d '{
    "amount":{
      "value":2000,
      "currency":"USD"
    },
    "paymentMethod":{
      "type":"scheme",
      "storedPaymentMethodId":"8415718415172204",
      "encryptedSecurityCode":"adyenjs_0_1_18$MT6ppy0FAMVMLH..."
    },
    "reference":"YOUR_ORDER_NUMBER",
    "merchantAccount":"YOUR_MERCHANT_ACCOUNT",
    "returnUrl":"...",
    "shopperReference":"YOUR_UNIQUE_SHOPPER_ID_IOfW3k9G2PvXFu2j",
    "shopperInteraction":"ContAuth",
    "recurringProcessingModel":"CardOnFile"
   }'

The /payments response contains:

• resultCode: Use this to present the payment result to your shopper.

{
   "pspReference": "8815329842815468",
   "resultCode": "Authorised"
}

You can also use tokens to make shopper-not-present payments for subscriptions or contracts. For more information, refer to Making a payment for a subscription or contract.

Test and go live

Before making live card payments:

1. Test your integration using our test card numbers. You can check the status of test payments in your Customer Area > Transactions > Payments.
   If you want to test API calls but your client-side integration is not yet ready, add a test_ prefix to the test card credentials. Refer to test with encrypted card details.
2. Add the cards that you want to accept in your live Customer Area.

3. 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. For more information, refer to PCI DSS compliance guide.

See also