Checkout icon

Migrate to Checkout API

Migrate your Classic API integration to Checkout API.

View source

Adyen no longer develops or updates our Classic API. We recommend that you migrate your integration to use the latest version of Checkout API for the following benefits:

  • A single integration to process all payment methods, including cards, bank-based, and alternative payment methods.
  • A simpler client-side integration with Drop-in/Components that is only available with the Checkout API.
  • Improved 3D Secure 2 authentication for payments. This includes simpler integration and the auto-authorization feature which reduces integration errors and failed payments.
  • An integration that adheres to latest security standards, like JSON Web Encryption (JWE) and JSON Web Signature (JWS), and offers your shoppers a more secure checkout process.
  • A simple, developer-friendly integration experience that handles many of the complexities of processing payments with less code complexity.
  • More specific error responses, for more efficient debugging.

When you migrate to Checkout API, changes affect:

  • Payment authentication
  • Authorization
  • Modification requests

The following do not change:

  • Reporting
  • Reconciliation
  • Webhooks
  • API authentication keys

Supported features

The following table shows the features supported in Classic API and Checkout API:

Feature Classic API Checkout API
Card payments Required Required
3D Secure 2 authentication Required Required
Drop-in/Components for web, mobile, and cross-platform Required
Hosted Checkout Required
Pay by Link Required
Donations with Adyen Giving Required
Creating orders that allow for partial payments Required
Usage analytics Required

How to migrate

Follow this guide to migrate to Checkout API v72 or later. The migration tasks that you must do depends on your type of Classic API integration.

Classic API integration type

The following table shows which migration tasks you must do, based on your integration type:

Integration type Description Tasks
Server-side only (API only) You use Classic API on your payment server, without any client-side SDKs or libraries from Adyen. Update your credentials, endpoints, and request objects.
Server-side with CSE or JWE You use Classic API with Client-Side Encryption (CSE) or JSON Web Encryption (JWE). In addition to changes to your payment and webhook servers, migrate your client-side encryption.
Server-side with CSE/JWE and features You use additional features like 3D Secure authentication or Tokenization. In addition, make updates for authentication and updates for Tokenization.
Integration with local and alternative payment methods You also use local payment methods and wallets. In addition, make updates for wallets and local payment methods.
Integration with a SOAP stack You use SOAP instead of REST. In addition, migrate from SOAP to REST.
Partner integration You use a technology partner. Contact your Adyen Account Manager to discuss your migration process.

During your migration process, you can continue to use your existing Classic API integration to process live payments.

Approaches to speed up your migration

You can use the following approaches to speed up your migration process:

Approach Benefits Trade-offs
Use Adyen API libraries. Faster server-side development, if you use Java, Node.js, PHP, .NET, Go, or Python. You must upgrade to the latest version of the library to support new features.
Migrate Classic API v68 endpoints to Checkout API v68, then upgrade to the latest version later. Minimal changes needed. API fields remain mostly the same. Changes only to URLs, authentication, and tokenization behavior. Migrating to an earlier version of Checkout API can require you to upgrade again, if it we deprecate it. We recommend migrating directly to the latest version.
Use the Sessions flow. Reduces integration complexity by making one required API request to handle payment, tokenization, and authentication. You must use Adyen Drop-in/Components.

Update settings in Customer Area

In your Customer Area, do the following:

  • Make sure that your API credential has the Checkout webservice user role.
    1. In your Customer Area, go to Developers > API credentials.
    2. From the list of users, select the user whose credentials you want to use to make Checkout API requests.
    3. In the Permissions section, in the Roles panel, under UNCATEGORIZED, select Checkout webservice role.
  • Turn on additional data that you want to get it in your Checkout API responses.
    1. In your Customer Area, go to Developers > Additional data.
    2. Select the fields that you want to get.

You continue to get the same reports in your Customer Area after you migrate to Checkout API.

Update your endpoints

The following tables show the base URL and endpoints that you must update from Classic API to Checkout API.

Base URL

Environment Classic Checkout
Test https://pal-test.adyen.com/pal/servlet/Payment/{VERSION} https://checkout-test.adyen.com/checkout/{VERSION}
Live https://{PREFIX}-pal-live.adyenpayments.com/pal/servlet/Payment/{VERSION} https://{PREFIX}-checkout-live.adyenpayments.com/{VERSION}

You can find your URL prefixes for the live environment in your live Customer Area:

  1. Go to Developers > API URLs.
  2. Select the endpoint that corresponds to the region that the account operates in. For example, if you are located in India, you must use a URL in the India (IN) region.

Endpoints

Change the following endpoints for each corresponding action.

Append each endpoint to the base URL.

Action Classic Checkout
Get a list of available payment methods. Not available. /paymentMethods
Make a payment. /authorise /payments
Authorize a payment after 3D Secure 2 authentication. authorise3d and /authorise3ds2 /payments/details
Refund a captured payment with its pspReference. /refund /payments/{paymentPspReference}/refunds
Cancel an authorization with its pspReference. /cancel /payments/{paymentPspReference}/cancels
Cancel an authorization without its pspReference. /technicalCancel /cancels
Capture a payment. /capture /payments/{paymentPspReference}/captures
If you do not know the status of a payment, refund or cancel the payment. /cancelOrRefund /payments/{paymentPspReference}/reversals
Update the amount of an authorized payment. Both synchronous and asynchronous flows are supported. /adjustAuthorisation /payments/{paymentPspReference}/amountUpdates
Create a payment session that handles payment, tokenization, and authentication in a single call. Not available. /sessions
Void a pending refund. Recurring/v68/voidPendingRefund Not available in Checkout API.
Delete stored payment details for a shopper or a specific stored payment method. Recurring/v68/disable The DELETE /storedPaymentMethods/{storedPaymentMethodId}
Get a list of stored payment details for a shopper. Recurring/v68/listRecurringDetails The GET /storedPaymentMethods
Save a token for stored payment details. /storeToken /payments with storePaymentMethod set to true
Create a token for stored payment details. /createToken POST /storedPaymentMethods
Get a token for stored payment details. /getToken GET /storedPaymentMethods
For redirect payment methods, send payment data after the redirect. Not available. /payments/details
Get the list of brands on a card. Not available. /cardDetails
Make a donation through Adyen Giving. Not available. /donations
Get a list of your active donation campaigns. Not available. /donationCampaigns
Create a Pay by Link payment link. Not available. /paymentLinks

Update your request objects

The request objects in Classic API and Checkout API are different. You must update the parameters for each object.

Data format

The required data format for Checkout API is JSON. If your Classic API integration uses XML data, you must change your request objects to JSON instead.

The following examples show the differences in the request objects between Classic API and Checkout API, in JSON format.

If you are not PCI-compliant, use one of Adyen's client-side solutions to encrypt card details.

After encrypting card details, make a payment request with the encrypted card details.

Parameters

Classic API Checkout API
amount amount
additionalData.card.encrypted.json paymentMethod
Not applicable. paymentMethod.type
Not applicable. paymentMethod.encryptedCardNumber
Not applicable. paymentMethod.encryptedExpiryMonth
Not applicable. paymentMethod.encryptedExpiryYear
Not applicable. paymentMethod.encryptedSecurityCode
Not applicable. paymentMethod.holderName
reference reference
merchantAccount merchantAccount
Not applicable. returnUrl

Classic API

To make a basic card payment with encrypted card details, include the following in the /authorise request:

Checkout API

To make a basic card payment with encrypted card details, include the following in the /payments request:

You must be PCI compliant to use unencrypted card details.

Make a request for a card payment with unencrypted card details.

Parameters

Classic API Checkout API
amount amount
Not applicable. paymentMethod.type
card.number paymentMethod.number
card.expiryMonth paymentMethod.expiryMonth
card.expiryYear paymentMethod.expiryYear
cvc paymentMethod.cvc
holderName paymentMethod.holderName
reference reference
merchantAccount merchantAccount
Not applicable. returnUrl

Classic API

To make a basic card payment, include the following in the /authorise request:

Checkout API

To make a card payment, include the following in the /payments request:

Make a request to store the shopper's card details.

Parameters

Classic API Checkout API
amount amount
additionalData.card.encrypted.json paymentMethod
Not applicable. paymentMethod.type
Not applicable. paymentMethod.encryptedCardNumber
Not applicable. paymentMethod.encryptedExpiryMonth
Not applicable. paymentMethod.encryptedExpiryYear
Not applicable. paymentMethod.encryptedSecurityCode
Not applicable. paymentMethod.holderName
reference reference
merchantAccount merchantAccount
shopperEmail shopperEmail
shopperIP shopperIP
shopperReference shopperReference
recurring Not applicable.
recurringProcessingModel recurringProcessingModel
Not applicable. storePaymentMethod
Not applicable. returnUrl

Classic API

To store the shopper's card details (in this example, for one-off payments), include the following in the /authorise request:

Checkout API

To store the shopper's card details (in this example, for one-off payments), include the following in the /payments request:

Make a request for a one-off payment with stored card details.

Parameters

Classic API Checkout API
amount amount
additionalData.card.encrypted.json paymentMethod.type
Not applicable. paymentMethod.encryptedSecurityCode
selectedRecurringDetailReference paymentMethod.storedPaymentMethodId
reference reference
merchantAccount merchantAccount
shopperEmail shopperEmail
shopperIP shopperIP
shopperInteraction shopperInteraction
recurringProcessingModel recurringProcessingModel
shopperReference shopperReference
recurring.contract Not applicable.
Not applicable. returnUrl

Classic API

To make a one-off payment with stored card details, include the following in the /authorise request:

Checkout API

To make a one-off payment with stored card details, include the following in the /payments request:

Make a request for a subscription payment with stored card details.

Parameters

Classic API Checkout API
amount amount
Not applicable. paymentMethod.type
Not applicable. paymentMethod.encryptedSecurityCode
selectedRecurringDetailReference paymentMethod.storedPaymentMethodId
reference reference
merchantAccount merchantAccount
shopperEmail shopperEmail
shopperIP shopperIP
shopperReference shopperReference
shopperInteraction shopperInteraction
recurringProcessingModel recurringProcessingModel
recurring Not applicable.
Not applicable. storePaymentMethod
Not applicable. returnUrl

Classic API

To make a subscription payment with stored card details, include the following in the /authorise request:

Checkout API

To make a subscription payment with stored card details, include the following in the /payments request:

Make a request for a payment with native 3D Secure 2 authentication. Use our native 3D Secure 2 Component to handle 3D Secure 2 authentication.

Parameters

Classic API Checkout API
amount amount
reference reference
merchantAccount merchantAccount
additionalData.card.encrypted.json paymentMethod.type
Not applicable paymentMethod.encryptedCardNumber
Not applicable. paymentMethod.encryptedExpiryMonth
Not applicable. paymentMethod.encryptedExpiryYear
Not applicable. paymentMethod.encryptedSecurityCode
Not applicable. paymentMethod.holderName
threeDS2RequestData.mobilePhone threeDS2RequestData.mobilePhone
threeDS2RequestData.deviceChannel channel
threeDS2RequestData.notificationURL Not applicable.
browserInfo browserInfo
shopperIP shopperIP
shopperReference shopperReference
Not applicable. billingAddress
shopperEmail shopperEmail
Not applicable. origin
Not applicable. returnUrl

Classic API

To make a payment for native 3D Secure 2 authentication, include the following in the /authorise request:

Checkout API

To make a payment for native 3D Secure 2 authentication, include the following in the /payments request:

Make a request for a payment with 3D Secure 2 redirect authentication. Use our redirect 3D Secure 2 Component to handle redirect 3D Secure 2 authentication.

Parameters

Classic API Checkout API
amount amount
reference reference
merchantAccount merchantAccount
additionalData.card.encrypted.json paymentMethod.type
Not applicable paymentMethod.encryptedCardNumber
Not applicable. paymentMethod.encryptedExpiryMonth
Not applicable. paymentMethod.encryptedExpiryYear
Not applicable. paymentMethod.encryptedSecurityCode
Not applicable. paymentMethod.holderName
browserInfo browserInfo
shopperReference shopperReference
shopperEmail shopperEmail
shopperIP shopperIP
Not applicable. billingAddress
Not applicable. channel
Not applicable. origin
Not applicable. returnUrl

Classic API

To make a payment with 3D Secure 2 redirect authentication, include the following in the /authorise request:

Checkout API

To make a payment with 3D Secure 2 redirect authentication, include the following in the /payments request:

Make a request for refund.

Parameters

Classic API Checkout API
amount amount
merchantAccount merchantAccount
reference reference
originalReference Path parameter: paymentPspReference

Classic API

To make a refund, include the following in the /refund request:

Checkout API

To make a refund, include the following in the /payments/{paymentPspReference}/refunds request:

Make a request to cancel a payment.

Parameters

Classic API Checkout API
merchantAccount merchantAccount
reference reference
originalReference Path parameter: paymentPspReference

Classic API

To cancel a payment, include the following in the /cancel request:

Checkout API

To cancel a payment, include the following in the /payments/{paymentPspReference}/cancels request:

Make a request to capture a payment.

Parameters

Classic API Checkout API
modificationAmount amount
merchantAccount merchantAccount
reference reference
originalReference Path parameter: paymentPspReference

Classic API

To capture a payment, include the following in the /capture request:

Checkout API

To capture a payment, include the following in the /payments/{paymentPspReference}/captures request:

Make a request for reversal. Use this when you do not know if a payment was already captured.

Parameters

Classic API Checkout API
merchantAccount merchantAccount
reference reference
originalReference Path parameter: paymentPspReference

Classic API

To reverse (cancel or refund) a payment, include the following in the /cancelOrRefund request:

Checkout API

To reverse (cancel or refund) a payment, include the following in the /payments/{paymentPspReference}/reversals request:

Make a request to adjust the amount of an authorized payment.

Parameters

Classic API Checkout API
modificationAmount amount
merchantAccount merchantAccount
reference reference
additionalData.industryUsage industryUsage
originalReference Path parameter: paymentPspReference
Not applicable. lineItems

Classic API

To adjust an authorized amount, include the following in the /adjustAuthorisation request:

Checkout API

To adjust an authorized amount, include the following in the /payments/{paymentPspReference}/amountUpdates request:

Make a request for a payment with third-party authentication. The parameters you include depend on the authentication data from the third party.

Parameters

Classic API Checkout API
amount amount
additionalData.card.encrypted.json paymentMethod
Not applicable. paymentMethod.type
selectedBrand
For co-badged cards.		 paymentMethod.brand
For co-badged cards.
Not applicable. paymentMethod.encryptedCardNumber
Not applicable. paymentMethod.encryptedExpiryMonth
Not applicable. paymentMethod.encryptedExpiryYear
Not applicable. paymentMethod.encryptedSecurityCode
Not applicable. paymentMethod.holderName
additionalData.scaExemption
For Cartes Bancaires.		 additionalData.scaExemption
For Cartes Bancaires.
additionalData.acquirerCode
For Cartes Bancaires.		 additionalData.acquirerCode
For Cartes Bancaires.
merchantAccount merchantAccount
reference reference
mpiData.cavv mpiData.cavv
mpiData.eci mpiData.eci
mpiData.dsTransID mpiData.dsTransID
mpiData.directoryResponse mpiData.directoryResponse
mpiData.authenticationResponse mpiData.authenticationResponse
mpiData.threeDSVersion mpiData.threeDSVersion
mpiData.cavvAlgorithm
For Cartes Bancaires.		 mpiData.cavvAlgorithm
For Cartes Bancaires.
mpiData.challengeCancel
For Cartes Bancaires.		 mpiData.challengeCancel
For Cartes Bancaires.
mpiData.riskScore
For Cartes Bancaires.		 mpiData.riskScore
For Cartes Bancaires.
threeDS2RequestData.threeDSRequestorChallengeInd
For Cartes Bancaires.		 threeDS2RequestData.threeDSRequestorChallengeInd
For Cartes Bancaires.
Not applicable. channel
Not applicable. shopperInteraction
Not applicable. recurringProcessingModel

Classic API

To make a payment with third-party authentication, include the following in the /authorise request:

The parameters you include depend on the authentication data from the third party.

Checkout API

To make a payment with third-part authentication, include the following in the /payments request:

The parameters you include depend on the authentication data from the third party.

Implement card brands check

To comply with co-badge card regulations, follow instructions to show co-badged cards.

Handle additional actions

The /payments response includes the payment status. If the response includes the action object, you must handle an additional action before the shopper can finish the payment.

What you must do depends on the action.type:

action.type Description Next steps
voucher The shopper gets a voucher which they will use to complete the payment later. 1. Show the voucher.
2. After the shopper completes the payment, get the webhook that includes the payment result.
qrCode The shopper scans a QR code and is redirected to an app to complete the payment. 1. Show the QR code.
2. After the shopper completes the payment, get the webhook that includes the payment result.
redirect The shopper is redirected to another website or app to complete the payment. Handle the redirect.
await The shopper completes the payment asynchronously, for example by using an app. 1. Inform the shopper that you are waiting for the payment.
2. Wait to get the webhook that includes the payment result.
sdk Applies for payment methods that require an SDK, for example WeChat Pay.
The type can sometimes include the payment method name, for example: wechatpaySDK.		 1. Invoke the SDK to trigger the switch to the payment method's app.
2. After the shopper completes the payment, get the webhook that includes the payment result.
threeDS2 The payment qualifies for 3D Secure 2 and will go through 3D Secure 2 authentication. Follow our 3D Secure 2 integration guides:

Show the voucher or QR code to your shopper

For voucher and QR code actions, you must use the information in the action object to show something to the shopper.

Handle the redirect

For redirect payment methods or redirect 3D Secure 2 authentication, you get action.type: redirect. You must redirect the shopper.

  1. Get the action.url from the response.

  2. Redirect the shopper to the action.url with the HTTP method from action.method.

    The shopper is redirected to a page where they need to take additional action, depending on the payment method.

    For security reasons, when displaying the redirect in an app, we recommend that you use SFSafariViewController for iOS or Chrome Custom Tabs for Android, instead of WebView objects.

    After the shopper completes the payment, they are redirected back to your returnUrl using the HTTP GET method. The URL includes a Base64-encoded redirectResult:

    GET /?shopperOrder=12xy..&&redirectResult=X6XtfGC3%21Y... HTTP/1.1
Host: www.your-company.example.com/checkout

  3. Get the redirectResult appended to the URL and pass it to your server. If the shopper completes the payment but doesn't return to your website or app, you do not get the redirectResult. Instead, you get the outcome of the payment in a webhook.

  4. From your server, make a POST /payments/details request, specifying:

    Parameter Description
    details Contains the URL-decoded redirectResult.

    The response includes the following:

    Parameter Description
    resultCode The current status of the payment.
    pspReference Our unique identifier for the payment.

Make updates for authentication

If your Classic API integration uses 3D Secure authentication, update it to use 3D Secure 2 on Checkout API.

Key improvements in Checkout API v67 and later:

  • Unified redirect flow: The shopper is redirected back from the issuer with the HTTP GET method instead of the HTTP POST method. This reduces errors caused by loss of cookies.
  • Authorization before redirect: The payment is authorized before the shopper is redirected back. You no longer need to make a /payments/details request to authorize the payment. This helps authorize payments even if there is an error during the redirect.
  • Simplified 3D Secure 2 flow: The fingerprint and challenge steps are combined under one action in the /payments response. You no longer need to make two /payments/details requests.
  • Higher authorization rates: Based on recent migrations, authorization rates for payments with 3D Secure in the EU region increase after migrating.

To migrate your 3D Secure implementation:

  1. Replace your Classic 3D Secure requests ( authorise3d and /authorise3ds2) with /payments/details.
  2. If you use a custom 3D Secure 2 implementation, migrate from the legacy Classic implementation to the Checkout custom 3D Secure 2 implementation.

For details on testing, refer to the 3D Secure 2 authentication testing guide.

Make updates for tokenization

If your Classic API integration uses Tokenization (for recurring payments), update how you handle stored payment details.

On Checkout API, the Recurring toggle in your Customer Area no longer functions to enable Tokenization. You must specify the type of shopper interaction and recurring processing model in each payment request.

To migrate your tokenization:

  1. Update the endpoints that you use to create and manage tokens.
  2. Update your payment requests to create tokens to store payment details, including the shopper interaction and recurring processing model.
  3. Update your payment requests to make payments with tokens, including the shopper interaction and recurring processing model.
  4. (Optional) Import stored payment details.
  5. Enable the tokenization webhook to manage your token lifecycle.

The following table shows corresponding endpoints:

Classic API Checkout API
post /disable delete /storedPaymentMethods/{storedPaymentMethodId}
post /listRecurringDetails get /storedPaymentMethods

The following table shows corresponding parameters:

Classic API Checkout API
recurring.contract shopperInteraction and recurringProcessingModel

Make updates for wallets and local payment methods

If your Classic API integration supports wallets or local payment methods, you must update the payment flow for Checkout API.

Google Pay

The transaction variant has changed:

Classic API Checkout API
paywithgoogle transaction variant googlepay transaction variant

Use Google Pay on Checkout API v67 or later. The flow is different from Classic API. Refer to the Google Pay API-only integration guide.

Apple Pay

PIX

Gift cards

  • Classic API allowed multi-PSP gift card payments.
  • On Checkout API, if a gift card does not cover the full amount, you must process partial payments using the Orders API.
  • We recommend that you use /balanceCheck when a shopper adds a gift card, and then authorize all partial payments at once when the shopper selects pay. Refer to the gift cards integration guide.

Migrate client-side encryption

If your Classic API integration uses Client-Side Encryption (CSE), you must replace it. It does not work with Checkout API.

You can replace CSE with the following options:

Option Description
Card Component (recommended) Use the Card Component for lower PCI-DSS compliance requirements and a quick go-live.
Custom Card Component Use the Custom Card Component for lower PCI-DSS compliance requirements with more UI flexibility.
JWE on Checkout API Use JSON Web Encryption (JWE) for a fully custom client side with encrypted card data.

Migrate webhooks

Standard webhooks have not changed because they use v1. Migration is minimal for standard webhooks.

To migrate your webhooks:

  1. If you use SOAP webhooks, migrate them to the JSON format. Refer to the webhook types documentation.
  2. If you use tokenization, add tokenization webhooks to manage your token lifecycle.
  3. If you use a differently structured AUTHORISATION webhook, review the old structure and compare it with the current structure.

Update security settings

On both Classic API and Checkout API, you authorize API requests with an API key or basic authentication credentials.

Your setup What you must do
You use Adyen API libraries. Generate and provide the credentials for your chosen authentication type.
You use Adyen Drop-in/Components. Set up client-side authentication with a client key and allowed origins.

Assess the impact to your PCI compliance

The impact on your PCI compliance depends on your integration type:

Integration type Impact
API-only to API-only, custom client-side interface No impact on PCI compliance.
API-only to API-only, with Components Using Adyen client-side SDKs can lower your PCI DSS scope. Refer to the PCI DSS compliance guide. We no longer support Client Side Encryption (CSE). Replace it with JWE to encrypt payment details.
Accessibility You can use Adyen Drop-in/Components to comply with accessibility directives. Refer to the accessibility documentation.

Make changes to enhanced scheme data

If your industry uses enhanced scheme data (for example, airline or lodging data), you must update how you include it in your API requests. In Checkout API v71 or later, the parameters for such data have moved from the additionalData object to the root-level enhancedSchemeData object.

Classic API Checkout API v71 or later
additionalData.enhancedSchemeData enhancedSchemeData
additionalData.airline enhancedSchemeData.airline
additionalData.enhancedSchemeData.customerReference enhancedSchemeData.levelTwoThree.customerReferenceNumber

Some other data that you include in additionalData can have a corresponding root-level parameter in the Checkout API. If you identify such parameters, update your requests to use the root-level parameter instead.

Request additional configuration (optional)

Adyen supports some features that require additional configuration that you cannot do yourself. If you previously required Adyen to help you set up a feature or you encounter a new feature that you cannot enable yourself, contact our Support Team.

Optimize performance of your payments

After you migrate to Checkout API, you can optimize the performance of your payments:

Area Recommendation Impact
Conversion Collect as much information as possible about the shopper and their purchase in your payment request. Enable Adyen Uplift to reduce risk and costs. Up to +6% higher conversion on payments.
Conversion, cost, shopper experience Use Adyen Drop-in/Components with sessions on the server. Lower PCI scope, higher conversion, fewer payment-related errors, easier to unlock new payment methods.
Cost Use Adyen server-side API libraries to reduce development time. Lower development time for your engineering team.
Engagement, conversion Add shopper loyalty programs with Checkout tokenization. Shopper retention, personalized offers, increased conversion.
Fraud, costs Collect risk-related data for better fraud management with the Adyen risk engine. Reduced chargebacks, blocked fraudulent payments.

Handle new errors

Make changes to your server's business logic to handle errors in Checkout API responses.

A Classic API integration can get only generic error codes.

A Checkout API integration can get all error codes.

Use our API library

When you migrate to Checkout API, we recommend that you use one of our API libraries, available in many languages, to help you make requests.

If you use an API library for your Classic API integration, upgrade your API library version to get the latest changes for Checkout API.

Test your updates

Follow our guide to test your online payments integration.

Go live

You can test your Checkout API integration in the live environment by processing some live payments. While testing in the live environment, you can continue to process payments with your Classic API integration.

After you verify that Checkout API meets your requirements in the live environment, we recommend that you stop using the Classic API integration.

See also