Adyen's integration options stack in layers: the Checkout and Management APIs underneath everything, an API Explorer for firing test calls before writing a line of code, Adyen Web as the customizable front-end component library, Drop-in as its prebuilt single-component version, and a separate Terminal API for in-person card readers. We pick whichever layer actually matches what needs building, rather than defaulting to the heaviest option, and connect whatever the API returns to the rest of the business.
Drop-in is the fastest to ship, a single prebuilt component with the least customization available. Adyen Web gives field-level control over the checkout's look and behavior while Adyen's own iframe still holds card data for PCI scope. The Checkout API sits underneath both and can also be called directly for a fully custom flow that doesn't use either front-end library at all. The API Explorer lets you fire real test requests against your own sandbox credentials right in the browser, useful for checking a request or response shape before writing integration code. The Terminal API is a separate track entirely, for integrating physical card readers and point-of-sale hardware.
Defaulting to Drop-in because it's fastest to launch, then needing custom field validation or a non-standard checkout flow six months later, usually means tearing parts of it out and rebuilding rather than extending what's there. Going the other way, building fully custom against the Checkout API for a business that never actually needed that level of control, burns development time nobody gets back either. We look at what a business actually needs built before picking which layer of Adyen to build on, instead of assuming.
We check whether a business actually needs field-level checkout customization or just needs a working payment form fast, and build against whichever Adyen layer matches, instead of reaching for the most flexible option out of habit.
In-person transactions through the Terminal API and online ones through Checkout get reconciled into one transaction record, so a business running both channels isn't checking two separate reports to see the full day's sales.
Tell us which integration option you're on and what it's missing, and we'll figure out what changing that actually takes.
Which layer of Adyen you built on matters less than whether it's actually doing what the business needs now. Tell us where the current setup falls short, and if Adyen isn't even the system causing the friction, that's fine too; we build on top of whatever's running your business.
Let's talk →A tool in Adyen's developer docs for firing test API calls against your own sandbox credentials directly in the browser, useful for checking what a request and response actually look like before writing integration code.
Both. Adyen provides server-side libraries in several languages, including Node, Java, PHP, Python, and .NET, that wrap the REST API, plus the option to call the API directly if a library doesn't fit your setup.
A separate API track for integrating physical card readers and point-of-sale terminals, distinct from the Checkout API used for online payments.
Generated in Adyen's Customer Area, both API keys and client keys, with separate sets for the test and live environments.
Yes, Adyen provides a separate test environment with its own credentials, letting you build and test an integration before it ever touches real transactions.