Skip to main content

Signature Generation

A signature is a mandatory header if using APIs. We are generating signatures using two details, the public API KEY and private SECRET KEY. There is a third PUBLISH KEY as well which is used for specific modules, but not requried for signature generation. Sample Example: Let partner Api key: tb_test_q47Wqf04e1sIZu22kVwWBrDncigOkIPN Let partner Secret key: tb_test_CT5u9ZeNMBEL884g6gP3 Step 1: Create a new string by concatenating the API key and secret key with a colon in between. In our sample, the string becomes "tb_test_q47Wqf04e1sIZu22kVwWBrDncigOkIPN:tb_test_CT5u9ZeNMBEL884g6gP3" Step 2: Create a signature using the above string using SHA-512 Algorithm. In our sample, the signature becomes 7ae85bcc8d0af6ceacd271da52d22d1fa091733b891ff133169ef959647f5d23232c6b6709150f1cbbabc5d2a815cb05b91448c3c3eabc9447343b689eba7606 Below are different examples for different languages
Step 3: Pass the public API KEY and the generated signature in the headers like below.

Extended Signature Generation

An extended signature is an optional authorization mechanism. To enable this feature, the partner will need to enable the extended signature for the API in the platform. This adds extra layer by using the request body to generate the signature making each request more secure and unique. We are generating extended signatures using three details, the public API KEY and private SECRET KEY and the REQUEST BODY. Sample Example: Let partner Api key: tb_test_q47Wqf04e1sIZu22kVwWBrDncigOkIPN Let partner Secret key: tb_test_CT5u9ZeNMBEL884g6gP3 Let request body: json
We use a specific format to create the token with three components. Token Format: ${encodedAuthHeader}.${encodedPayload}.${signature} Generating encodedAuthHeader: We use a static payload {"alg":"HS512","typ":"JWT"} which is encoded with Base64 to create encodedAuthHeader. In our sample the generated output will be "eyJhbGciOiJIUzUxMiIsInR5cCI6IkpXVCJ9" Generating encodedPayload: Encode the request body with Base64 to generate encodedPayload. In our sample the generated output will be "eyJyZXR1cm5VcmwiOiJodHRwczovL3d3dy50cmFuc2FjdGJyaWRnZS5jb20vZGVtbyIsInF1b3RlQ3VyckNvZGUiOiJVU0QifQ" Generating Signature: Create a string by concatenating the encodedAuthHeader and encodedPayload with a period in between. In our sample, the string becomes "eyJhbGciOiJIUzUxMiIsInR5cCI6IkpXVCJ9.eyJyZXR1cm5VcmwiOiJodHRwczovL3d3dy50cmFuc2FjdGJyaWRnZS5jb20vZGVtbyIsInF1b3RlQ3VyckNvZGUiOiJVU0QifQ". The string is then signed using SHA-512 Algorithm. In our sample the generated output will be "LQKyKPK9Sw_cXyuBxr7gnaUICYY-zASOcKezCr5ed5Vly0E1DXR1-8TZSVfPc9AGymTCjt3kvg48Z93es3slew" Generating Extended Signature: Using the token format concate the different components to created the final extended signature. In our sample, the token becomes "eyJhbGciOiJIUzUxMiIsInR5cCI6IkpXVCJ9.eyJyZXR1cm5VcmwiOiJodHRwczovL3d3dy50cmFuc2FjdGJyaWRnZS5jb20vZGVtbyIsInF1b3RlQ3VyckNvZGUiOiJVU0QifQ.LQKyKPK9Sw_cXyuBxr7gnaUICYY-zASOcKezCr5ed5Vly0E1DXR1-8TZSVfPc9AGymTCjt3kvg48Z93es3slew" Pass the public API KEY and the generated token in the headers like below. Below are different examples for different languages

Aggregators Authorization

An aggregator can use both signature or extended signature to authorize using their API keys. The aggregator might have multiple merchants and can use the same API keys of the main aggregator account to authorize. To call the aggregator’s account API, don’t pass x-partner-merchant-id .

Encryption

Encryption is used to send sensitive data like credit card and debit card details in the S2S API. We use RSA (Padding: RSA_PKCS1_OAEP_PADDING) algorithm to encrypt the data string using a key. To use this module, the partner must be PCI-certified. There is no need to integrate this if the partner is not using Create Payment Request.