Choose an in-person integration
Match host platform, card interaction and deployment model before selecting a device API.
Choose by where the payment runs
Phone acceptance, a host-connected reader, a cloud terminal and an unattended service have different lifecycle and deployment requirements. A shared payment brand does not make their SDK callbacks, amount conventions or authentication interchangeable. Option Integration surface Suitable setting Tap to Pay on iPhone Native iOS SDK; Full flavour Contactless card/wallet acceptance on a supported iPhone. Tap to Pay on Android Native Android SDK; Full flavour Contactless acceptance with app attestation and NFC Activity handling. VP3350 Android/iOS Payment Device SDK A mobile or counter reader for chip, contactless and swipe. Lane/Series Customer-Present Cloud API Networked customer-facing display and PIN pad with an OS-independent backend. Self/Series Windows/Linux Payment Device SDK Kiosk, vending and other unattended machines. Axium SmartPOS Android SDK SmartPOS mode; optional on-device application Terminal-executed payments and a separately managed application estate.
Use the right reference layer
SDK packages contain platform API documentation and sample applications. Public guides explain setup and workflows. Cloud API references describe HTTP contracts. Direct Connect is a separate API-led terminal integration with certification requirements; it is not a shortcut around the SDK deployment process.
Start with the matching lifecycle
Check device model, connection method, merchant service enablement and the SDK release before testing. Then follow the phone, reader, cloud or unattended guide. In a mixed fleet, keep capability selection explicit so unsupported callbacks or fields are never sent to another platform.