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 are not fully PCI compliant, use one of our pre-built UI solutions or build a custom card integration with encryption instead.
Requirements
Requirement | Description |
---|---|
Integration type | Make sure that you have an existing API-only integration. |
Setup steps | Before you begin, 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" | |
Card expiry month | "03" | |
Card expiry year | "30" | |
Card security code (CVV / CVC) | "737" | |
Cardholder name | "S. Hopper" |
Showing co-badged cards
For cards issued in some countries/regions, 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 8 digits, but the full card number gives 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.
-
Make a POST /cardDetails request including the following:
Parameter Description Required merchantAccount
Your merchant account. cardNumber
A minimum of the first 8 digits of the card number and a maximum of the full card number. 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. -
The response has a
brands
array containing the brands on the card. If you includedsupportedBrands
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.
-
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 | |
paymentMethod.number |
The card number (without separators). | |
paymentMethod.expiryMonth |
The card expiry month. | |
paymentMethod.expiryYear |
The card expiry year. | |
paymentMethod.cvc |
The card verification code. | |
paymentMethod.holderName |
The name of the cardholder. | |
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. |
|
paymentMethod.threeDS2SdkVersion |
The version of the 3D Secure 2 mobile SDK. Required for mobile integrations to trigger in-app Native 3D Secure 2 (iOS or Android. |
The /payments response contains:
- pspReference: Our unique identifier for the transaction.
resultCode
: Use this to present the payment result to your shopper.merchantReference
: Thereference
from the /payments request.additionalData
: Additional information about the transaction.
To specify the fields that you want to receive inadditionalData
, 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:
-
If you are 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 to 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.
- splitCardFundingSources: Set this to true to receive separate objects for credit and debit cards in the response.
-
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.
Brazil
For debit transactions, we highly recommend using 3D Secure and Automatic Capture due to some issuers' restrictions.
Sweden
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
-
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. ThestoredPaymentMethods
array contains theid
that you need when making the payment.If your Components version is 3.2.0 or lower, use the
oneClickPaymentMethods
array and therecurringDetailReference
instead.
{
...
"storedPaymentMethods":[
{
"brand":"visa",
"expiryMonth":"10",
"expiryYear":"2020",
"holderName":"John Smith",
"id":"8415718415172204",
"lastFour":"1111",
"name":"VISA",
"supportedShopperInteractions":[
"Ecommerce",
"ContAuth"
],
"type":"scheme"
},
{
"brand":"visa",
"expiryMonth":"08",
"expiryYear":"2018",
"holderName":"John Smith",
"id":"8315720121476805",
"lastFour":"0008",
"name":"VISA",
"supportedShopperInteractions":[
"ContAuth",
"Ecommerce"
],
"type":"scheme"
}
]
...
}
-
Collect the following card details from the shopper in your payment form:
Card details Example input The security code (CVV / CVC) "737" -
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
: Theid
from the the /paymentMethods response. This is therecurringDetailReference
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.shopperInteraction
: ContAuth.recurringProcessingModel
: CardOnFile.
{
"amount":{
"currency":"USD",
"value":1000
},
"reference":"YOUR_ORDER_NUMBER",
"paymentMethod":{
"type":"scheme",
"storedPaymentMethodId":"8415718415172204",
"cvc":"737"
},
"shopperReference":"YOUR_UNIQUE_SHOPPER_ID_IOfW3k9G2PvXFu2j",
"returnUrl":"https://your-company.com/...",
"merchantAccount":"YOUR_MERCHANT_ACCOUNT"
}
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:
-
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 D document. For more information, refer to PCI DSS compliance guide.