A2AP Sequence Diagram - mdoujak/A2AP GitHub Wiki
The following diagram gives a high-level presentation of the interaction between a merchant, a holder, and a bank to pay during the checkout. The diagram delineates the scope of the "demonstrator" and shows which roles are in scope and which are not.
The following roles are used:
- Merchant: exposes an API that starts the checkout over the new payment rail and at the end receives the proof of order confirmation from the customer (holder).
- Merchant Simulator: component that simulates the merchant and interacts with the holder's wallet on behalf of the merchant.
- Holder: customer of the merchant that wants to checkout from the online web shop or the PoS.
- Bank Simulator: component that simulates the bank and interacts with the holder's wallet on behalf of the bank.
- Bank: exposes an API ro receive pamynet orders and respond with an order confirmation.
test
sequenceDiagram
autonumber
accTitle: Account to Account Payment
accDescr: Sequence diagram for A2A using SSI technology
participant merchant as Merchant Checkout API
participant mssi as Merchant Simulator
actor Holder
participant bssi as Bank Simulator
participant bank as Bank Payment API
rect rgb(255,211,92)
note over merchant, bank: Initiation of the flow starts with the payment selection on the checkout page.<br/>The customer select the A2AP rail.
Holder->>merchant: Pay with A2AP
merchant->>+mssi: Request payment with invoice data
end
note over merchant, bank: this is where the A2AP simulation starts.
mssi->>Holder: Merchant presents QR Code of Holder.<br/>This is an offer for a VC
Holder->>mssi: Customer accepts the VC offer
mssi->>Holder: deliver invoice VC and<br/>QR Code to request payment promise
rect rgb(164,196,0)
note over merchant, bank: This part of the flow uses a different Window or an Overlay of the current window.<br/>In a mobile-only situation this could also be achieved with app switches.<br/>The Holder connects to the Bank<br/>to authenticate with Bank ID VC and<br/>present the invoice VC
Holder->>bssi: Start invoice upload flow
bssi->>Holder: QR Code to request Bank ID and Invoice
Holder->>bssi: Present VP with invoice VC and Bank ID
note over merchant, bank: The authentication was successful, <br/>the validation of the invoice and the Merchant were successful, and <br/>the Bank now processes the invoice.
bssi->>bssi: validate Bank ID and invoice VC
note over merchant, bank: This step is outside the PoC simulation
bssi->>bank: request payment promise from API
bank->>bssi: returns payment promise details
note over merchant, bank: The Bank now presents another QR Code to offer the payment promise to the Holder
bssi->>Holder: QR Code offers payment promise
Holder->>bssi: Accept payment promise
bssi->>Holder: Deliver payment promise
end
note over merchant, bank: Now we can finally read the QR Code from above and present the Payment Promise to the Merchant
Holder->> mssi: Scan QR Code from Merchant
mssi->>Holder: Request Payment Promise from Holder
Holder->>mssi: Present payment promise to Merchant
mssi->>mssi: Validate Payment promise
note over merchant, bank: Now we can finally read the QR Code from above and present the Payment Promise to the Merchant
mssi->>-merchant: Response on the intial request<br/>with data extracted from the payment promise
rect rgb(255,211,92)
note over merchant, bank: This step is out of scope of the PoC.<br/>It is done some time after the payment promise was issued.<br/>maybe a batch process during the night.
bssi->>mssi: payment execution over SIC
end
The part with the green background color is the communication between Holder and Bank. The initial steps and the remainder of the flow are the communication between Holder and Merchant.
The parts with yellow color are out of scope of the PoC.