Adyen's point-of-sale hardware, physical card readers and terminals, processes in-person payments through the same Terminal API and backend as its online Checkout, so a card tap at the counter and a card payment online both land in the same underlying system. That shared foundation is real. What still needs building is everything a business running several locations or devices actually needs on top of it: provisioning terminals without configuring each one by hand, catching a device that's gone offline before a store finds out the hard way, and reporting broken out by location instead of one combined number.
The Terminal API lets your own software send a payment request to a physical terminal and get the result back, the same general pattern as an online Checkout call, just aimed at a physical device instead of a browser or app. Terminals support the local payment methods and card networks relevant to wherever they're deployed, with local currency and tax handling built in.
Because terminal and online transactions both run through Adyen's core processing, a business accepting payments in person and online already gets one underlying settlement system instead of two separate ones to stitch together.
One terminal at one counter is simple to set up by hand. A retail chain running dozens or hundreds of them across multiple locations is a different problem entirely: each device needs provisioning, a software update rollout, and a way to tell when one's gone offline before a store manager calls in confused about why the card reader stopped working.
Adyen's own reporting treats terminal transactions as part of the merchant account's overall activity. Splitting that by individual store or register, so a location manager sees their own numbers rather than the whole chain's, is a reporting layer that has to be built on top rather than something the dashboard hands you by default.
A new location's terminals get configured and activated automatically against your existing merchant and store setup, instead of someone manually working through Adyen's dashboard for every single device.
A terminal that drops offline or stops processing gets caught and reported to whoever manages that location right away, instead of the store finding out when a customer's card gets declined and nobody can explain why.
Tell us how many locations and devices you're running, and where the manual setup or monitoring actually eats the time. That's usually where it's worth starting.
A card reader at the counter and a checkout online share the same backend by design. Whether that turns into one clean, store-level view of your business, or stays as separate numbers someone pieces together, depends on what's built around it. Tell us what that currently looks like, and if terminals aren't where your real gap is, that's fine too. We automate whatever's manual, any system, Adyen or otherwise.
Let's talk →A separate API track from Adyen's online Checkout API, built specifically for sending payment requests to physical card readers and point-of-sale terminals and getting the result back, while still running through the same underlying Adyen processing as online payments.
Yes, a single merchant account can have terminals deployed across as many locations as needed. Keeping each location's transaction data cleanly separated for reporting generally takes custom work beyond Adyen's own default view.
Each physical terminal needs its own provisioning and activation, but it runs against the same merchant account and core processing as your online Checkout, rather than being a fully separate system.
Adyen's own dashboard shows device status, but by default nothing proactively alerts a store manager the moment a terminal drops offline. That kind of alerting has to be built on top if you want to catch it before a customer's card gets declined.