APIs Overview

Payment APIs

The Payment APIs are sectioned in three APIS:

Checkout API

Use this API to initiate an authentication session for payment checkout.

Checkout API →

S2S APM API

Use this API to create a payment via SALE request in the Payment Platform.

APM Sale API →

S2S Card Card API

Use this API for SALE request to perform immediate payment (SALE) or authorization only (AUTH) transactions. API to create a payment via SALE request in the Payment Platform.

Card Sale API →

About the APIs

The Payments API is Resource oriented, relying on REST principles. Our APIs accept and respond with JSON.

warning

Checkout protocol requires requests to be sent using JSON formatting with the following content type:
Header: Content-Type: application/json

Postman collection

Download and test the Checkout Postman Collection:

Postman collection →

Authentication

The Payments API does not use HTTP authentication headers. Every request is sent by POST and is authenticated by two values in the request body:

• merchant_key (or client_key on the S2S protocols) identifies your account.
• hash is a signature computed from the request fields and your password.

The password itself is never transmitted. It is only an input to the hash. See Hash signature for the per-protocol formulas, and Quickstart for where to find your merchant key and password.

Environments

The Payment APIs are available in two environments:

• Sandbox: Use the Sandbox environment for development and testing.
• Production: Use the Production environment for production use.

Use the API domain to make requests to the relevant environment.

Environment	API Domain
Sandbox	- Checkout https://checkout.your_sandbox_url/api/v1/session - API https://api.your_sandbox_url.com.secure.payinspect.com/post
Production	- Checkout https://checkout.your_production_url/api/v1/session - API https://api.your_production_url.com.secure.payinspect.com/post

Idempotency

The merchant order.number is not unique in the system.

Use a unique order.number per payment attempt in order to distinguish payment intent from another. The order.number appears only once in callbacks.

Otherwise, you have the following options to ensure idempotency:

• Use ID to list all attempts made by a customer on the payment page.
• Limit attempts to 1 (in admin panel > Protocol mapping > Maximum number of declines > 1)