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

Gives insight into the status of the authorization request with the following encoding:

Interface valueMeaningComment
0Authorization completeFor successfully authorized transactions (RC 00)
1Authorization declined (default)Fallback code if 2 or 3 cannot be distinguished, details should be communicated via the authorizationResponseCode (below)
2Authorization declined ISSIf authorization was declined by issuer
3Authorization declined ACQIf authorization was declined by acquirer
4Process canceledIf the transaction is cancelled after authentication stage, during an ongoing or directly before entering the authorization attempt (and therefore not successful)
5Technical ErrorFor 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

Contains the (card scheme specific) response code received during authorization message exchange, e.g. "00" for authorization approved.

authorizationApprovalCode

Contains the authorization approval code (if available), e.g. "123456".

merchantReference

Contains the merchant reference that will be send to authorization backend, e.g. "DreamAir_MC: Order-ID = ABCDEFG".

cardholderReference

Contains the cardholder reference that will be send to authorization backend , e.g. "DreamAir flight to Bad Homburg v. d. HΓΆhe".


Did this page help you?