From 339c59ba118915cbe05b51b7e0909b45ea160ce1 Mon Sep 17 00:00:00 2001 From: Marcello Stanisci Date: Mon, 21 Mar 2016 16:41:40 +0100 Subject: moving here wallet papers forlder --- articles/ui/figs/cc3ds.pml | 96 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 96 insertions(+) create mode 100644 articles/ui/figs/cc3ds.pml (limited to 'articles/ui/figs/cc3ds.pml') diff --git a/articles/ui/figs/cc3ds.pml b/articles/ui/figs/cc3ds.pml new file mode 100644 index 000000000..90fc33008 --- /dev/null +++ b/articles/ui/figs/cc3ds.pml @@ -0,0 +1,96 @@ +# FROM: https://github.com/w3c/webpayments/tree/gh-pages/PaymentFlows + +@startuml +!includeurl https://raw.githubusercontent.com/w3c/webpayments/gh-pages/PaymentFlows/skin.ipml + +Participant "Payee (Merchant) PSP [Acquirer]" as MPSP +Participant "Payee (Merchant) [Acceptor] Site " as Payee +Actor "Payer (Shopper) [Cardholder] Browser" as Payer +participant "Browser Form Filler" as UA +participant "Card Scheme Directory" as CSD +participant "Issuing Bank [Issuer] Website" as CPSPW +participant "Issuing Bank [Issuer]" as CPSP + +note over Payee, Payer: HTTPS + +title +Legacy Merchant Hosted Card Payment with Acquirer Supported 3DS (Current) + +3DS is used to add confidence that the payer is who they say they are and importantly in the event of a dispute liability shift to the Issuer. +end title + +== Establish Payment Obligation == + +Payee->Payer: Present Check-out page with Pay Button +Payer->Payer: Select Card Payment Method + +alt + UA->Payer: Form Fill + Note right: fields are PAN & Expiry Date with optional CVV, & Address, Also Card Valid Date and Issue Number are required for some Schemes +else + Payer->Payer: User Fills Form +End + +== Card Payment Initiation == + +Payer->Payee: Payment Initiation +Note right: Custom code on merchant webpage can encrypt payload to reduce PCI burden from SAQ D to SAQ A-EP + +opt + Payee->Payee: Store Card + note right: Merchant can store card details apart from CVV (even if encrypted) for future use (a.k.a. Card on File) +end + +Payee-\MPSP: Authorise + + +== 3DS part of flow == + +Note over MPSP, Payee: At this point, the Merchant or Merchant's PSP can decide if it wishes to invoke 3DS. This might be based on transaction value (i.e. low value -> low risk) or other factors, e.g. if the Shopper is a repeat purchaser. + + MPSP –> CSD: BIN to URL lookup (VAReq message) + CSD -> CSD: Lookup URL from BIN + CSD –> CPSPW : “PING” + note right: verify URL validity + CPSPW –> CSD: “PING” response + CSD –> MPSP: URL + + MPSP-/Payee: 3DS redirect (PAReq message) + Payee->Payer: 3DS redirect (PAReq message) + Payer->CPSPW: 3DS invoke + CPSPW-\Payer: 3DS challenge + Payer-/CPSPW: 3DS response (PARes message) + CPSPW->Payer: 3DS response (PARes message) + Payer->Payee: 3DS response (PARes message) + Payee-\MPSP: 3DS response (PARes message) + + MPSP->MPSP: Verification of PARes signature + +== End of 3DS == + + +MPSP-\CPSP: Authorisation Request +CPSP-/MPSP: Authorisation Response + +MPSP-/Payee: Authorisation Response + +== Notification == + +Payee->Payer: Result Page + +== Request for Settlement process (could be immediate, batch (e.g. daily) or after some days) == + +Alt + Payee -> MPSP : Capture + note right: Later Capture may be called, for example after good shipped or tickets pickedup +Else + MPSP -> MPSP : Auto Capture in batch processing at end-of-day +End + +MPSP->CPSP: Capture + +== Fulfilment == + +Payee->Payer: Provide products or services + +@enduml -- cgit v1.2.3