Software development kit (SDK) is a packaged set of code libraries, documentation and tools that lets developers add a platform's features to their own application without writing the low-level integration. In payments it is provider code running inside a merchant's iOS app, Android app or web page, that wraps the provider's API, retries and error mapping. It renders the card form or wallet button and sends card details from the device straight to the provider, which returns a token, so raw card numbers never touch the merchant's servers and PCI DSS scope shrinks. Payment SDKs also bundle an EMV 3-D Secure SDK and device fingerprinting. Outdated versions create migration debt, since replacing an SDK means resubmitting the app.
SDK versus API
An application programming interface is the contract: endpoints, fields, responses. The SDK is client code that already speaks that contract, handling authentication headers, retries, error mapping and data models in a specific language such as Swift, Kotlin or JavaScript. A merchant can integrate against the API directly, but the SDK removes weeks of work and bakes in the provider's security choices.
How does a payment SDK work
A typical mobile checkout runs in four steps. The merchant's server creates a payment session with a secret key and passes a short-lived client token to the app. The SDK renders the card form or wallet button inside the app. Card details are sent from the device straight to the provider, which returns a payment token in place of the card number. The merchant's server then confirms the payment using that token.
Because the raw card number never touches the merchant's servers, the merchant's PCI DSS scope shrinks considerably. That single design choice is the main reason payment providers push SDKs over custom forms.
Features that live in the SDK
Modern payment SDKs bundle more than a card field. They include an EMV 3-D Secure SDK for in-app authentication (certified separately by EMVCo), Apple Pay and Google Pay buttons, device fingerprinting for fraud scoring, localized field validation and saved-card management. Some providers ship a SoftPOS SDK that turns an NFC-capable phone into a card-present terminal.
Risks: versions, size and dependency
An SDK is third-party code shipped inside the merchant's binary. Mobile apps update slowly, so a provider supporting 3DS2 protocol changes or new wallet rules must maintain several old SDK versions in parallel. Each SDK adds app size and permissions that app store reviewers inspect. Switching providers means replacing the SDK and resubmitting the app, which is one reason merchants adopt a provider abstraction layer.
Example: counting integrations in diligence
A PSP with 400 merchants on mobile might find that 30% still run an SDK version more than two years old. For a buyer, that number matters: deprecating the old version forces those merchants to ship app updates, and some will churn instead. Asking for the SDK version distribution across the merchant base is a quick way to size migration debt before a deal closes.
See also: In-app payment.