Other useful information
Partial approval
In order to indicate that the terminal is capable to handle partial approvals, the terminal needs to send SpprtdOptn with value PART to the Gateway.
If the transaction is a payment including cashback or in foreign currency, then the terminal should not send this tag. If it's included, then the Gateway will not forward the indicator to the authorisation 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 transaction or cash. This separate transaction is not linked to the previous transaction.
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' |
Due to requirements of the Payment Services Directive II, issuers may decline contactless transactions without cardholder verification when specific criteria (e.g. thresholds) are met, and therefore send back specific response codes to drive the terminal behavior. The Gateway 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 |
Following the receipt of TxRspn/Actn/ActnTp value 'PINR', the terminal will need to re-send the transaction with original chip data, but with PIN and new transaction references and include an occurrence of Tx/AddtlTxData with value "/request/ContactlessSingleTapPIN"
- 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 the Gateway. If your account is activated for tokenization, the 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 (of the 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 the Gateway, 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 about 1 month ago
