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 GET
     retrieves resource details. 
    HTTP POST
     submits a request, such as payment authorization, that changes the state of the resource. HTTP status code 200 indicates a successful 
    GET API
     call. Other HTTP status codes, such as 400 and 502, indicate unsuccessful calls. HTTP status code 201 indicates a successful 
    POST API
     call. 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 value 
    application/hal+json
    , the payment API returns a response with HAL links. When the HTTP Accept header has the value 
    application/json
    , the API returns plain JSON objects without HAL links.