Integration
For security reasons (authenticity, integrity), every transmitted notification is provided with a signature.
This signature is calculated both on the side of the service recipient (PAYONE) and on the side of the service provider (notification recipient). Requests should only be processed technically by the service provider if the calculated signature based on the request content corresponds to the signature provided by the service recipient.
The signature is created based on the 'string-to-sign' and the 'secret' using the function HMAC-SHA-512 [RFC 2104]
The 'secret' is never transmitted in the communication, but is kept at the respective participant. An SHA512 hash of the PortalKey is used as the secret.
The following values are included to determine the string-to-sign:
parameter | format | description |
---|---|---|
X-Request-ID |
UUID |
Unique request-ID from the HTTP-Header. example: 67e96638-8295-41ad-894d-914900461f26 |
SHA512-Hash des Request Body |
String |
SHA512 Hash without salt of the request body. example: B5AB92007F8FC0F2BE26919EE9064C6268767D67DBDA1E6 FA8691D1AEA7359F1D19B464F1F72393585DD7F42DA0B2C941FAEEAEA2F13CCF88 |
From the above-mentioned parameters, the string-to-sign is created in the order given above. For this, the values are concatenated separated by the separator ":".
Example 'string-to-sign':
67e96638-8295-41ad-894d-914900461f26:B5AB92007F8FC0F2BE26919EE9064C6268767D67DBDA1E6FA8691D1AEA7359F1D19B464F1F72393585DD7F42DA0B2C941FAEEAEA2F13CCF88
---end
The signature is transmitted by the service recipient - in addition to the unique technical request ID (X-Request ID) required to create the signature on the recipient side - in the http header field X-Auth-Code.
---end
|
---end