Generate request signatures
A request signature is essential for the Establish Data used by the Trustly UI and the POST /establish API endpoint to ensure the integrity of transactions, providing robust protection against potential tampering. The requestSignature should be generated server-side to keep your accessKey secure and out of client-side code. It is a Base64-encoded HMAC-SHA1 hash of the data in the request payload, created using your accessKey.
To generate a request signature, you complete the following tasks:
- Concatenate Parameters - Gather all the request parameters, including the
accessIdand then concatenate these parameters into a single string. Ensure the parameters are in the correct order. - Hash the Concatenated String - Use the HMAC-SHA1 hashing algorithm, use your
accessKeyas the key for the HMAC algorithm, and then Base64 encode the resulting hash. - Attach the Signature to Your Request - Include the generated signature in the
requestSignatureproperty of the payload.
Hashing algorithm options (BETA functionality)
If desired, an alternative hashing algorithm may be used to generate the requestSignature. Trustly will assume by default that HMAC-SHA1 has been used to generate the hash so if an alternative is used, the algorithm name and a colon should be prepended to the resulting signature after it is Base64 encoded. For example:
Supported algorithms include:
- HMAC-SHA1:
HmacSHA1(Default value if no algorithm prefix is included) - HMAC-SHA512:
HmacSHA512
Parameter ordering
In order for the signature to be validated correctly, the order of parameters in the hash must be strictly maintained. Any field in the list below which is present in the request payload must be included in the generated requestSignature and must appear in the order below.
Do not include any parameters that are not present in the request payload. Additionally, do not include fields with null values unless they also appear in your request payload with a null value.
- accessId
- merchantId
- description
- currency
- amount
- displayAmount
- minimumBalance
- merchantReference
- paymentType
- timeZone
- recurrence.startDate
- recurrence.endDate
- recurrence.frequency
- recurrence.frequencyUnit
- recurrence.frequencyUnitType
- recurrence.recurringAmount
- recurrence.automaticCapture
- verification.status
- verification.verifyCustomer
- customer.customerId
- customer.externalId
- customer.name
- customer.vip
- customer.taxId
- customer.driverLicense.number
- customer.driverLicense.state
- customer.address.address1
- customer.address.address2
- customer.address.city
- customer.address.state
- customer.address.zip
- customer.address.country
- customer.phone
- customer.email
- customer.balance
- customer.currency
- customer.enrollDate
- customer.externalTier
- customer.externalTierTrustScore
- customer.dateOfBirth
- account.nameOnAccount
- account.name
- account.type
- account.profile
- account.accountNumber
- account.routingNumber
- beneficiary.name
- beneficiary.taxId
- beneficiary.address.address1
- beneficiary.address.city
- beneficiary.address.state
- beneficiary.address.zip
- beneficiary.address.country
- beneficiary.dateOfBirth
- beneficiaryAccount.iban
- beneficiaryAccount.paymentProvider.name
- beneficiaryAccount.paymentProvider.routingNumber
- beneficiaryAccount.paymentProvider.swift
- beneficiaryAccount.paymentProvider.country
- transactionId
- onlinePPSubtype
- customer.customData.payins.volume30Days
- customer.customData.payins.volume90Days
- customer.customData.payins.volume365Days
- customer.customData.payouts.volume30Days
- customer.customData.payouts.volume90Days
- customer.customData.payouts.volume365Days
Examples
For a functional example in the context of a backend application, see the NestJS example. The following examples are provided here:
- Readable but verbose JavaScript example
- Optimized ES6 JavaScript example
- Java example