With payment services, you can process payment cards (tokenized or non-tokenized), digital payments such as Apple Pay and Google Pay, and customer ID transactions. You can process payments across the globe and across multiple channels with scalability and security. An extensive list of payment cards and a wide choice of gateways and acquiring banks are supported through one connection.
To learn more about REST APIs, see Getting Started with the REST API .
For details about authentication, see:
For field-level descriptions and request/response examples, see the REST API Reference .
eCommerce Payments 101
Payment APIs reflect the following RESTful API concepts:
- Resources—these provide access to payment functions such as authorizations and captures. A resource’s unique ID provides access to an individual payment object such as an authorization.
- HTTP verbs and status codes—HTTP GETretrieves resource details.HTTP POSTsubmits a request, such as payment authorization, that changes the state of the resource. HTTP status code 200 indicates a successfulGET APIcall. Other HTTP status codes, such as 400 and 502, indicate unsuccessful calls. HTTP status code 201 indicates a successfulPOST APIcall. Other HTTP status codes, such as 400 and 502, indicate unsuccessful calls.
- Hypermedia links for follow-on actions—JSON Hypertext Application Language (HAL) informs the follow-on actions performed on a resource. For example, when a payment capture follows a successful payment authorization, and the HTTP Accept header is either not found or has the valueapplication/hal+json, the payment API returns a response with HAL links. When the HTTP Accept header has the valueapplication/json, the API returns plain JSON objects without HAL links.