Get the latest features
We no longer develop the classic Checkout SDK integration. We actively develop our latest integration, which uses:
- Drop-in and Components on the client side.
- Checkout API on the server side.
We are building new features, making security improvements, and optimizing performance. For example, our latest integration supports native 3D Secure 2, which the classic Checkout integration didn't.
With weekly release cycles for the Checkout API, you immediately get access to new payment methods, new features, and fixes.
Offer the latest local payment methods
New local payment methods are exclusively supported by the Checkout API, meaning they are available in Drop-in and Components integrations, but not through the classic Checkout SDK.
This means that if you use a Drop-in or Components integration, you can easily offer your shoppers the option of paying with their latest payment method of choice. In contrast, if you use the classic Checkout SDK, you may not have access to the same range of payment options.
Co-branded cards compliance
On 27 May 2021, Visa updated their regulations which require merchants to:
- Always show the brands available on co-branded cards.
- Not override a card brand that the shopper has selected.
Visa announced stricter enforcement of this regulation starting 1 November 2021.
The classic Checkout SDK does not have support for this regulation, so if you accept co-branded Visa cards using the classic Checkout SDK, you are exposed to non-compliance assessments from Visa.
Higher authorization rate
Our data indicates that Drop-in and Components integrations have authorization rates that on average are 3.3% higher than those of the classic Checkout SDK.
One possible reason for this is that the classic Checkout SDK's payment form lacks built-in validation for input fields. This means that validation only occurs after the payment details have been submitted, which can result in a declined transaction if any of the information is invalid.
Drop-in and Components integrations have built-in validation for the payment form, which give shoppers immediate feedback to help them correct any input errors. This ensures that shoppers can only submit their payment if all validations are successful, eliminating declined transactions caused by shopper errors.
For example, Drop-in and Components validation includes checking if:
- The card number is valid.
- You accept the card brand the shopper wants to pay with.
- The required address fields are filled in, based on country requirements.
Improved support and monitoring
A classic Checkout SDK integration is harder to troubleshoot, so resolving issues takes longer than for Drop-in or Components.
Improved monitoring for the Checkout API allows our support team to more easily reproduce and investigate issues. The architecture of Drop-in and Components also makes troubleshooting easier which together allow our support team to resolve issues faster.
Offer donation options
The classic Checkout SDK integration does not support our donations feature, Adyen Giving. With the newer online payments integrations, you can offer your shoppers the option to donate at checkout. For web integrations, Adyen Giving is available:
- As a pre-built Component rendered on the confirmation page.
- As an API-only integration.
Get Google Play store support
The classic Checkout SDK for Android uses an Android API that the Google Play store no longer supports. If you use the classic Checkout SDK for Android and upload your app to the Google Play store, it will be rejected.
Our newer integration options are all supported by the Google Play store.