Payment API

What a Payment API is

An application programming interface, or API, is a set of rules that lets software communicate. A payment API gives your website, app, or business system a way to request payment services, such as processing a transaction, checking its status, issuing a refund, or managing recurring billing.

The API connects your software to a payment service. It does not replace the payment processor, card network, or issuing bank that handles the transaction. For example, your checkout can send a payment request for a $100 order (illustrative) and receive an approval or decline and a transaction ID to attach to the order.

A payment API controls how your software handles payment requests, but it does not make your processor’s markup non-negotiable.

How a payment API works

Your application sends a request with details such as the amount, currency, payment method, and order reference. The payment service processes the request and returns a status. One documented API, for example, returns an authorized status for an approved payment, while a request that needs additional authentication returns a response that sends the customer through a redirect.

Your software uses that response to decide what happens next: confirm the order, show an error, or wait for authentication. An idempotency feature lets an application retry a request without creating a duplicate payment. In one documented implementation, a card authorization expires after 7 days, so the business must capture it before then or the hold is released.

What it means for your business

A payment API can connect checkout to order management, refunds, saved payment methods, or recurring billing. The benefit is operational control: your systems can update an order from the payment response instead of relying on staff to re-enter payment results. A poorly handled decline or delayed authentication can leave an order unpaid while your system shows the wrong status.

Security depends on how payment details move through your setup. Tokenization replaces sensitive card data with a token, reducing repeated transmission of the card number. Some APIs restrict sending full card details to merchants with PCI compliance level SAQ D. Using an API does not, by itself, make your business PCI compliant; PCI DSS v4.0.1 is the current version as of 2026.

What it means for your costs

A payment API does not set your card rates. Card costs have three layers: interchange paid to the issuing bank, network fees paid to the card network, and your processor’s markup. Only the markup is negotiable. The API documentation reviewed here does not state a standard API fee or a fee amount, so do not assume an API-related charge is a network fee.

For B2B card sales, sending complete line-item details through an API can support Level 2 or Level 3 processing and qualify the transaction for lower interchange categories. That depends on the transaction meeting the applicable data requirements. Compare the processor markup and any separate service charges on your billing records, rather than treating the API itself as a rate.

What you can actually change

1. 01
   Map the payment flow. Identify which system sends the payment request and which system receives the approval, decline, or authentication status. Confirm that a declined payment does not mark an order as paid.
2. 02
   Protect card data. Use tokenized payment details where your setup supports them, and confirm which systems handle card data for your PCI DSS assessment.
3. 03
   Review the charges. Separate interchange and network fees from processor markup and any software or service charges. Compare markup across your processing volume before accepting a proposed rate change.

Frequently asked questions