Response Details
Upon completion, the transaction details will be sent back to the defined URL as hidden fields:
| Field Name | Description | Value |
|---|---|---|
approval_code | Approval code for the transaction. The first character of this parameter is the most helpful indicator for verification of the transaction result. | Y indicates that the transaction has been successful, N indicates that the transaction has not been successful, ? indicates that the transaction has been successfully initialized, but a final result is not yet available since the transaction is now in a waiting status. The transaction status will be updated at a later stage. |
oid | Order ID, if not defined in the request, the Gateway generates it automatically | e.g. C-2101f68a-45e9-4f3c-a6da-1337d5574717 |
refnumber | Reference number | - |
status | Transaction status | APPROVED, DECLINED (by authorisation endpoint or due to fraud prevention settings),FAILED (wrong transaction message content/parameters, etc.) or WAITING (asynchronous Alternative Payment Methods) |
txndate_processed | Time of transaction processing | - |
ipgTransactionId | Transaction identifier assigned by the Gateway, e.g. to be used for a Void | - |
tdate | Identification for the specific transaction | - |
fail_reason | Reason the transaction failed | - |
response_hash | Hash-Value to protect the communication See note below | - |
extended_response_hash | Hash-Value to protect the communication, where all response parameters are included in the hash calculation see note below. | |
processor_response_code | The response code provided by the backend system. | Note that response codes can be different depending on the used payment type and backend system. While for credit card payments, the response code 00 is the most common response for an approval, the backend for giropay transactions for example returns the response code 4000 for successful transactions. |
fail_rc | Internal processing code for failed transactions | - |
terminal_id | Terminal ID used for transaction processing | - |
ccbin | 6 digit identifier of the card issuing bank | - |
cccountry | 3 letter alphanumeric ISO code of the cardholder’s country | e.g. USA, DEU, ITA, etc. Filled with N/A if the cardholder’s country cannot be determined or the payment type is not credit card |
ccbrand | Brand of the credit or debit card | MASTERCARD, VISA, AMEX, DINERSCLUB, JCB, CUP, CABAL, MAESTRO, RUPAY, BCMC, SOROCRED. Filled with N/A for any payment method which is not a credit card or debit card. |
How to generate a hash response:
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_hashfrom 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.
For 3-D Secure transactions only:
Return code indicates the classification of the transaction:
| Field Name | Description |
|---|---|
response_code_3dsecure | 1 – Successful authentication (VISA ECI 05, MasterCard ECI 02) 2 – Successful authentication without AVV (VISA ECI 05, MasterCard ECI 02) 3 – Authentication failed / incorrect password / authentication rejected by DS or ACS (authorization transaction declined by the Gateway) 4 – Authentication attempt (VISA ECI 06, MasterCard ECI 01) 5 – Unable to authenticate / DS not responding (VISA ECI 07) - relevant for 3DS 1.0 6 – Unable to authenticate / ACS or DS not responding (VISA ECI 07) 7 – Cardholder not enrolled for 3-D Secure (VISA ECI 07) - relevant for 3DS 1.0 only 8 – Invalid 3-D Secure values received |
Credential-on-file transactions only:
| Field Name | Description |
|---|---|
schemeTransactionId | Returned in the response by a scheme for stored credentials transactions to be used in subsequent transaction requests as a reference |
For Currency Conversion transactions only:
| Field Name | Description |
|---|---|
dcc_foreign_amount | Converted amount in cardholder home currency. Decimal number with dot (.) as a decimal separator |
dcc_foreign_currency | ISO numeric code of the cardholder home currency. This transaction is performed in this currency |
dcc_margin_rate_percentage | Percent of margin applied to the original amount. Decimal number with dot (.) as a decimal separator |
dcc_rate_source | Name of the exchange rate source (e.g. Reuters Wholesale Inter Bank) |
dcc_rate | Exchange rate. Decimal number with dot (.) as a decimal separator |
dcc_rate_source_timestamp | Exchange rate origin time. Integer - Unix timestamp (seconds since 1.1.1970) |
dcc_accepted | Indicates if the card holder has accepted the conversion offer (response value ‘true’) or declined the offer (response value ‘false’) |
For iDEAL transactions only:
| Field Name | Description |
|---|---|
accountOwnerName | Name of the owner of the bank account that has been used for the iDEAL transaction |
iban | IBAN of the bank account that has been used for the iDEAL transaction |
bic | BIC of the bank account that has been used for the iDEAL transaction |
For SEPA Direct Debit as part of the Local Payments offering:
| Field Name | Description |
|---|---|
mandateReference | Mandate reference as returned for the first direct debit transaction |
mandateDate | Date of the initial direct debit transaction as returned for the first transaction |
Validity & Errors:
Additionally when using your own error page for negative validity checks (full_bypass=true):
| Field Name | Description |
|---|---|
fail_reason_details | Comma separated list of missing or invalid variables. Note that fail_reason_details will not be supported in case of payplus and fullpay mode. |
invalid_cardholder_data | true – if validation of card holder data was negative. false – if validation of card holder data was positive but transaction has been declined due to other reasons. |
For Partial Approval:
| Field Name | Description |
|---|---|
PartiallyApprovedAmount | Available balance as a partial amount approved. |
Status | Transaction status: ‘PARTIALLY APPROVED’. This unique status allows you to identify this transaction and subtract the partially approved amount from the total transaction amount, and request another form of payment, using split-tender functionality. |
Updated 4 months ago