Getting started

To streamline integration and maintain consistency with existing workflows, we’ve developed an API that implements the same interface as Praxis. This means the procedures for initializing payments and handling webhooks remain unchanged. If you're already familiar with Praxis, you'll find this API easy to work without the need to modify your current integration logic.

API credentials

Before you can start using Praxis-like API, you must first obtain your API credentials.

Parameter	Comment
Cashier API URL	Base Cashier API URL, which represents domain where API requests should be sent. Supports different environments.
Merchant ID	Merchant ID, should be received from Cashier Support Team.
Application Key	ID of your application (website), should be received from Cashier Support Team.
Merchant Secret	This value is a Merchant Secret, should be received from Cashier Support Team and never be published publicly or passed as request parameter in raw format. Used for calculating/validation signature hash.

Environments:

Environment	Cashier API Base URL
Sandbox	https://api.cashier-sbox.fintech360.dev
Production	https://api.cashier.fintech360.tech

Please contact your account manager or Cashier support team to receive your credentials. Once received, store them securely and use them in all authorized API calls.

Authorization

Before you can send requests to the API, proper authorization is required to ensure secure and authenticated communication. This process verifies your identity and grants you access to API endpoints. Follow the steps below to authorize your requests and begin interacting with the system.

General authorization flow

Signature value is passing in Gt-Authentication header in API request, value for this header should be calculated by next algorithm

1. Retrieve special request parameters from your request; For every request type there are different fields, which are needed for signature calculations.
2. Concatenate values of those parameters in one string.
3. Concatenate received string with Merchant Secret at the end (refer to API credentials section for more details about this key, do not mix it up with Application Key described in table).
4. The resulting temporary variable is then hashed using the SHA-384 algorithm, producing the hash variable. This hash is used as value for Gt-Authentication header.

Init Payment Request Authorization

Please find the list of required parameters in Init Payment Request used in signature calculation, all others could be skipped.

Parameter	Commentary
merchant_id	Merchant ID provided by Cashier Technical Support team
application_key	Application Key provided by Cashier Technical Support team
timestamp	Unix timestamp (Epoch time): Number of seconds (or milliseconds) since January 1, 1970 (UTC). Example: 1716735600
intent	Intent type, currently only payment value is supported
cid	Customer ID in merchant's system
order_id	Payment ID on merchant’s side

Example:

1. We’re using the following request body to sign in:

{
   "merchant_id":"MerchantID",
   "application_key":"TestApplicationKey",
   "intent":"payment",
   "currency":"USD",
   "amount":100,
   "cid":"1",
   "payment_method":null,
   "order_id":"test-1560610955",
   "variable1":"your variable",
   "variable2":"if one variable is not enough, you can pass up to three",
   "variable3":null,
   "version":"1.3",
   "timestamp":1590611635
}

2. In that case, the concatenated string will be:

MerchantIDTestApplicationKey1test-15606109551590611635

3. Let’s assume we have Merchant Secret: SecretKey

In that case , concatenated string with secret key before encoding will look like:

MerchantIDTestApplicationKey1test-15606109551590611635SecretKey

4. After SHA-384 encoding this string would look like:

C7ed98ad580a670e117085fb80759599df3efab85956d3d14311d5337b7fa42ab38d62b7c3a6b47a7ac9f46db7099ca5

5. In the end, the request header will look like:

Gt-Authentication: C7ed98ad580a670e117085fb80759599df3efab85956d3d14311d5337b7fa42ab38d62b7c3a6b47a7ac9f46db7099ca5

Init Payment Response authorization

To ensure data integrity and authenticity, our API includes a digital signature in every response. This signature allows you to verify that the data was returned by our system and has not been tampered with.

Here's how you can verify the signature:

1. Extract the signature from the response (found in a header Gt-Authentication).

2. Recreate the signature on your side by using the same algorithm and secret key that was used to generate it (e.g., HMAC with SHA-384).

   Please use required fields in the table below as signature payload:

Parameter	Commentary
status	Response status code.
redirect_url	Redirect URL received after initiating payment session.
timestamp	Unix timestamp (Epoch time): Number of seconds (or milliseconds) since January 1, 1970 (UTC). Example: 1716735600
customer.customer_token	customer_token field value received from Customer object response

3. Compare your generated signature with the one provided in the response.
   • If they match, the response is valid and trusted.
   • If they don't match, the response may have been altered.

Always perform signature validation before processing any sensitive data from the API to ensure security and data integrity.

Webhook authorization

Whenever a payment status changes, our system will send a webhook notification to your URL which was passed in the request to initiate payment. Always verify the signature before processing the webhook data to maintain security and trustworthiness.

Signature hash could be found in header Gt-Authentication in webhook request.

Verification algorithm is the same, except another set of fields used in signature payload calculation.

Parameters used for signature hash:

Parameter	Commentary
merchant_id	Merchant ID provided by Cashier Technical Support team.
application_key	Application Key provided by Cashier Technical Support team.
timestamp	Unix timestamp (Epoch time): Number of seconds (or milliseconds) since January 1, 1970 (UTC). Example: 1716735600
customer.customer_token	customer_token field received from Customer object.
session.order_id	Transaction order ID received from Session object.
transaction.tid	Transaction ID received from Transaction object.
transaction.currency	Original currency of the transaction from Transaction object.
transaction.amount	Original amount of the transaction in minor units from Transaction object.
transaction.conversion_rate	Conversion rate applied from Transaction object.
transaction.processed_currency	Currency in which the transaction was processed from Transaction object.
transaction.processed_amount	Final amount after processing in minor units from Transaction object.

Example:

1. We have the following webhook request:

{
   "merchant_id":"TestMerchantId",
   "application_key":"TestKey",
   "conversion_rate":1.000000,
   "customer":{
      "customer_token":"87cfb23a8f1e68e162c276b754d9c061",
      "country":"GB"
   },
   "session":{
      "auth_token":"8a7sd87a8sd778ac961062c6bedddb8",
      "intent":"payment",
      "session_status":"created",
      "order_id":"560610955"
   },
   "transaction":{
      "tid":756850,
      "transaction_id":"13348",
      "currency":"EUR",
      "amount":100,
      "conversion_rate":1.000000,
      "processed_currency":"EUR",
      "processed_amount":100,
      "gateway":"s-pTSZyK23E1Ee5KZpcNbX_aFl0HuhQ0",
      "status_details":"Transaction approved"
   },
   "version":"1.3",
   "timestamp":1590611635
}

2. Concatenate the required parameter values:

   TestMerchantIdTestKey87cfb23a8f1e68e162c276b754d9c061560610955756850EUR1001.000000EUR1001590611635

3. Add secret key to end of concatenated string. Assume Secret Key: SecretKeyTest.

   TestMerchantIdTestKey87cfb23a8f1e68e162c276b754d9c061560610955756850EUR1001.000000EUR1001590611635SecretKeyTest

4. Hash this string with SHA-384 algorithm:

   4d43620734dcae453cd947ab815069b16915dc8fcd9ece5bfcf5a120e06d1a720e5b09b3386d126a68e55ce2c143cce8

5. Compare calculated value with received one from header Gt-Authentication

Please refer to the Webhook section for detailed information about webhook request parameters.