Are you looking for test card numbers?

Would you like to contact support?

No momento, esta página não está disponível em português
Payment-method icon

Raw card data

Accept card payments submitting raw card data.

Use our APIs to accept card payments with raw card data, and build your own UI to have full control over the look and feel of your checkout page.

To collect raw card data, you need to be fully PCI compliant. If you're not fully PCI compliant, use one of our client-side solutions or make a custom card integration instead.

Before you begin

These instructions explain how to add card payments to your existing API-only integration. The API-only integration works the same way for all payment methods. If you haven't done this integration yet, refer to our API-only integration guide.

Before starting your integration:

  1. Make sure that you have set up your back end implementation.
  2. Add the cards that you want to support in your test Customer Area.

Build your payment form for cards

When making a card payment, collect the following shopper details:

Card details Example input Required
Card number "4111111111111111" -white_check_mark-
Card expiry month "03" -white_check_mark-
Card expiry year "30" -white_check_mark-
Card security code (CVV / CVC) "737" -white_check_mark-
Cardholder name "S. Hopper" -white_check_mark-

Showing co-badged cards

For cards issued in some countries, you must comply with regulations for co-badged cards.

Use the /cardDetails endpoint to identify the brands on the shopper's card. To identify the brands, start making /cardDetails requests while the shopper is entering the card number. You need a minimum of the first 6 digits, but 11 digits give the best result.

If the /cardDetails endpoint identifies two brands and you support both, you must let the shopper choose which brand to pay with. If you only support one brand, let the shopper pay with it.

  1. Make a POST /cardDetails request including the following:

    Parameter Description Required
    merchantAccount Your merchant account. -white_check_mark-
    cardNumber A minimum of the first 6 digits of the card number and a maximum of the full card number. -white_check_mark-
    countryCode The shopper's two-character ISO-3166-1 alpha-2 country code.
    supportedBrands The array of the card brands that you support. This is the brands array from your /paymentMethods response. If not provided, we assume that you support all card brands.
  2. The response has a brands array containing the brands on the card. If you included supportedBrands in the request, the response shows the ones you support.

    The following example shows a response where:

    • The brands on the card are visa and cartebancaire.
    • The merchant account only supports visa.
  3. If you support both brands, you must let the shopper choose their preferred brand. Render brand logos and names in the payment form for the shopper to choose one and include the brand when making a payment.

Make a payment

From your server, make a /payments request, specifying:

Field Description Required
paymentMethod.type scheme -white_check_mark-
paymentMethod.number The card number (without separators). -white_check_mark-
paymentMethod.expiryMonth The card expiry month. -white_check_mark-
paymentMethod.expiryYear The card expiry year. -white_check_mark-
paymentMethod.cvc The card verification code. -white_check_mark-
paymentMethod.holderName The name of the cardholder. -white_check_mark-
paymentMethod.brand If the card is co-badged, this is the brand that the shopper choose to pay with.
This is the brands.type from the /cardDetails response that matches the shopper's preferred brand.

The /payments response contains:

  • pspReference: Our unique identifier for the transaction.
  • resultCode: Use this to present the payment result to your shopper.
  • merchantReference: The reference from the /payments request.
  • additionalData: Additional information about the transaction.
    To specify the fields that you want to receive in additionalData, log in to your Customer Area, and go to Developers > Additional data.

Present the payment result

Use the  resultCode from the /payments response to present the payment result to your shopper. You will also receive the outcome of the payment asynchronously in a webhook.

For card payments, you can receive the following resultCode values:

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 whether 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 refusalReason field. Inform the shopper that there was an error processing their payment.
Refused The payment was refused. For more information, check the refusalReason field. Ask the shopper to try the payment again using a different payment method.

Additional resultCode values are possible in case of the 3D Secure authentication flow. For more information, refer to Result codes.

Present debit and credit cards separately

This requires Checkout API v53 and later.

In some scenarios, you may want to present your shoppers with separate payment forms for debit cards and credit cards. Some examples include:

  • If you accept payments in Sweden, you need to present debit cards before credit cards in order to comply with local legislation.
  • In Brazil, many shoppers use Combo cards, allowing for both debit and credit transactions. Having a separate form for Debit Card and Credit Card gives your shoppers a clear indication of whether they are making a debit or credit transaction.

For more details, see the corresponding sections about Brazil and Sweden.

To show debit and credit cards separately:

  1. If you're using the /paymentMethods endpoint to get a list of payment methods to present on the client side, include:

    • splitCardFundingSources: Set this to true to receive separate objects for credit and debit cards in the response.

    The following example shows how you would get the available payment methods for a shopper in the Netherlands, making a EUR 47.00 payment.

    The response includes the list of available payment methods, with debit and credit cards split into separate objects.

  2. When the shopper selects to pay with either a debit or credit card, proceed to make a POST /payments request and include:

    • paymentMethod.fundingSource: Set this to either credit or debit.

    The following example shows how you can make a payment request for a debit card.


For debit transactions, we highly recommend using 3D Secure and Automatic Capture due to some issuers' restrictions.


When accepting payments in Sweden, present debit before credit cards, and label the forms clearly in order to comply with Swedish legislations.

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, include in your /payments request:

  • storePaymentMethod: true
  • shopperReference: Your unique identifier for the shopper.

The /payments response contains:

  • recurringDetailReference: This is the token that you'll need to make recurring payments for this shopper.

The recurringDetailReference is also contained in the AUTHORISATION webhook that you will receive for this payment.

Show a stored card in your payment form

  1. To get the stored payment methods for a shopper, include in your /paymentMethods request:

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

    The /paymentMethods response includes a storedPaymentMethods array containing the stored payment methods for this shopper. The storedPaymentMethods array contains the id that you need when making the payment.

    If your Components version is 3.2.0 or lower, use the oneClickPaymentMethods array and the recurringDetailReference instead.

                "holderName":"John Smith",
                "holderName":"John Smith",
  1. Collect the following card details from the shopper in your payment form:

    Card details Example input
    The security code (CVV / CVC) "737"
  2. Next, proceed to submit a payment request from your server.

Make a payment with a token

To make a payment with the token, include in your /payments request:

  • paymentMethod.storedPaymentMethodId: The id from the the /paymentMethods response. This is the recurringDetailReference that you received when creating the token.
  • paymentMethod.cvc: The security code that you collected from the shopper.
  • shopperReference: The unique shopper identifier that you specified when creating the token.
  • shopperInteractionContAuth.
  • recurringProcessingModel: CardOnFile.

The /payments response contains:

   "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.

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

See also