Start a transaction
Sends payment parameters (like amount, country, and currency) together with other required input details collected from the shopper. To know more about required parameters for specific payment methods, refer to our payment method guides. The response depends on the payment flow:
- For a direct flow, the response includes a pspReference and a resultCode with the payment result, for example Authorised or Refused.
- For a redirect or additional action, the response contains an action object.
Headers
A unique identifier for the message with a maximum of 64 characters (we recommend a UUID).
Request body
This field contains additional data, which may be required for a particular payment request.
The additionalData object consists of entries, each of which includes the key and value.
The delay between the authorization and automatic capture of the payment, specified in hours.
Maximum value: 672 (28 days).
The platform where a payment transaction takes place. This field is optional for filtering out payment methods that are only available on specific platforms. If this value is not set, then we will try to infer it from the sdkVersion or token.
Possible values:
- iOS
- Android
- Web
Checkout attempt ID that corresponds to the Id generated by the client SDK for tracking user payment journey.
Conversion ID that corresponds to the Id generated by the client SDK for tracking user payment journey.
The shopper country code.
Format: ISO 3166-1 alpha-2 Example: NL or DE
The shopper's date of birth.
Format ISO-8601: YYYY-MM-DD
The date and time the purchased goods should be delivered.
Format ISO 8601: YYYY-MM-DDThh:mm:ss.sssTZD
Example: 2017-07-17T13:42:40.428+01:00
The date and time the purchased goods should be delivered.
Format ISO 8601: YYYY-MM-DDThh:mm:ss.sssTZD
Example: 2017-07-17T13:42:40.428+01:00
A string containing the shopper's device fingerprint. For more information, refer to Device fingerprinting.
When true and shopperReference is provided, the shopper will be asked if the payment details should be stored for future one-click payments.
When true and shopperReference is provided, the payment details will be tokenized for payouts.
When true and shopperReference is provided, the payment details will be stored for recurring payments where the shopper is not present, such as subscription or automatic top-up payments.
The type of the entity the payment is processed for.
An integer value that is added to the normal fraud score. The value can be either positive or negative.
The reason for the amount update. Possible values:
- delayedCharge
- noShow
- installment
The localizedShopperStatement field lets you use dynamic values for your shopper statement in a local character set. If this parameter is left empty, not provided, or not applicable (in case of cross-border transactions), then shopperStatement is used.
Currently, localizedShopperStatement is only supported for payments with Visa, Mastercard, JCB, Diners, and Discover.
Supported characters: Hiragana, Katakana, Kanji, and alphanumeric.
The merchant category code (MCC) is a four-digit number, which relates to a particular market segment. This code reflects the predominant activity that is conducted by the merchant.
The merchant account identifier, with which you want to process the transaction.
You can use this reference to link multiple transactions to one another (for example, to track order authorization rate).For each billing cycle, this reference should be unique. After the first authorized payment attempt, do not reuse the reference. If you use this parameter, include it in all of the payment requests that you make. We strongly recommend that you:
- Always include this parameter, so that you can benefit from linking payment requests to one another, in case of authorization retries.
- Additionally include the following parameters in the additionalData object: retry.orderAttemptNumber, retry.chainAttemptNumber, and retry.skipRetry
Metadata consists of entries, each of which includes a key and a value. Limits:
- Maximum 20 key-value pairs per request. When exceeding, the "177" error occurs: "Metadata size exceeds limit".
- Maximum 20 characters per key.
- Maximum 80 characters per value.
When you are doing multiple partial (gift card) payments, this is the pspReference of the first payment. We use this to link the multiple payments to each other. As your own reference for linking multiple payments, use the merchantOrderReferenceinstead.
Required for browser-based (channel Web) 3D Secure 2 transactions.Set this to the origin URL of the page where you are rendering the Drop-in/Component. Do not include subdirectories and a trailing slash.
Date after which no further authorisations shall be performed. Only for 3D Secure 2.
Minimum number of days between authorisations. Only for 3D Secure 2.
Defines a recurring payment type. Required when creating a token to store payment details or using stored payment details. Allowed values:
- Subscription – A transaction for a fixed or variable amount, which follows a fixed schedule.
- CardOnFile – With a card-on-file (CoF) transaction, card details are stored to enable one-click or omnichannel journeys, or simply to streamline the checkout process. Any subscription not following a fixed schedule is also considered a card-on-file transaction.
- UnscheduledCardOnFile – An unscheduled card-on-file (UCoF) transaction is a transaction that occurs on a non-fixed schedule and/or have variable amounts. For example, automatic top-ups when a cardholder's balance drops below a certain amount.
Specifies the redirect method (GET or POST) when redirecting back from the issuer.
Specifies the redirect method (GET or POST) when redirecting to the issuer.
The reference to uniquely identify a payment. This reference is used in all communication with you about the payment status. To provide multiple references for one transaction, separate the reference values with the hyphen (-) character.We strongly recommend that you use a unique value for each transaction. Maximum length: 80 characters.
The URL to return to in case of a redirection. The format depends on the channel.
- For web, include the protocol http:// or https://. You can also include your own additional query parameters, for example, shopper ID or order reference number. Example: https://your-company.example.com/checkout?shopperOrder=12xy
- For iOS, use the custom URL for your app. To know more about setting custom URL schemes, refer to the Apple Developer documentation. Example: my-app://
- For Android, use a custom URL handled by an Activity on your app. You can configure it with an intent filter. Example: my-app://your.package.name
If the URL to return to includes non-ASCII characters, like spaces or special letters, URL encode the value.
We strongly recommend that you use a maximum of 1024 characters.
The URL must not include personally identifiable information (PII), for example name or email address.
The date and time until when the session remains valid, in ISO 8601 format.
For example: 2020-07-18T15:42:40.428+01:00
A unique ID to connect the shopper to a single checkout session that uses multiple API requests. You can use this to get insights into conversion rates.
The shopper's email address. We recommend that you provide this data, as it is used in velocity fraud checks. > Required for Visa and JCB transactions that require 3D Secure 2 authentication if you did not include the telephoneNumber.
The shopper's IP address. We recommend that you provide this data, as it is used in a number of risk checks (for instance, number of payment attempts or location-based checks).
Required for Visa and JCB transactions that require 3D Secure 2 authentication for all web and mobile integrations, if you did not include the shopperEmail. For native mobile integrations, the field is required to support cases where authentication is routed to the redirect flow. This field is also mandatory for some merchants depending on your business model. For more information, contact Support.
Specifies the sales channel, through which the shopper gives their card details, and whether the shopper is a returning customer. For the web service API, Adyen assumes Ecommerce shopper interaction by default.
This field has the following possible values:
- Ecommerce - Online transactions where the cardholder is present (online). For better authorisation rates, we recommend sending the card security code (CSC) along with the request.
- ContAuth - Card on file and/or subscription transactions, where the cardholder is known to the merchant (returning customer). If the shopper is present (online), you can supply also the CSC to improve authorisation (one-click payment).
- Moto - Mail-order and telephone-order transactions where the shopper is in contact with the merchant via email or telephone.
- POS - Point-of-sale transactions where the shopper is physically present to make a payment using a secure payment terminal.
The language for the payment. The value combines the two-letter ISO 639-1 language code with the ISO 3166-1 alpha-2 country code. For example, nl-NL.
When using Drop-in/Components, the specified language appears if your front-end global configuration does not set the locale.
Required for recurring payments. Your reference to uniquely identify this shopper, for example user ID or account ID. Minimum length: 3 characters.
Your reference must not include personally identifiable information (PII), for example name or email address.
The text to be shown on the shopper's bank statement. We recommend sending a maximum of 22 characters, otherwise banks might truncate the string. Allowed characters: a-z, A-Z, 0-9, spaces, and special characters . , ' _ - ? + * /.
The shopper's social security number.
Required for Adyen for Platforms integrations if you are a platform model. This is your reference (on balance platform) or the storeReference (in the classic integration) for the ecommerce or point-of-sale store that is processing the payment.
When true and shopperReference is provided, the payment details will be stored for future recurring payments.
The shopper's telephone number. The phone number must include a plus sign (+) and a country code (1-3 digits), followed by the number (4-15 digits). If the value you provide does not follow the guidelines, we do not submit it for authentication.
Required for Visa and JCB transactions that require 3D Secure 2 authentication, if you did not include the shopperEmail.
Required to trigger the authentication-only flow. If set to true, you will only perform the 3D Secure 2 authentication, and will not proceed to the payment authorisation.Default: false.
Set to true if the payment should be routed to a trusted MID.
Response
OK - the request has succeeded.
Contains additional information about the payment. Some data fields are included only if you select them first: Go to Customer Area > Developers > Additional data.
Donation Token containing payment details for Adyen Giving.
The reference to uniquely identify a payment. This reference is used in all communication with you about the payment status. We recommend using a unique value per payment; however, it is not a requirement. If you need to provide multiple references for a transaction, separate them with hyphens ("-"). Maximum length: 80 characters.
Adyen's 16-character string reference associated with the transaction/request. This value is globally unique; quote it when communicating with us about this request.
For payment methods that require a redirect or additional action, you will get this value in the /payments/details response.
If the payment's authorisation is refused or an error occurs during authorisation, this field holds Adyen's mapped reason for the refusal or a description of the error. When a transaction fails, the authorisation response includes resultCode and refusalReason values.
For more information, see Refusal reasons.
Code that specifies the refusal reason. For more information, see Authorisation refusal reasons.
The result of the payment. For more information, see Result codes.
Possible values:
- AuthenticationFinished – The payment has been successfully authenticated with 3D Secure 2. Returned for 3D Secure 2 authentication-only transactions.
- AuthenticationNotRequired – The transaction does not require 3D Secure authentication. Returned for standalone authentication-only integrations.
- Authorised – The payment was successfully authorised. This state serves as an indicator to proceed with the delivery of goods and services. This is a final state.
- Cancelled – Indicates the payment has been cancelled (either by the shopper or the merchant) before processing was completed. This is a final state.
- ChallengeShopper – The issuer requires further shopper interaction before the payment can be authenticated. Returned for 3D Secure 2 transactions.
- Error – There was an error when the payment was being processed. The reason is given in the refusalReason field. This is a final state.
- IdentifyShopper – The issuer requires the shopper's device fingerprint before the payment can be authenticated. Returned for 3D Secure 2 transactions.
- PartiallyAuthorised – The payment has been authorised for a partial amount. This happens for card payments when the merchant supports Partial Authorisations and the cardholder has insufficient funds.
- Pending – Indicates that it is not possible to obtain the final status of the payment. This can happen if the systems providing final status information for the payment are unavailable, or if the shopper needs to take further action to complete the payment.
- PresentToShopper – Indicates that the response contains additional information that you need to present to a shopper, so that they can use it to complete a payment.
- Received – Indicates the payment has successfully been received by Adyen, and will be processed. This is the initial state for all payments.
- RedirectShopper – Indicates the shopper should be redirected to an external web page or app to complete the authorisation.
- Refused – Indicates the payment was refused. The reason is given in the refusalReason field. This is a final state.
When non-empty, contains a value that you must submit to the /payments/details endpoint as paymentData.