Other useful information
Partial approval
In order to indicate that terminal is capable to handle partial approvals, the terminal needs to send SpprtdOptn with value PART to IPG.
If the transaction is a Cashback or DCC trx, then the terminal should not send this tag. If it's included anyway, then IPG will not forward the indicator to the authorization system.
If transaction gets partially approved by authorization system, then Rspn will contain value 'PART' and TtlAmt will include the approved amount.
Based on the result the merchant/customer can decide if he wants to abort the entire transaction or pays for the remaining amount with another trx or cash.
In case of a cancellation the terminal needs to cancel only the partial approved amount in CmpltnAdvc/Tx/TxDtls/TtlAmt.
In case of a subsequent transaction for the remaining amount, there's no reference to the partially approved transaction.
Please note that partial approval is only possible for a limited set of MCCs (ref to Mastercard mandate AN 2815)
Single Tap PIN and fallback to Chip/PIN
Terminals that support Contactless Single-TAP PIN request will need to send an additional occurrence of element Envt/POI/Cpblties/CrdhldrVrfctnCpblties with value 'OTHR' in authorization request messages.
Special values are required for the first (contactless) authorization request:caaa.001.001.06
| Tag | Description |
|---|---|
CrdhldrVrfctnCpblties | One occurence of value 'OTHR' |
As part of PSD2 SCA requirements, issuers may decline contactless transactions without CVM when new thresholds will be reached and send back specific response codes to drive the terminal behavior. IPG will forward the specific declined response codes as first two digits of ResponseReason and will include the corresponding action type requested by the card issuer as below:
- Perform contactless Single Tap PIN
The following additional information will be returned:
| Tag | Description |
|---|---|
TxRspn/AuthstnRslt/... RspnToAuthstn/Rspn | Contains value 'DECL' |
TxRspn/AuthstnRslt/... RspnToAuthstn/AddtlRspnInf | Contains value 'ContactlessSingleTapPIN' |
TxRspn/AuthstnRslt/... RspnToAuthstn/RspnRsn | Contains value '70' or '65' with AdditionalResponseInfo from scheme Format: xx:yy, text (max 35 char) xx= RC ifrom Scheme yy= AdditionalResponseInfo from scheme |
TxRspn/Actn/ActnTp | Contains value 'PINR' to indicate that the terminal must prompt for PIN entry and re-send the transaction using the chip data from the frist tap but with new transaction references and PIN data |
- Perform fail-forward to Chip and PIN
The following additional information will be returned:
| Tag | Description |
|---|---|
TxRspn/AuthstnRslt/... RspnToAuthstn/Rspn | Contains value 'DECL' |
TxRspn/AuthstnRslt/... RspnToAuthstn/AddtlRspnInf | Contains value 'FallbackToChipAndPIN' |
TxRspn/AuthstnRslt/... RspnToAuthstn/RspnRsn | Contains value '1A' or '65' with AdditionalResponseInfo from scheme Format: xx:yy, text (max 35 char) xx= RC ifrom Scheme yy= AdditionalResponseInfo from scheme |
TxRspn/Actn/ActnTp | Contains value 'FLFW' to indicate that terminal must read the data from chip in contact mode nad prompt for PIN entry |
Tokenization
Token provisioning is controlled via configuration in our gateway. If the merchant is activated for tokenization, our gateway will return a token in the authorization response message when the authorization request message contains an occurrence of tag Tx/AddtlTxData with value 'request/token'. The token value will be returned in element Envt/Card/PmtAcctRef. If the token is associated to an expiration date, it will be provided in Envt/PmtTkn/TknChrtc as "YYMM".
During the creation of a token the card details are stored encrypted in the Token vault (gateway or partner solution). An authorization request that contains a token value will be passed to the authorization and back-office systems with real card number instead of token.
Remark: with implementation of acquirer protocol V8.0 or higher, the format of token response will need to be adjusted to the new structure (we supply an acquirer token, see MUG V8, chapter: 4.10.1
Unattended terminals
In order to send card-present transactions from an unattended terminal to Fiserv’s Central Acceptance Platform, please use the following parameters:
| Tag | Description |
|---|---|
Cntxt/PmtCntxt/AttndncCntxt | Use value 'UATT' |
TxDtls/UattnddLvlCtgy | Unattended level category: The following values are currently accepted (others will be ignored): 0: The transaction is not a cardholder activated terminal transaction 1 or 2: Online-capable CAT (Cardholder Activated Terminals) devices that support PIN - online or offline or both, or no cardholder verification (CV) are known as dual-capability devices. They may produce either CAT Level 1 or 2 transactions, depending on which CV method was completed. A CAT that supports offline PIN, must have dual capability. Dual-capability devices produce CAT Level 1 transactions when PIN was used and produce CAT Level 2 transactions hene no CVM was used. |
Updated 6 months ago
