Transaction States

SUCCEEDED

Authentication completed successfully, either frictionlessly or via a completed challenge.

CANCELLED

The transaction was cancelled by the cardholder or the 3DS Requestor.

ABORTED

A challenge was required but the 3DS Requestor never sent the follow-up CReq.

FAILED

The cardholder failed to complete the SCA challenge.

TIMEOUT

The cardholder did not complete the challenge within the allotted time period.

ERROR

An error occurred during transaction processing.

REJECTED

The ACS determined the transaction could not proceed.

SUCCEEDED

The transaction was authenticated by the ACS and the result was returned to the DS successfully. A transaction in the SUCCEEDED state may have been approved frictionlessly or via a completed SCA challenge.

When a transaction is approved frictionlessly, the exemption field will be set to indicate which exemption was applied.

Exemption Values

Value	Description
`LOW_VALUE_PAYMENT`	The Low Value Payment exemption under PSD2 was applied. Conditions: the payment is under €30, cumulative spend since the last SCA does not exceed €100, and no more than 5 transactions have occurred since the last SCA.
`LOW_RISK`	The transaction was assessed as low risk via TRA performed by Apata or an External Risk Engine. The maximum transaction value eligible for this exemption is determined by the institution's fraud levels.
`WHITELISTED`	The cardholder previously added the merchant to their Whitelist. Future transactions with that merchant are exempted from challenge. SCA must be performed in order to whitelist a merchant.
`RECURRING`	The Recurring Payment exemption was applied. The first payment in the recurring series was challenged; subsequent fixed-amount payments to the same merchant are exempted.
`ACQUIRER_EXEMPTION`	The Acquirer Exemption was applied. The merchant indicated that they have already performed TRA or SCA on their side.
`SECURE_CORPORATE_PAYMENT`	The Secure Corporate Payment exemption under PSD2 was applied.
`ONE_LEG_TRANSACTION`	The One-Leg Transaction exemption was applied. This applies when the acquirer is located outside the EEA.
`MERCHANT_INITIATED`	The transaction was exempted as a Merchant-Initiated Transaction (3RI). The cardholder is not present and cannot complete a challenge.
`DATA_SHARE`	The transaction was a Data Share. Data Share messages pass through the EMV 3DS rails to generate authentication insights without requesting authentication, and are not eligible for challenge under the specification.
`NON_PAYMENT`	The transaction was an NPA flow. Non-payment authentications support use cases such as adding a card to a wallet, trusted merchant listing, account creation, and tokenisation.
`VISA_DAF`	The transaction was exempted via Visa DAF. After an initial authenticated payment credential is established, Visa validates subsequent AReq data elements and exempts the transaction. Successful authentication results in a CAVV and an ECI of 05.

CANCELLED

The transaction was cancelled by the cardholder or the 3DS Requestor. When the state is CANCELLED, the reason field will be set.

Reason	Description
`CANCELLED_VIA_CHALLENGE_PAGE`	The cardholder selected the cancel option on the Challenge Interface displayed in their browser or app.
`CANCELLED_OUT_OF_BAND`	The cardholder cancelled the transaction outside the challenge page, for example from a banking app during an OOB flow.
`CANCELLED_BY_REQUESTOR`	The transaction was cancelled by the 3DS Requestor, typically a merchant.

ABORTED

The 3DS Requestor sent an AReq but never followed up with a CReq after Apata determined that a challenge was required.

FAILED

The cardholder failed to complete the SCA challenge. When the state is FAILED, the reason field will be set.

Reason	Description
`CHALLENGE_ATTEMPTS_EXCEEDED`	The cardholder exceeded the maximum number of allowed attempts. For example, an incorrect OTP was entered too many times.
`CHALLENGE_RETRIES_EXCEEDED`	The cardholder exceeded the maximum number of challenge retries, for example by requesting too many OTP resends.
`REQUIRED_DETAILS_MISSING`	The cardholder's contact details (phone number or email address) could not be found, making it impossible to deliver a Challenge.

TIMEOUT

The cardholder did not complete the challenge within the allotted time period. When the state is TIMEOUT, the reason field will be set.

Reason	Description
`NO_CHALLENGE_PAGE_SUBMIT`	The cardholder did not return to the Challenge Interface to proceed with the transaction.
`NO_OOB_CONFIRMATION`	The OOB authentication or decline callback was not received within the allowed time.

ERROR

An error occurred during transaction processing. When the state is ERROR, the errorCode field will be set. The errorMessage field may also be populated with additional detail.

Error Code	Description
`validation_error`	A 3DS message received by the ACS was invalid according to the EMV 3DS protocol.
`ds_error`	The DS returned an error when the ACS attempted to report the transaction result.
`webhook_call_failed`	A webhook call from the Apata ACS to the issuer failed.
`client_error`	The 3DS Requestor reported an error on their side to the ACS.
`sms_send_failed`	The ACS was unable to send an SMS OTP to the cardholder.
`invalid_config`	The transaction could not be completed due to invalid or incomplete configuration.
`fallbacks_exceeded`	The cardholder exceeded the permitted number of fallback attempts across Challenge Methods.
`decoupled_not_supported`	Decoupled Authentication was required but the Challenge Method configured for the card does not support it. Decoupled authentication is only available under EMV 3DS 2.2 and later.
`email_send_failed`	The ACS was unable to send an Email OTP to the cardholder.
`card_link_failed`	The request sent to the issuer via Card Link was unsuccessful.

REJECTED

The ACS determined that the transaction could not proceed. When the state is REJECTED, the reason field will be set.

Reason	Description
`CARD_DISABLED`	The card has been blocked in the Apata system, or its associated Card Range has been disabled.
`LOW_CONFIDENCE`	The Risk Profile determined that the transaction was too risky to continue.

Real-Time Notifications

Issuers receive the final transaction state in real time via the Finalised Event. The transaction.state and transaction.reason fields in the event payload reflect the values described on this page.