Upon completion, the transaction details will be sent back to the defined ‘responseSuccessURL’ or ‘responseFailURL’ as hidden fields. You can define these URLs in your transaction request.

Standard set

Hash Validation

Make sure to use the parameter response_hash to recheck if the received transaction response has really been sent by Fiserv to protect you from fraudulent manipulations. The value is created with a HMAC Hash using the following parameter string:

   approval_code|chargetotal|currency|txndatetime|storename

Shared secret (sharedsecret) will be used as a key in HMAC to calculate the hash with the above hash string. The hash algorithm is the same as the one that you have set in the transaction request.

Please note that you have to implement the response hash validation, when doing so remember to store the txndatetime that you have submitted with the transaction request in order to be able to validate the response hash. Furthermore, you must always use the https-connection (instead of http) to prevent eavesdropping of transaction details.

You can also use the parameter extended_response_hash to include all response parameters in the hash calculation. Please contact your local support team if you want to enable this feature. This will be managed with a specific setting performed on your account (service configuration extendedResponseHashSupported).

Creating the extended response hash:

• Step 1: Retrieve all non-empty Gateway specified response parameters and then remove the parameter extended_response_hash from your list, so that it will not get included in the hash calculation. Consider also that shared secret will be used as a key in HMAC to calculate the hash and the hash algorithm must be the same as the one that you have set in the transaction request.
• Step 2: Sort the response parameters in ascending order of the parameter names, where the upper-case characters come before the lower case (based on ASCII value). Join the parameters’ values to one string with pipe separator (use only parameters’ values and not the parameters’ names).
• Step 3: Pass the created string to the HMAC algorithm while using shared secret (‘sharedsecret’) as a key for calculating the hash value.
• Step 4: Encode the result of HMAC with Base64 to generate the extended response hash. Only HMAC algorithm (i.e.: HMACSHA256, HMACSHA384 or HMACSHA512) is supported for generating the extended response hash.

3-D Secure transactions

Response code indicates the classification of the transaction, values are valid for both HPP and APIs.

Credential-on-file transactions

Currency Conversion (Global Choice™) transactions

iDEAL transactions

SEPA Direct Debit as part of the Local Payments offering

SEPA Direct Debit as part of the TeleCash by Fiserv offering

Global Merchant Acquiring model

Partial Approval

Account Updater Service transactions

When your store is enabled for the MasterCard real-time account updater service on the Gateway, and you have the payment information vaulted on your side then when applicable the updates are sent as part of the Gateway response, and you have to react upon it accordingly i.e.: update the account number for a token when you store PAN and a token on your side.

When you are processing on the Fiserv North frontend (Nashville) endpoint and your store is enabled for account updater services:

Validity Checks & Errors

Additionally when using your own error page for negative validity checks (full_bypass=true):

Server-to-server Notification

In addition to the response you received in hidden fields to your responseSuccessURL or responseFailURL, the Gateway can send server-to-server notifications with the above result parameters to a defined URL. This is useful to keep your systems in sync with the status of a transaction. To use this notification method, you can specify an URL in the Customisation section of the Virtual Terminal or submit the URL in the following additional transaction parameter transactionNotificationURL.

Please note, that:
• The transaction URL is sent as received therefore please don’t add additional escaping (e.g.: using %2f for a Slash(/).
• No SSL handshake or verification of SSL certificates will be done in this process.
• The notification URL needs to listen on port 443 (https) – other ports are not supported.

The response hash parameter for validation (using the same algorithm that you have set in the transaction request) notification_hash is calculated as follows:

chargetotal|currency|txndatetime|storename|approval_code

Shared secret (sharedsecret) will be used as a key in HMAC to calculate the hash with the above hash string.

Such notifications can also be set up for the recurring payments that get automatically triggered by the Gateway. Please contact your local support team to get a shared secret (rcpSharedSecret) agreed for these notifications. You can configure your Recurring Transaction Notification URL (rcpTransactionNotificationURL) in the Customisation section of the Virtual Terminal.

In case of the recurring transactions the response hash parameter notification_hash is calculated differently as follows:

chargetotal+rcpSharedSecret+currency+txndatetime+storename+approval_code

The shared secret (rcpSharedSecret) is part of the string (it is not used as a key in HMAC to calculate the hash with the hash string). Moreover, the response hash parameter for the recurring transaction notifications is calculated with the SHA256-value (as the default value).