Security

Signature

To prevent tampering with a request/response while it's in transit, server-to-server API calls should contain a signature in the header. The signature is a hash calculated over the complete request/response body with a secret key. We are using the HMAC-SHA256 algorithm for generating the signature. As part of the onboarding process, the secret key would be shared with the merchant over a secure channel. Merchant and Synapse will ignore the request/response of the server to server API call if

• The request/response does not contain the signature in the header(X-Body-Signature).
• The signature verification fails.

Encryption

To ensure the confidentiality of the data while it’s in transit, the request and response body in server-to-server calls must be encrypted. The request/response would contain a payload, which would be the encrypted value of the raw request/response. We are using the AES with Galois/Counter Mode (AES-GCM) algorithm for encryption. As part of the onboarding process, the secret key would be shared with the merchant over a secure channel. Merchant and Synapse will ignore the request/response of the server to server API call if

• The request/response does not contain the encrypted payload.
• The receiver is not able to decrypt the data.

JS Communication

JS SDK exposes methods which the merchants can use to invoke native OS functionality. Any communication over the JS channel containing customer, transaction related or any confidential information shall be sent in an encrypted format and must be forwarded to the respective server for decryption with the algorithm mentioned earlier.

Whitelist

Merchant and Synapse shall share their IPs for whitelisting during the onboarding process. Only requests from whitelisted sources shall be entertained.