Authorization data
Authorization data
The following fields will be discussed:
- authorizationStatus
- authorizationResponseCode
- authorizationApprovalCode
- merchantReference
- cardholderReference
- threeDSFlowIndicator
This JSON-object provides information about the authorization process. It can naturally only be provided if the transactions enters the authorization stage. All transactions that fail the authentication/exemption stage are not expected to provide this info, e.g. an event with the field combination transStatus=N, threeDSFlowIndicator=SUBMITTED_TO_3DS, scaStatusReason=USER_DECLINE_SCA_FAILURE. In general, only transactions with scaStatusReason FRICTIONLESS or SCA_SUCCESS (all that successfully passed or circumvented/skipped authentication stage) require authorizationData.
All transactions that reach the authorization stage should provide at least the following information. Again, only the final (last) authorization is meaningful for those fields. If, for example, a transaction is soft declined during the first authorization attempt, goes to 3DS afterwards and re-enters authorization stage and is successfully authorized, only the last status "0" (authorization complete) should be provided. An intermediate stage is not part of the fields and encoding.
authorizationStatus
authorizationStatusGives insight into the status of the authorization request with the following encoding:
| Interface value | Meaning | Comment |
|---|---|---|
0 | Authorization complete | For successfully authorized transactions (RC 00) |
1 | Authorization declined (default) | Fallback code if 2 or 3 cannot be distinguished, details should be communicated via the authorizationResponseCode (below) |
2 | Authorization declined ISS | If authorization was declined by issuer |
3 | Authorization declined ACQ | If authorization was declined by acquirer |
4 | Process canceled | If the transaction is cancelled after authentication stage, during an ongoing or directly before entering the authorization attempt (and therefore not successful) |
5 | Technical Error | For any "blameless" cancellations of events, e.g. authorization system not reachable (e.g. RC 91) |
While this field (for most use-cases) constitutes a summary/grouping of the authorizationResponseCode (see below), it additionally supports the opportunity for a risk related decline from any authorization risk engine. In case the authentication stage is successfully passed and the event is provided to an authorization risk engine (in the acquirer/PSP domain, before entering back-end flow) with result that this event has to be declined there might not be a meaningful ResponseCode, but authorizationStatus=3 (or 1 as fallback) can be provided nevertheless.
A similar argument can be made for authorizationStatus=4,5 that can also occur outside of the acquirer-scheme-issuer authorization back-end communication.
The codes 0,2 are always generated in communication with the issuing bank and should correspond directly to a ResponseCode.
authorizationResponseCode
authorizationResponseCodeContains the (card scheme specific) response code received during authorization message exchange, e.g. "00" for authorization approved.
authorizationApprovalCode
authorizationApprovalCodeContains the authorization approval code (if available), e.g. "123456".
merchantReference
merchantReferenceContains the merchant reference that will be send to authorization backend, e.g. "DreamAir_MC: Order-ID = ABCDEFG".
cardholderReference
cardholderReferenceContains the cardholder reference that will be send to authorization backend , e.g. "DreamAir flight to Bad Homburg v. d. Höhe".
Updated about 1 year ago
