Once we’ve collected all of the required data and signature for a valid SEPA mandate, we’ll perform a serverside POST to the URL you provided during your Merchant Intake process so that you can update your backend accordingly.
|merchant_id||string||your Sign2Pay Merchant ID|
|purchase_id||string||the Sign2Pay ID of this transaction|
|ref_id||string||your internal reference ID to retrieve the order|
|amount||number||the purchase amount in cents|
|status||string||“mandate_valid” indicates you will receive payment|
|token||string||a randomly generated string with length 50.|
|timestamp||string||the number of seconds passed since January 1, 1970 (UTC)|
|test||boolean||reflects the mode of the application used to create purchase (test vs. live)|
|signature||string||string with hexadecimal digits generated by HMAC algorithm|
To verify the webhook is originating from Sign2Pay you need to:
- Concatenate timestamp and token values.
- Encode the resulting string with the HMAC algorithm (using your API Key as a key and SHA256 digest mode).
- Compare the resulting hexdigest to the signature.
- Optionally, you can also check if the timestamp is not too far from the current time (UTC).
After validating the authenticity of the POST request, you may want to update your order record status as paid (or whatever your internal process is). Once this is complete, a response is required for use to redirect your consumer appropriately.
|status||string||“success” or “failed”|
|redirect_to||string||the URL the consumer should be redirected to|
|params||string||any additonal params you would like passed to your redirect_url (ie.: authorization_code, user_message etc)|
When the Postback process is complete, your consumer will be directed to the url provided in the postback response with any params you’ve returned appended to the query string.
This is a bit different if you are using the Sign2Pay iOS Library as we instead broadcast an event your app can listen for.