Skip to main content

Overview

ACS by Verestro is a solution designed to address online payment threats. It allows for secure processing of card-not-present transactions, compliant with the latest 3D Secure standards from EMV, ensuring the highest level of security for users and their funds. By using the latest 3DS protocols in version 2.3.x, you can effectively combat financial fraud while maintaining customer convenience in everyday card purchases.

Terminology

Name

Description
3DS Server A 3DS server (3D Secure server) is a software system used in online card payments to manage and secure communication between a merchant and a card's issuing bank. 3DS server is built on the acquirer side.
Decoupled authentication Decoupled authentication (often referred to in the context of 3D Secure as decoupled authorization) is a feature in EMV 3DS 2.2+ that separates the customer's identity check from the active checkout session.
In app OOB authentication In-app OOB (Out-of-Band) authorization in 3D Secure (3DS) is a secure mobile payment verification method where your banking app approves a purchase on the user device through a separate communication channel.
SPC authentication

Secure Payment Confirmation (SPC) authorization in 3D Secure (3DS) is a streamlined authentication method that lets customers confirm online card payments using fast device biometrics like a fingerprint or face scan directly from trusted device or WEB browser.
ACS ACS stands for Access Control Server, which is the central software system operated by a card-issuing bank to authenticate online shoppers.
Customer Institution which is using Verestro products. This institution decides which SDK should be used and how transaction should be processed. Basicly Customer can be called Verestro client.
Directory Server A Directory Server (DS) in 3-D Secure (3DS) is a central hub managed by card networks (like Mastercard or Visa) that routes authentication messages between online merchants and card-issuing banks.
User User which is using Payment Hub Application. It is root of entity tree. User is identified in Wallet Server by some unique identifier which is provided after registration. User can have access to his data and operations based on session. User’s session is created after device pairing is performed. When session expires then user authentication have to be performed. Session is valid 10 minutes, however it is configurable parameter.
Card Card belongs to the user. User can have many cards. Card is identified via internal id given after storing card on Wallet Server. Whole PAN is stored on Wallet Server which has PCI DSS certificate.
Device Device belongs to user. When user starts using application after installation then device pairing is performed. After pairing device with some unique id, unique device installation id is generated and this installation is assigned to user. It is possible to have one active installation on specific device for specific user.
Session Token Token which defines User. It is an authorization way of the User.  This entity is created after paring device and this is needed to perform any actions in the application. When session is expired then user authentication needs to be performed. Session is valid 10 minute s, however it is configurable parameter.
Acquirer External institution responsible for processing transaction and 3ds requests ordered by the Verestro Payment Hub App. Acquirer connects with banks / card issuers and returns information whether the ordered action on a given card is possible.
PAN (Primary Account Number) It is 14-19 (usually 16) digits number which is a unique identifier of the payment card issued to the customer's account.
Wallet Server Provides the backend services to support Mobile Payment Application via Verestro Wallet SDK and is responsible for managing users, devices, cards , device tokens, storing transactions history and communication with Acquirers.
PCI DSS PCI DSS (Payment Card Industry Data Security Standard) is a security standard used in environments where the data of payment cardholders is processed. The standard covers meticulous data processing control and protection of users against violations.
PCI 3DS

PCI 3DS (Payment Card Industry 3-D Secure) is a security standard and protocol designed to add an extra layer of authentication for online and card-not-present (CNP) payment transactions
Partner

Wherever this document refers to the Partner, it refers to your company and your IT infrastructure, depending on the context.

Integration Methods

Regardless of whether you already have card issuance implemented or are starting from scratch, Verestro's ACS is able to flexibly adapt the deployment model for you.

1. Integration with a bank/processor

We will redirect verification and authorization requests, as well as generated IAVs, to you.

image.png

2. Verestro API

With full PCI DSS / PCI 3DS certification, Verestro enables secure storage and management of cards on our servers; in this model, you feed the Verestro system with your cards and receive an IAV, while authorization takes place directly between Verestro and the user.

image.png

3. Full core banking and processing solution from Verestro

Verestro is able to provide a complete platform through which you can acquire a user, register them, create an account for them, and issue them a card, including processing transactions using the most advanced methods available on the market. 

image.png

High-level structure of Verestro's ACS

Verestro's system architecture is based on microservices, which makes it possible to tailor the integration precisely to clients' needs.


image.png

Administrative Panel

the basic interface through which you gain access to the full ACS configuration and real-time monitoring of its operation, making it an excellent support tool

Notification Service

The service through which the ACS sends messages to users. The Notification Service allows the configuration of multiple communication channels depending on your needs - SMS, email, server-to-server connection, and others.

ACS

(Access Control Service) the main service processing 3D Secure authorizations, holding PCI 3DS and EMV certification. This is where all data is verified, the appropriate authorization path is selected, and the IAV is generated, which is attached to the transaction authorization object.

Risk Engine

a tool used by the ACS when selecting the appropriate authorization path; this is where the full configuration of rules, exceptions, and whitelists and blacklists resides.

Mobile SDK

an optional element, a library prepared by Verestro ready for integration into an application on the user's mobile device. The SDK enables secure communication and provides the ability to perform IN APP OOB authorization

VIPP

(Verestro Issuing Processing Platform) an optional element through which Verestro is able to deliver a complete solution, from card generation through 3DS verification to transaction authorization.

Data Core

an optional central service, holding full PCI DSS certification, used to store user data and their cards used in the 3DS authorization process

Configuration

The basic parameter that is part of every ACS configuration is the BIN and its range. Depending on the Partner's preferences, the available authorization methods, their channels, the appearance and content of 3DS templates are defined for a given range, and the parameters according to which the Risk Engine will make decisions regarding the authorization path are configured. The basic tool available to the partner is the Administrative Panel, through which they gain access to the entire ACS solution and all its components.

Card Program

The basic configuration element within which we define the BIN range to which challenge profiles and risk profiles will be assigned. 

image.png

Challenge profile

here we define the parameters according to which authorizations will be carried out, including their configuration (OTP, IN APP, DECOUPLED, SPC), as well as the design of the authorization screen template itself

image.png

image.png

Risk profile

Configuration of the parameters according to which authorization paths are selected, including MCC code whitelists/blacklists, geolocation, as well as low-value transaction thresholds.

image.png

Security

Deployments in which we integrate Server-to-Server require the use of the following security measures:

Connectivity Architecture

Issuer → ACS

  • Protocol: HTTPS (TLS 1.2+)

  • Authentication: Mutual TLS (X.509)

  • Issuer Role: Client

  • ACS Role: Server

  • Certificate Usage:

    • The Issuer presents a client certificate signed by a Verestro CA.

    • ACS validates the Issuer's certificate against its trust store.

    • ACS authenticates the Issuer
ACS → Issuer

  • Protocol: HTTPS (TLS 1.2+)

  • Authentication: Mutual TLS (X.509)

  • ACS Role: Client

  • Issuer Role: Server

  • Certificate Usage:

    • ACS presents its client certificate.

    • The Issuer validates ACS’s certificate against its trust store.

    • The Issuer authenticates ACS

Certificate Generation and Use

Certificate Type Generated By Signed By Used By Purpose(s)
Client Certificate (Issuer) Issuer Verestro Issuer X.509 mTLS authentication (Issuer → Verestro)
      Verestro/Issuer JWE. Verestro uses the public key from this certificate to encrypt sensitive fields (e.g., card number) in requests. The Issuer uses the private key from this certificate to decrypt sensitive fields
Client Certificate (Verestro) Verestro Issuer Verestro X.509 mTLS authentication (Verestro → Issuer)
      Issuer/ Verestro JWE. The Issuer uses the public key from this certificate to encrypt sensitive fields (e.g., card number) in requests. Verestro uses the private key from this certificate to decrypt sensitive fields

Note: While the same certificate pair may be used for both mTLS and JWE, it's recommended to use separate certificates for TLS and field-level encryption for improved security and certificate lifecycle management.

Certificate Requirements

  • Format: X.509

  • Key Length: RSA 2048-bit or higher

  • Validity: Minimum 1 year validity recommended

Check the following document on how to create a client certificate:

https://developer.verestro.com/books/connecting-to-our-services-and-sandbox/page/connecting-to-server-to-server-apis-fe-sandbox

Field-Level Encryption

Certain sensitive fields (e.g., cardNumber) are encrypted using JWE (JSON Web Encryption) to provide end-to-end protection beyond TLS.

JWE Encryption Details

Data is encrypted using JWE per RFC 7516 (https://tools.ietf.org/html/rfc7516)

JWE header

Name

Description

alg

RSA-OAEP-256

Cryptographic algorithm used to encrypt CEK

enc

A256GCM

Identifies the content encryption algorithm used to perform authenticated encryption

  • Algorithm: RSA-OAEP-256

  • Content Encryption: A256GCM

  • Key Material: Derived from or aligned with the public key in the X.509 certificate

  • Envelope Format: Compact JWE serialization

Encrypted Fields

Field Location Requirement

encryptedCardNumber

 JSON Payload Must be encrypted
encryptedCVC JSON Payload Must be encrypted if present

Authentication Flows

Below are the paths and their variants according to which 3D Secure authorization requests are processed:

Frictionless

Used for lists of trusted merchants, devices, low-value transactions, and others for which the Risk Engine allows authorization without additional user involvement in the process.

@startuml
skinparam ParticipantPadding 30
skinparam BoxPadding 30
skinparam noteFontColor #FFFFFF
skinparam noteBackgroundColor #1C1E3F
skinparam noteBorderColor #1C1E3F
skinparam noteBorderThickness 1
skinparam sequence {
ArrowColor #1C1E3F
ArrowFontColor #1C1E3F
ActorBorderColor #1C1E3F
ActorBackgroundColor #FFFFFF
ActorFontStyle bold
ParticipantBorderColor #1C1E3F
ParticipantBackgroundColor #1C1E3F
ParticipantFontColor #FFFFFF
ParticipantFontStyle bold
LifeLineBackgroundColor #1C1E3F
LifeLineBorderColor #1C1E3F
}
title Authentication via Frictionless (no challenge required)
actor "Cardholder\nbrowser & phone" as Cardholder
participant "Merchant\n3DS Server" as Merchant
participant "Directory Server\ncard scheme" as DS
participant "Verestro ACS\nAccess Control Server" as ACS
participant "Issuer" as Issuer
note over Issuer
Card systems
end note
Cardholder -> Merchant: Pay with card
activate Merchant
Merchant -> DS: Authenticate \n(AReq)
activate DS
DS -> ACS: Route to ACS \n(AReq)
activate ACS
ACS -> Issuer: Card verification \n(API)
activate Issuer
ACS <-- Issuer: Card active - not blocked (ACTIVE)
deactivate Issuer
ACS -> ACS: RISK ENGINE \nDECISION: FRICTIONLESS \n(trusted merchant / device / low-value)
note over Cardholder, Issuer #1C1E3F
No challenge is presented to the cardholder -
authentication result is returned immediately
end note
ACS -> Issuer: IAV authenticationValue
ACS <-- Issuer: Acknowledged
DS <-- ACS: Authentication result \n(ARes) [transStatus=Y] \nIAV authenticationValue
Merchant <-- DS: Authentication result \n(ARes) [transStatus=Y] \nIAV authenticationValue
deactivate DS
deactivate ACS
Cardholder <-- Merchant: Transaction authorized
deactivate Merchant
@enduml

Challenge

The most commonly used path, requiring the user to authorize the transaction via the methods available to them (OTP, in APP, bio).

SMS OTP

@startuml
skinparam ParticipantPadding 30
skinparam BoxPadding 30
skinparam noteFontColor #FFFFFF
skinparam noteBackgroundColor #1C1E3F
skinparam noteBorderColor #1C1E3F
skinparam noteBorderThickness 1
skinparam sequence {
ArrowColor #1C1E3F
ArrowFontColor #1C1E3F
ActorBorderColor #1C1E3F
ActorBackgroundColor #FFFFFF
ActorFontStyle bold
ParticipantBorderColor #1C1E3F
ParticipantBackgroundColor #1C1E3F
ParticipantFontColor #FFFFFF
ParticipantFontStyle bold
LifeLineBackgroundColor #1C1E3F
LifeLineBorderColor #1C1E3F
}
title Authentication via SMS OTP with the ability to select the method by the user
actor "Cardholder\nbrowser & phone" as Cardholder
participant "Merchant\n3DS Server" as Merchant
participant "Directory Server\ncard scheme" as DS
participant "Verestro ACS\nAccess Control Server" as ACS
participant "Issuer" as Issuer
note over Issuer
Card systems
Mobile app
end note
Cardholder -> Merchant: Pay with card
activate Merchant
Merchant -> DS: Authenticate \n(AReq)
activate DS
DS -> ACS: Route to ACS \n(AReq)
activate ACS
ACS -> Issuer: Card verification \n(API)
activate Issuer
ACS <-- Issuer: Card active - not blocked (ACTIVE)
ACS -> ACS: RISK ENGINE \nDECISION: CHALLENGE
DS <-- ACS: Challenge required \n(ARes) [transStatus=C]
Merchant <-- DS: Challenge required \n(ARes)
Cardholder -> ACS: Open challenge \n(CReq)
Cardholder <-- ACS: Authentication methods \n(CRes)
Cardholder -> ACS: Method: SMS OTP \n(CReq)
ACS -> Issuer: Send one-time code \n(SMS)
deactivate Issuer
Cardholder -> ACS: Code submitted \n(CReq)
Cardholder <-- ACS: Challenge complete \n(CRes)
ACS -> Issuer: Final result \n(RReq) [transStatus=Y] \nIAV authenticationValue
ACS <-- Issuer: Acknowledged \n(RRes)
ACS -> DS: Final result \n(RReq) [transStatus=Y] \nIAV authenticationValue
DS -> Merchant: Final result \n(RReq) [transStatus=Y] \nIAV authenticationValue
DS <-- Merchant: Acknowledged \n(RRes)
deactivate Merchant
ACS <-- DS: Acknowledged \n(RRes)
deactivate DS
deactivate ACS
deactivate Merchant
@enduml

IN APP OOB

@startuml
skinparam ParticipantPadding 30
skinparam BoxPadding 30
skinparam noteFontColor #FFFFFF
skinparam noteBackgroundColor #1C1E3F
skinparam noteBorderColor #1C1E3F
skinparam noteBorderThickness 1
skinparam sequence {
ArrowColor #1C1E3F
ArrowFontColor #1C1E3F
ActorBorderColor #1C1E3F
ActorBackgroundColor #FFFFFF
ActorFontStyle bold
ParticipantBorderColor #1C1E3F
ParticipantBackgroundColor #1C1E3F
ParticipantFontColor #FFFFFF
ParticipantFontStyle bold
LifeLineBackgroundColor #1C1E3F
LifeLineBorderColor #1C1E3F
}
title Authentication via IN APP OOB with the ability to select the method by the user
actor "Cardholder\nbrowser & phone" as Cardholder
participant "Merchant\n3DS Server" as Merchant
participant "Directory Server\ncard scheme" as DS
participant "Verestro ACS\nAccess Control Server" as ACS
participant "Issuer" as Issuer
note over Issuer
Card systems
Mobile app
end note
Cardholder -> Merchant: Pay with card
activate Merchant
Merchant -> DS: Authenticate \n(AReq)
activate DS
DS -> ACS: Route to ACS \n(AReq)
activate ACS
ACS -> Issuer: Card verification \n(API)
activate Issuer
ACS <-- Issuer: Card active - not blocked (ACTIVE)
ACS -> ACS: RISK ENGINE \nDECISION: CHALLENGE
DS <-- ACS: Challenge required \n(ARes) [transStatus=C]
Merchant <-- DS: Challenge required \n(ARes)
deactivate DS
Cardholder -> ACS: Open challenge \n(CReq)
Cardholder <-- ACS: Authentication methods \n(CRes)
Cardholder -> ACS: Method: mobile app \n(CReq)
ACS -> Issuer: Push notification \n(OOB)
ACS <-- Issuer: Confirmed by cardholder \n(OOB)
deactivate Issuer
Cardholder <-- ACS: Challenge complete \n(CRes)
ACS -> Issuer: Final result \n(RReq) [transStatus=Y] \nIAV authenticationValue
activate Issuer
ACS <-- Issuer: Acknowledged \n(RRes)
deactivate Issuer
ACS -> DS: Final result \n(RReq) [transStatus=Y] \nIAV authenticationValue
activate DS
DS -> Merchant: Final result \n(RReq) [transStatus=Y] \nIAV authenticationValue
DS <-- Merchant: Acknowledged \n(RRes)
deactivate Merchant
ACS <-- DS: Acknowledged \n(RRes)
deactivate DS
deactivate Merchant
@enduml

DECOUPLED

@startuml
skinparam ParticipantPadding 30
skinparam BoxPadding 30
skinparam noteFontColor #FFFFFF
skinparam noteBackgroundColor #1C1E3F
skinparam noteBorderColor #1C1E3F
skinparam noteBorderThickness 1
skinparam sequence {
ArrowColor #1C1E3F
ArrowFontColor #1C1E3F
ActorBorderColor #1C1E3F
ActorBackgroundColor #FFFFFF
ActorFontStyle bold
ParticipantBorderColor #1C1E3F
ParticipantBackgroundColor #1C1E3F
ParticipantFontColor #FFFFFF
ParticipantFontStyle bold
LifeLineBackgroundColor #1C1E3F
LifeLineBorderColor #1C1E3F
}
title Authentication via Decoupled (asynchronous, no browser challenge window)
actor "Cardholder\nbrowser & phone" as Cardholder
participant "Merchant\n3DS Server" as Merchant
participant "Directory Server\ncard scheme" as DS
participant "Verestro ACS\nAccess Control Server" as ACS
participant "Issuer" as Issuer
note over Issuer
Card systems
Mobile app
end note
Cardholder -> Merchant: Pay with card
activate Merchant
Merchant -> DS: Authenticate \n(AReq) [decoupledRequestInd=Y]
activate DS
DS -> ACS: Route to ACS \n(AReq)
activate ACS
ACS -> Issuer: Card verification \n(API)
activate Issuer
ACS <-- Issuer: Card active - not blocked (ACTIVE)
ACS -> ACS: RISK ENGINE \nDECISION: DECOUPLED CHALLENGE
DS <-- ACS: Challenge required \n(ARes) [transStatus=D]
Merchant <-- DS: Challenge required \n(ARes) [transStatus=D]
deactivate Merchant
deactivate DS
note over Cardholder, Merchant #1C1E3F
No CReq/CRes exchange with the browser -
authentication continues out of band in the mobile app
end note
ACS -> Issuer: Push notification \n(OOB)
Cardholder <-- Issuer: Authentication request \n(mobile app)
Cardholder -> Issuer: Confirmed by cardholder \n(mobile app)
ACS <-- Issuer: Confirmed by cardholder \n(OOB)
deactivate Issuer
ACS -> Issuer: Final result \n(RReq) [transStatus=Y]
activate Issuer
ACS <-- Issuer: Acknowledged \n(RRes)
deactivate Issuer
deactivate ACS
...decoupled max time / merchant polling...
Merchant -> DS: Results request \n(RReq)
activate Merchant
activate DS
DS -> ACS: Route RReq
activate ACS
DS <-- ACS: Final result \n(RRes) [transStatus=Y] \nIAV authenticationValue
deactivate ACS
Merchant <-- DS: Final result \n(RRes) [transStatus=Y] \nIAV authenticationValue
deactivate DS
deactivate ACS
deactivate Merchant
@enduml

SPC

@startuml
skinparam ParticipantPadding 30
skinparam BoxPadding 30
skinparam noteFontColor #FFFFFF
skinparam noteBackgroundColor #1C1E3F
skinparam noteBorderColor #1C1E3F
skinparam noteBorderThickness 1
skinparam sequence {
ArrowColor #1C1E3F
ArrowFontColor #1C1E3F
ActorBorderColor #1C1E3F
ActorBackgroundColor #FFFFFF
ActorFontStyle bold
ParticipantBorderColor #1C1E3F
ParticipantBackgroundColor #1C1E3F
ParticipantFontColor #FFFFFF
ParticipantFontStyle bold
LifeLineBackgroundColor #1C1E3F
LifeLineBorderColor #1C1E3F
}
title Authentication via SPC (Secure Payment Confirmation)
actor "Cardholder\nbrowser & phone" as Cardholder
participant "Merchant\n3DS Server" as Merchant
participant "Directory Server\ncard scheme" as DS
participant "Verestro ACS\nAccess Control Server" as ACS
participant "Issuer" as Issuer
note over Issuer
Card systems
Credential registry
end note
Cardholder -> Merchant: Pay with card
activate Merchant
Merchant -> DS: Authenticate \n(AReq)
activate DS
DS -> ACS: Route to ACS \n(AReq)
activate ACS
ACS -> Issuer: Card verification \n(API)
activate Issuer
ACS <-- Issuer: Card active - not blocked (ACTIVE)
ACS -> ACS: RISK ENGINE \nDECISION: CHALLENGE (SPC supported)
DS <-- ACS: Challenge required \n(ARes) [transStatus=C]
Merchant <-- DS: Challenge required \n(ARes)
deactivate DS
Cardholder -> ACS: Open challenge \n(CReq)
Cardholder <-- ACS: SPC credential request \n(CRes) [WebAuthn options]
note over Cardholder #1C1E3F
Browser invokes the platform authenticator -
cardholder confirms with biometrics / device PIN
(no OTP, no separate mobile app)
end note
Cardholder -> Cardholder: Local WebAuthn \nauthenticator ceremony
Cardholder -> ACS: SPC assertion \n(CReq) [signed WebAuthn response]
ACS -> Issuer: Verify assertion \n(API)
ACS <-- Issuer: Assertion verified (ACTIVE)
deactivate Issuer
Cardholder <-- ACS: Challenge complete \n(CRes)
ACS -> Issuer: Final result \n(RReq) [transStatus=Y] \nIAV authenticationValue
activate Issuer
ACS <-- Issuer: Acknowledged \n(RRes)
deactivate Issuer
ACS -> DS: Final result \n(RReq) [transStatus=Y] \nIAV authenticationValue
activate DS
DS -> Merchant: Final result \n(RReq) [transStatus=Y] \nIAV authenticationValue
DS <-- Merchant: Acknowledged \n(RRes)
deactivate Merchant
ACS <-- DS: Acknowledged \n(RRes)
deactivate DS
deactivate ACS
@enduml

Declined

An authorization that ends in failure due to its absence, a failed attempt, or the fulfillment of criteria flagged by the Risk Engine.

@startuml
skinparam ParticipantPadding 30
skinparam BoxPadding 30
skinparam noteFontColor #FFFFFF
skinparam noteBackgroundColor #1C1E3F
skinparam noteBorderColor #1C1E3F
skinparam noteBorderThickness 1
skinparam sequence {
ArrowColor #1C1E3F
ArrowFontColor #1C1E3F
ActorBorderColor #1C1E3F
ActorBackgroundColor #FFFFFF
ActorFontStyle bold
ParticipantBorderColor #1C1E3F
ParticipantBackgroundColor #1C1E3F
ParticipantFontColor #FFFFFF
ParticipantFontStyle bold
LifeLineBackgroundColor #1C1E3F
LifeLineBorderColor #1C1E3F
}
title Authentication via Declined (authorization ends in failure)
actor "Cardholder\nbrowser & phone" as Cardholder
participant "Merchant\n3DS Server" as Merchant
participant "Directory Server\ncard scheme" as DS
participant "Verestro ACS\nAccess Control Server" as ACS
participant "Issuer" as Issuer
note over Issuer
Card systems
Mobile app
end note
Cardholder -> Merchant: Pay with card
activate Merchant
Merchant -> DS: Authenticate \n(AReq)
activate DS
DS -> ACS: Route to ACS \n(AReq)
activate ACS
ACS -> Issuer: Card verification \n(API)
activate Issuer
ACS <-- Issuer: Card verification result
deactivate Issuer
alt Blocked by Risk Engine \nrules or unavailable \ncard data
ACS -> ACS: RISK ENGINE \nDECISION: DECLINED \n(MCC / geolocation blacklist, blocked card, missing data)
note over Cardholder, Issuer #1C1E3F
No challenge is presented -
transaction is rejected immediately
end note
DS <-- ACS: Authentication result \n(ARes) [transStatus=N]
Merchant <-- DS: Authentication result \n(ARes) [transStatus=N]
else Challenge required but \n authentication fails
ACS -> ACS: RISK ENGINE \nDECISION: CHALLENGE
DS <-- ACS: Challenge required \n(ARes) [transStatus=C]
Merchant <-- DS: Challenge required \n(ARes)
Cardholder -> ACS: Open challenge \n(CReq)
Cardholder <-- ACS: Authentication methods \n(CRes)
Cardholder -> ACS: Method: mobile app \n(CReq)
ACS -> Issuer: Push notification \n(OOB)
activate Issuer
ACS <-- Issuer: Rejected / timed out by cardholder \n(OOB)
deactivate Issuer
Cardholder <-- ACS: Challenge failed \n(CRes)
ACS -> Issuer: Final result \n(RReq) [transStatus=N]
activate Issuer
ACS <-- Issuer: Acknowledged \n(RRes)
deactivate Issuer
DS <-- ACS: Final result \n(RRes) [transStatus=N]
deactivate ACS
Merchant <-- DS: Final result \n(RRes) [transStatus=N]
deactivate DS
end
Cardholder <-- Merchant: Transaction declined
deactivate Merchant
@enduml

Back to top