Why you get an app and an API — never an SDK
Because the SDK model makes payment problems your problems.
When a card reader ships with an SDK, the payment code moves into your application — and with it, a set of responsibilities you never asked for. Card-handling security becomes something your build has to think about. SDK updates become your release work. A reader misbehaving at a merchant's counter becomes your support ticket, even though nothing in your code caused it.
What the app model hands you instead
With the Kuvex KReader, there is no SDK. A complete, sealed application owns the device; your software talks to it locally or through the cloud API, and everything below that line is ours:
- PCI security, contained. Card data lives and dies inside the certified payment app. Your software never touches it — which keeps your security surface, and your compliance burden, as small as it can be.
- Zero maintenance. The payment core iterates and upgrades itself. New card rules, new certifications, new firmware — they arrive at the device without a line of work on your side.
- Automated troubleshooting. Device health, diagnostics and fault recovery are built into the app and managed remotely. Most problems fix themselves before anyone files a ticket.
- Stable hardware. One sealed unit — app and device tested and shipped together — behaves the same on the thousandth day as the first.
- Truly turnkey. Install once. From then on your integration is an API call, and the machine is our problem.
An SDK gives you code and keeps the responsibility. An app takes the responsibility and gives you an interface. For a software company, that's the entire difference.