An application programming interface (API) exposes a list of operations, often called endpoints, each with defined inputs and outputs. A payment API might offer endpoints to create a payment, capture it, refund it and list transactions. Everything behind the endpoint, whether a card network connection, a ledger or a fraud engine, stays hidden. That separation lets the provider change its internal systems without breaking the thousands of businesses that integrate with it.

Most modern web APIs follow the REST API style, using HTTP methods such as GET and POST and exchanging JSON. Older banking and enterprise systems often still use SOAP API interfaces built on XML.

A request has four parts: the endpoint address, the method, headers carrying authentication such as an API key or OAuth token, and a body with the data. The provider authenticates the caller, validates the input, performs the action and returns a status code and a response body.

Consider an online shop charging €49.90. Its server sends a POST request to the payment provider's payments endpoint with the amount, the currency and a card token. The provider sends the authorization to the acquirer and card network, then returns a response with a payment ID and the status "authorized" in under two seconds. For events that happen later, such as a chargeback weeks afterwards, the provider calls the shop back through a webhook.

The API is the interface itself: the endpoints and the rules for calling them. A software development kit (SDK) is a package of code, usually for one programming language or mobile platform, that wraps the API so developers do not have to build raw HTTP requests. An iOS payments SDK, for example, calls the same API underneath but also provides ready-made card forms and handles 3-D Secure screens. Any SDK depends on an API; an API can be used without any SDK.

Nearly every step of a modern payment runs through APIs: gateways accepting payments, orchestration layers routing them, issuer processors approving card transactions, and banking-as-a-service providers opening accounts. In Europe, PSD2 requires account servicing payment service providers to give authorised account information service providers (AISPs) and payment initiation service providers (PISPs) access to payment accounts, and banks meet that duty mainly through dedicated open banking APIs.

For a payment company, its API is often the product. Buyers look at uptime history, versioning policy, how many merchants run on deprecated versions, and whether regulated activities exposed through the API match the licence the company actually holds.