SDK (Software Development Kit)

A software development kit, or SDK, is a package of code a provider ships so that other developers can build against its service without starting from scratch. In payments it usually wraps the provider's own interface. It handles the parts every build needs: signing requests, retrying safely, reading responses, and putting up a card form that behaves on a phone. The work it saves is not glamorous, and it is work that can go wrong when written from scratch.

An SDK is not the service. Under it sits an application programming interface, and the SDK is a layer of convenience over that. This matters when something breaks, because the question becomes whether the fault is in your code, the SDK, or the service behind it. It can matter in cash terms too: an SDK can sometimes be swapped without changing providers, and where an integration sits behind an abstraction layer, a provider can be changed without rewriting all the code that touches it.

What A Payments SDK Usually Contains

Four things turn up in most of them. The first is a client for the provider's interface, so calls are made correctly. Ready-made screen parts, usually a card field or a whole payment sheet. Helpers for the awkward bits, such as swapping a card for a token or handling a return from a bank app. And a sandbox mode, so a team can build without moving money. What is in the box varies enough between providers to be worth a look.

Server Side And Client Side Are Different Things

The split decides where your risk sits, and a server side SDK runs on your own machines, holds secret keys and does the work the customer does not see. A client side SDK runs in the browser or the app, in a place the customer controls, and should not hold a secret key. Mixing the two up is how keys end up published in a mobile app, which is a class of incident that recurs with some regularity.

Why It Can Narrow The Audit Scope

The main reason to use a provider's own card fields is that the card number does not land on your servers. The SDK collects the data and passes it straight to the provider, which is the same logic behind a hosted payment page and has a direct effect on how much of your estate falls within scope. The current rules sit in the PCI Security Standards Council document library. They are revised, so the version in force is the one to work from.

The Version You Are On Matters

An SDK is a dependency, and dependencies age. Providers retire old versions, card schemes push changes twice a year, and a version that was current at launch drops out of support with nobody on the team noticing. The awkward cases are mobile apps, where the version in a customer's hand is the one they last updated to, which may be a long way behind what you shipped. Planning for that is easier than reacting to it.

Where SDKs Hide Problems

Convenience has a cost of its own. An SDK that retries on its own can turn one payment into two if it retries an unknown state instead of checking it. A gateway timeout is exactly the case where that goes wrong. Error handling is the other common gap. An SDK that swallows a detailed provider error and hands back something vague leaves a support team with nothing to work from.

Standards Reduce The Lock-In

Where a provider builds to a published standard, the SDK becomes less of a commitment. The UK Open Banking API standards are a good case in payments. They turned what would have been many bank-by-bank builds into one shared rulebook. Outside standardised areas, an SDK tends to carry a provider's own shape, and swapping it later costs more than the code suggests.

Testing It Like Any Other Dependency

An SDK deserves the same treatment as code your team wrote. Walk the failure paths on purpose during user acceptance testing: a timeout, a declined card, a session that ran out, and a customer who walks away from a bank redirect halfway through. Pin the version instead of letting it float, so an upgrade is a decision. And keep a note of what the sandbox does differently from production, because that gap is where surprises live.

Picking One And Living With It

Check what the SDK actually covers before assuming it covers your case. Confirm the split between server side and client side, and keep secret keys off anything a customer can open. Pin versions and put upgrades on a schedule, instead of waiting for a retirement notice. Test the failure paths, not just the happy one. Keep the underlying interface in view, since you may need it when the SDK does not do what you want. And check whether the provider's errors survive the SDK intact. This piece on hosted fields against a direct API weighs the choice, and this one on integrating several providers through one interface covers the wider build.

‍