diff --git a/BusinessModelDefinitions_October2015_W3C_Highlights.xlsx b/BusinessModelDefinitions_October2015_W3C_Highlights.xlsx deleted file mode 100755 index b6ef533..0000000 Binary files a/BusinessModelDefinitions_October2015_W3C_Highlights.xlsx and /dev/null differ diff --git a/Flow.Update.pptx b/Flow.Update.pptx deleted file mode 100644 index 48f721b..0000000 Binary files a/Flow.Update.pptx and /dev/null differ diff --git a/PSD2 about Payment Initiation 4 Feb 2016 b/PSD2 about Payment Initiation 4 Feb 2016 deleted file mode 100644 index 9b10a24..0000000 --- a/PSD2 about Payment Initiation 4 Feb 2016 +++ /dev/null @@ -1,3082 +0,0 @@ - - - - - - - - - - - - - - - - - - - -
- -

What PSD2 says about Payment initiation -services and Payment Initiation Service Providers (PISP).

- -

 

- - -

Table

-

1. There are now legal definitions of - what a Payment Initiation and a Payment Initiation Service Provider are. 2

-

2. Some precisions about what is - called "payment initiation services". 2

-

3. Payment Initiation Service - Providers can work as equal partners with Account Service Providers, their - relationship with Account Service Providers is regulated in every respect: - access to accounts, obligations for the account SP, obligation for the PISP…No - discrimination for the PISP. 2

-

4. Capital constraints on Payment - Initiation Service Providers are mitigated. 4

-

5. No extra costs imposed to customers - when using PISP. 4

-

6. Same protections for the customers. 4

-

7. Strong customer authentication is - also for PISP, with a special mention about the "dynamic link" and - applicable standards will be regulated by the European Banking Authority (EBA) 4

-

8. The minimum data that the PISP must - provide in the flow to the payee and payer are defined. 5

-

9. Responsibilities of the - participants are defined, with a concern on customer protection, especially - regarding "unauthorized transactions", impossibility to refuse the - payment 6

-

10. The protection of the payee is - included (irrevocability, defective transaction) 7

-

 

- - -

 

- -

 

- -

Reference: http://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32015L2366&from=FR

- -
- - -

 

- -

 

- -

1.   There are now legal definitions of -what a Payment Initiation and a Payment Initiation Service Provider are

- -

Page 58:

- -

Definition

- -

‘payment initiation service’ means a service to initiate a payment order -at the request of the payment service user with respect to a payment account -held at another payment service provider;

- -

‘payment initiation service provider’ -means a payment service provider pursuing business activities as referred to in -point (7) of Annex I;

- -

(remark: this annex gives a list of what -is called payment services, but does not detail the concept of ‘payment -initiation service provider’)

- -

Page 59:

- -

‘sensitive -payment data’ means data, including personalised security credentials which can -be used to carry out fraud. For the activities of payment initiation service -providers and account information service providers, the name of the account owner and the account number do not constitute -sensitive payment data;

- -

2.   Some precisions about what is called -"payment initiation services"

- -

page 39:

- -

…payment initiation services in the field of e-commerce have evolved. -Those payment services play a part in e-commerce payments by establishing a software bridge between the website of the -merchant and the online banking platform of the payer’s account servicing -payment service provider in order to initiate internet payments on the basis of -a credit transfer.

- -

Payment -initiation services enable the payment initiation service provider to provide -comfort to a payee that the payment has been initiated in order to provide an -incentive to the payee to release the goods or to deliver the service without -undue delay. Such services offer a low-cost solution for both merchants and -consumers and provide consumers with a possibility to shop online even if they -do not possess payment cards. Since payment initiation services are currently -not subject to Directive 2007/64/EC, they are not necessarily supervised by a -competent authority and are not required to comply with Directive 2007/64/EC. -This raises a series of legal issues, such as consumer protection, security and -liability as well as competition and data protection issues, in particular -regarding protection of the payment service users’ data in accordance with -Union data protection rules. The new rules should -therefore respond to those issues.

- -

3.   Payment Initiation Service Providers -can work as equal partners with Account Service Providers, their relationship -with Account Service Providers is regulated in every respect: access to -accounts, obligations for the account SP, obligation for the PISP…No -discrimination for the PISP

- -

 

- -

page 40:

- -

Payment initiation service providers do -not necessarily enter into a contractual relationship with the account -servicing payment service providers and, regardless of the business model -used by the payment initiation service providers, the account servicing payment -service providers should make it -possible for payment initiation service providers to rely on the authentication -procedures provided by the account servicing payments service providers to -initiate a specific payment on behalf of the payer.

- -

When -exclusively providing payment initiation services, the payment initiation -service provider does not at any stage of the payment chain hold the user’s -funds. When a payment initiation service provider -intends to provide payment services in relation to which it holds user funds, -it should obtain full authorisation for those services.

- -

Payment -initiation services are based on direct or indirect access for the payment -initiation service provider to the payer’s account. An account servicing payment -service provider which provides a mechanism for indirect access should also -allow direct access for the payment initiation service providers.

- -

Any -payment service provider, including the account servicing payment service -provider of the payment service user, should be able to offer payment -initiation services.

- -

Page 92:

- -

Article -66

- -

Rules on -access to payment account in the case of payment initiation services

- -

1. Member States shall ensure that a payer -has the right to make use of a payment initiation service provider to obtain -payment services as referred to in point (7) of Annex I. The right to make use of a payment initiation service provider shall not -apply where the payment account is not accessible online.

- -

2. When -the payer gives its explicit consent for a payment to be executed in accordance -with Article 64, the account servicing -payment service provider shall perform the actions specified in paragraph 4 of -this Article in order to ensure the payer’s right to use the payment initiation -service.

- -

The -payment initiation service provider shall:

- -

(a) not -hold at any time the payer’s funds in connection with the provision of the -payment initiation service;

- -

(b) ensure that the personalised security -credentials of the payment service user are not, with the exception of the user -and the issuer of the personalised security credentials, accessible to other -parties and that they are transmitted by -the payment initiation service provider through safe and efficient channels; -

- -

(c) ensure that any other information -about the payment service user, obtained when providing payment initiation -services, is only provided to the payee and only with the payment service -user’s explicit consent;

- -

(d) every time a payment is initiated, identify itself towards the account -servicing payment service provider of the payer and communicate with the account servicing payment service provider, the -payer and the payee in a secure way, in accordance with point (d) of -Article 98(1);

- -

(e) not store sensitive payment data of -the payment service user;

- -

(f) not request from the payment service -user any data other than those necessary to provide the payment initiation -service;

- -

(g) not use, access or store any data for -purposes other than for the provision of the payment initiation service as -explicitly requested by the payer;

- -

(h) not modify the amount, the payee or -any other feature of the transaction.

- -

 

- -

The account servicing payment service provider -shall:

- -

(a) communicate -securely with payment initiation service providers in accordance with point -(d) of Article 98(1);EN L 337/92 Official Journal of the European -Union 23.12.2015

- -

(b) immediately after receipt of the -payment order from a payment initiation service provider, provide or make available all information on the initiation of the -payment transaction and all information accessible to the account servicing -payment service provider regarding the execution of the payment transaction to -the payment initiation service provider;

- -

(c) treat payment orders transmitted through -the services of a payment initiation service provider without any discrimination other than for objective reasons, in particular in terms of timing, -priority or charges vis-à-vis payment orders transmitted directly by the payer.

- -

 

- -

The provision of payment initiation -services shall not be dependent on the existence of a contractual relationship -between the payment initiation service providers and the account servicing -payment service providers for that purpose.

- -

…

- -

4.   Capital constraints on Payment Initiation -Service Providers are mitigated

- -

page 40:

- -

Payment -service providers that provide only -payment initiation services should be considered to be of a medium risk with -regard to the initial capital.

- -

Payment -initiation service providers and account information service providers, when -exclusively providing those services, do not hold client funds. Accordingly, it would be disproportionate to impose own -funds requirements on those new market players. Nevertheless, it is -important that they be able to meet their liabilities in relation to their -activities. They should therefore be required to hold either professional -indemnity insurance or a comparable guarantee. EBA should -develop guidelines in accordance with...

- -

5.   No extra costs imposed to customers -when using PISP

- -

page 46:

- -

Since the payment service provider’s -request and the confirmation on the availability of the funds can be made -through existing secure communication channels, technical procedures and infrastructure -for communication between payment initiation service providers or account -information service providers and account servicing payment service providers, -while respecting the necessary security measures, there should be no additional costs for payment services providers -or cardholders.

- -

6.   Same protections for the customers

- -

Page 47:

- -

In order -to ensure a high level of consumer protection, payers should always be entitled to address their claim to a refund to -their account servicing payment service provider, even where a payment initiation service provider is involved in the -payment transaction.

- -

In the -case of payment initiation services, rights and obligations of the payment -service users and of the payment service providers involved should be -appropriate to the service provided. Specifically, the allocation of liability -between the payment service provider servicing the account and the payment -initiation service provider involved in the transaction should compel them to take -responsibility for the respective parts of the transaction that are under their -control.

- -

7.   Strong customer authentication is -also for PISP, with a special mention about the "dynamic link" and applicable -standards will be regulated by the European Banking Authority (EBA)

- -

Page 51:

- -

The -payment initiation service providers and the account information service -providers on the one hand and the account servicing payment service provider on -the other, should observe the necessary data protection and security requirements -established by, or referred to in, this Directive… EBA should also specify the -requirements of common and open standards of communication to be implemented by -all account servicing payment service providers that allow for the provision of -online payment services. This means that those -open standards should ensure the interoperability of different technological -communication solutions. Those common and open standards should also ensure that the account servicing payment service provider is aware that -he is being contacted by a payment initiation service provider or an account -information service provider and not by the client itself.

- -

The -standards should also ensure that payment initiation service providers and -account information service providers communicate with the account servicing -payment service provider and with the customers involved in a secure manner. In developing those requirements, EBA should -pay particular attention to the fact that the standards to be applied are to -allow for the use of all common types of -devices (such as computers, tablets and mobile phones) for carrying out -different payment services.

- -

Page 106:

- -

Article -97

- -

Authentication

- -

1. Member -States shall ensure that a payment service provider applies strong customer authentication where the payer:

- -

(a) accesses its payment account online;

- -

(b) initiates an electronic payment -transaction;

- -

(c) carries out any action through a -remote channel which may imply a risk of payment fraud or other abuses.

- -

2. With -regard to the initiation of electronic payment transactions as referred to in -point (b) of paragraph 1, Member States shall ensure that, for electronic remote payment transactions, payment service providers -apply strong customer authentication that includes elements which dynamically -link the transaction to a specific amount and a specific payee.

- -

3. With -regard to paragraph 1, Member States shall ensure that payment service -providers have in place adequate security -measures to protect the confidentiality and integrity of payment service users’ -personalised security credentials.

- -

4. -Paragraphs 2 and 3 shall also apply where payments are initiated through a -payment initiation service provider. Paragraphs 1 and 3 shall also apply when -the information is requested through an account information service provider.

- -

5. Member -States shall ensure that the account servicing payment service provider allows -the payment initiation service provider and the account information service -provider to rely on the authentication procedures provided by the account -servicing payment service provider to the payment service user in accordance -with paragraphs 1 and 3 and, where the payment initiation service provider is -involved, in accordance with paragraphs 1, 2 and 3.

- -

Page 106:

- -

Article -98

- -

Regulatory -technical standards on authentication and communication

- -

EBA shall, in close cooperation with the ECB and -after consulting all relevant stakeholders, including those in the payment -services market, reflecting all interests involved, develop draft regulatory -technical standards addressed to payment service providers

- -

…

- -

(d) the -requirements for common and secure open standards of communication for the -purpose of identification, authentication, notification, and information, as -well as for the implementation of security measures, between account servicing -payment service providers, payment initiation service providers, account -information service providers, payers, payees and other payment service -providers.

- -

8.   The minimum data that the PISP must -provide in the flow to the payee and payer are defined

- -

Page 82:

- -

Article -46

- -

Information -for the payer and payee after the initiation of a payment order

- -

In -addition to the information and conditions specified in Article 45, where a -payment order is initiated through a payment initiation service provider, the -payment initiation service provider shall, immediately after initiation, -provide or make available all of the -following data to the payer and, where applicable, the payee:

- -

(a) confirmation -of the successful initiation of the payment order with the payer’s account -servicing payment service provider;

- -

(b) a reference -enabling the payer and the payee to identify the payment transaction and, where -appropriate, the payee to identify the payer, and any information transferred with the payment transaction;

- -

(c) the amount of the payment transaction;

- -

(d) where applicable, the amount of any charges payable to the -payment initiation service provider for the transaction, and where applicable a breakdown of the amounts of such charges.

- -

Page 83:

- -

Article -47

- -

Information -for payer’s account servicing payment service provider in the event of a -payment initiation service

- -

Where a -payment order is initiated through a payment initiation service provider, it -shall make available to the payer’s account servicing payment service provider -the reference of the payment -transaction.

- -

Article -48

- -

Information -for the payer after receipt of the payment order

- -

Immediately -after receipt of the payment order, the payer’s payment service provider shall -provide the payer with or make available to the payer, in the same way as -provided for in Article 44(1), all of the following data with regard to its own -services:

- -

(a) a reference -enabling the payer to identify the payment transaction and, where appropriate, -information relating to the payee;

- -

(b) the amount of the payment transaction in the currency used in the -payment order;

- -

(c) the amount of any charges for the payment transaction payable by the -payer and, where applicable, a breakdown of the amounts of such charges;

- -

(d) where applicable, the exchange rate used in the payment -transaction by the payer’s payment service provider or a reference thereto, -when different from the rate provided in accordance with point (d) of Article -45(1), and the amount of the payment -transaction after that currency conversion;

- -

Page 89:

- -

Where a -currency conversion service is offered prior to the initiation of the payment -transaction and where that currency conversion service is offered at an ATM, at -the point of sale or by the payee, the party offering the currency conversion -service to the payer shall disclose to the payer all charges as well as the -exchange rate to be used for converting the payment transaction.

- -

Where, -for the use of a given payment instrument, the payee requests a charge or -offers a reduction, the payee shall inform -the payer thereof prior to the initiation of the payment transaction.

- -

Where, -for the use of a given payment instrument, the payment service provider or -another party involved in the transaction requests a charge, it shall inform -the payment service user thereof prior to the initiation of the payment -transaction.

- -

9.   Responsibilities of the participants -are defined, with a concern on customer protection, especially regarding -"unauthorized transactions", impossibility to refuse the payment

- -

Page 95 -and 96:

- -

Article -72

- -

Evidence -on authentication and execution of payment transactions

- -

1. Member -States shall require that, where a -payment service user denies having authorised an executed payment -transaction or claims that the payment transaction was not correctly executed, it is for the payment service provider to -prove that the payment transaction was authenticated, accurately recorded, -entered in the accounts and not affected by a technical breakdown or some other -deficiency of the service provided by the payment service provider.

- -

If the -payment transaction is initiated through a payment initiation service provider, -the burden shall be on the payment initiation service provider to prove that -within its sphere of competence, the payment transaction was authenticated, -accurately recorded and not affected

- -

Where a payment service user denies having -authorised an executed payment transaction, the use of a payment instrument recorded -by the payment service provider, including the payment initiation service -provider as appropriate, shall in itself -not necessarily be sufficient to prove either that the payment transaction -was authorised by the payer or that the payer acted fraudulently or failed with -intent or gross negligence to fulfil one or more of the obligations under -Article 69. The payment service -provider, including, where appropriate, the payment initiation service provider, -shall provide supporting evidence to prove fraud or gross negligence on -part of the payment service user.

- -

Page 96:

- -

Article -73

- -

Payment -service provider’s liability for unauthorised payment transactions

- -

…

- -

Where the -payment transaction is initiated through a payment initiation service provider, -the account servicing payment service -provider shall refund immediately, and in any event no later than by the -end of the following business day the -amount of the unauthorised payment transaction and, where applicable, -restore the debited payment account to the state in which it would have been -had the unauthorised payment transaction not taken place.

- -

If the payment initiation service provider -is liable for the unauthorised payment transaction, it shall immediately -compensate the account servicing payment service provider at its request for the losses incurred or -sums paid as a result of the refund to the payer, including the amount of the -unauthorised payment transaction.

- -

Page 99:

- -

Article -79

- -

Refusal -of payment orders

- -

Where all -of the conditions set out in the payer’s framework contract are met, the -payer’s account servicing payment service provider shall not refuse to execute an authorised payment order irrespective -of whether the payment order is initiated by a payer, including through a -payment initiation service provider, or by or through a payee, unless -prohibited by other relevant Union or national law.

- -

10.                  -The -protection of the payee is included (irrevocability, defective transaction)

- -

Page 99:

- -

Article -80

- -

Irrevocability -of a payment order

- -

Where the -payment transaction is initiated by a payment initiation service provider or by -or through the payee, the payer shall -not revoke the payment order after giving consent to the payment initiation -service provider to initiate the payment transaction or after giving consent to -execute the payment transaction to the payee.

- -

Page 103:

- -

Article -90

- -

Liability -in the case of payment initiation services for non-execution, defective or late -execution of payment transactions

- -

1. Where -a payment order is initiated by the payer through a payment initiation service -provider, the account servicing payment service provider shall, without -prejudice to Article 71 and Article 88(2) and (3), refund to the payer the amount of the non- executed or defective -payment transaction and, where applicable, restore the debited payment -account to the state in which it would have been had the defective payment -transaction not taken place.

- -

The burden shall be on the payment -initiation service provider to prove that the payment order was received by the -payer’s account servicing payment service provider in accordance with Article 78 and that -within its sphere of competence the payment transaction was authenticated, -accurately recorded and not affected by a technical breakdown or other -deficiency linked to the non-execution, defective or late execution of the -transaction.

- -
- - - - diff --git a/PaymentFlows/AliPay/AliPay-Current.pml b/PaymentFlows/AliPay/AliPay-Current.pml deleted file mode 100644 index 88780b1..0000000 --- a/PaymentFlows/AliPay/AliPay-Current.pml +++ /dev/null @@ -1,34 +0,0 @@ -@startuml -!includeurl https://raw.githubusercontent.com/w3c/webpayments/gh-pages/PaymentFlows/skin.ipml - -Participant "Payee (Merchant) Site" as Payee -Actor "Payer (Shopper) Browser" as Payer -participant "AliPay" as CPSP - -note over Payer, Payee: HTTPS - -title AliPay (Current) - -Payee->Payer: Present Check-out page with Pay Button - -Payer->Payee: Select "AliPay" Payment Instrument - -Payee->CPSP: Send Transaction Details with Digital Signature - -CPSP->Payer: User's Authentication and Confirmation Request - -Payer->CPSP: Authentication and Confirmation Response - -Note over CPSP: Risk Monitoring -Note over CPSP: Pay from PSP/bank's account - -CPSP->Payer: Notification -CPSP->Payee: Notification - -== Fulfilment == - -Payee->Payer: Provide products or services - -@enduml - - diff --git a/PaymentFlows/AlternativePayment/BankMobileWalletsCheckout.pml b/PaymentFlows/AlternativePayment/BankMobileWalletsCheckout.pml deleted file mode 100755 index 630844a..0000000 --- a/PaymentFlows/AlternativePayment/BankMobileWalletsCheckout.pml +++ /dev/null @@ -1,29 +0,0 @@ -@startuml -!includeurl https://raw.githubusercontent.com/w3c/webpayments/gh-pages/PaymentFlows/skin.ipml - -Participant "Payee (Merchant)\nPSP" as MPSP -Participant "Payee (Merchant)\nWeb Site" as Payee -Participant "Browser" as UA -Actor "Payer (Shopper)" as Payer -Participant "Bank Mobile Wallet" as Wallet -Participant "Bank Wallet Server" as WS - -note over Payee, Payer: HTTPS - -title Mobile Bank Wallet - "Pay with..." Button - -Payee->UA: Present Check-out page with Pay Button -Payer->UA: Select "Pay with ..." Payment Instrument - -UA->WS: Display Wallet Notification Page -WS->Wallet: Notify Payment Request -Wallet->Payer: Display Payment Info -Payer->Wallet: Confirm Payment, Payer Details and Authenticate -Wallet->WS: Signed payment confirmation - -WS->Payee: Callback with encrypted payment details and credentials, optional signed confirmation -Payee->MPSP: Payment -MPSP->Payee: Payment Result - -Payee->UA: Payment Result -@enduml diff --git a/PaymentFlows/AlternativePayment/MasterPassStandardCheckout-Current.pml b/PaymentFlows/AlternativePayment/MasterPassStandardCheckout-Current.pml deleted file mode 100755 index bdd516d..0000000 --- a/PaymentFlows/AlternativePayment/MasterPassStandardCheckout-Current.pml +++ /dev/null @@ -1,60 +0,0 @@ -@startuml -!includeurl https://raw.githubusercontent.com/w3c/webpayments/gh-pages/PaymentFlows/skin.ipml - -Participant "Payee (Merchant) PSP" as PSP -Participant "Payee (Merchant) Site" as Payee -Actor "Payer (Shopper) User Agent" as Payer -Participant "MasterPass Server" as MP -Participant "Payer (Shopper) MasterPass\nPartner Hosted Wallet" as PIP - -note over Payee, Payer: HTTPS - -title MasterPass-type Payment Flow [Simplified] - -Payee->Payer: Present Check-out page with Pay Button -Payer->Payee: Select "Pay with MasterPass" Payment Method - -== MasterPass specific flow starts == - -Payee->MP: Hand control to MasterPass -Note right: Redirect or iFrame -MP->Payer: Display Wallet Selector UI -Payer->MP: Select Partner Hosted Wallet -MP->PIP: Redirect to Wallet Checkout page -PIP->Payer: Display Sign in page - -note over Payer,PIP: Sign in is Partner specific (for instance, can go through mobile app) - -Payer->PIP: Supply credentials -PIP->MP: Get Accepted Card Brands &\nAddress Verification -MP->PIP: Return Cards - - -Alt - PIP->Payer: Display Card -Else - PIP->Payer: Display Card with Shipping Address Selection UI - Payer->PIP: Card & Shipping Address Selection -End - -note over Payer: can also be in mobile app - -PIP->MP: Finalise Shopping -MP-->PIP: Compute Merchant Callback URL -PIP->Payee: Redirect to Merchant through Callback URL -Payee->MP: Get Checkout Data -MP-->Payee: Card Number & Shipping Address - -== MasterPass specific flow ends == - -group opt - Payee->Payer: Capture CVV - Payer->Payee: CVV input -end group - -Payee->Payer: Display order summary -Payee->PSP: Submit Card Not Present Transaction with Card, CVV &\nAddress (if required) -PSP-->Payee: Payment confirmation -Payee->Payer: Display confirmation page - -@enduml \ No newline at end of file diff --git a/PaymentFlows/AlternativePayment/MerchantPSPIntermediated-GenericRedirectPayment-Current.pml b/PaymentFlows/AlternativePayment/MerchantPSPIntermediated-GenericRedirectPayment-Current.pml deleted file mode 100644 index 5feeb6b..0000000 --- a/PaymentFlows/AlternativePayment/MerchantPSPIntermediated-GenericRedirectPayment-Current.pml +++ /dev/null @@ -1,73 +0,0 @@ -@startuml -!includeurl https://raw.githubusercontent.com/w3c/webpayments/gh-pages/PaymentFlows/skin.ipml - -Participant "Payee (Merchant) PSP" as MPSP -Participant "Payee (Merchant) Site" as Payee -Actor "Payer (Shopper) Browser" as Payer -participant "Payer (Shopper) PSP" as CPSP - -note over MPSP, CPSP: HTTPS - -title Merchant PSP Intermediated Generic Push Payment (Current) - -Payee->Payer: Basket Page with Pay Button - -Payer->Payer: Press Pay - -Payer-\Payee: Payment Page Request - -Payee-\MPSP: Payment Page Request - -MPSP-/Payee: HTTP Redirect - -Payee-/Payer: HTTP Redirect - -Payer-\MPSP: Payment Request - -opt - - MPSP-/Payer: Payment Choice Page - - Payer->Payer: Select Payment Instrument - - Payer-\MPSP: Payment Instrument Page Request - - note right: This option is used where the merchant want to support many payment methods -end - -MPSP-/Payer: HTTP Redirect - -Payer-\CPSP: Payment Initiation - -CPSP-/Payer: Authentication Page - -Payer-\CPSP: Authenticate -note right: Typically a username & password - -CPSP-/Payer: Payment Page - -opt - Payer<->CPSP: Instrument Choice - note right: For Wallets with multiple payment instruments -end - -Payer->Payer: Agreement - -Payer-\CPSP: Payment Confirmation - -CPSP-/Payer: Payment Response - -Payer-\Payee: Payment Response - -Payee-/Payer: Result Page - -... asynchronous notification ... - -CPSP->MPSP: Payment Response - -MPSP->Payee: Payment Notification - -Note right: Provides out of band confirmation to protect against failure/modification at browser - - -@enduml diff --git a/PaymentFlows/ApplePay/ApplePay-Native-Current.pml b/PaymentFlows/ApplePay/ApplePay-Native-Current.pml deleted file mode 100644 index e11dcf5..0000000 --- a/PaymentFlows/ApplePay/ApplePay-Native-Current.pml +++ /dev/null @@ -1,40 +0,0 @@ -@startuml -!includeurl https://raw.githubusercontent.com/w3c/webpayments/gh-pages/PaymentFlows/skin.ipml - -Participant "Payee (Merchant)\nPSP" as MPSP -Participant "Payee (Merchant)\nServer" as Payee -Participant "Payee (Merchant)\nApplication" as UA -Actor "Payer (Shopper)" as Payer -Participant "Apple Pay Agent\n(SDK/Wallet/Payment Sheet)" as CPSP -Participant "Apple Pay\nServers" as APS -Participant "Apple Pay\nSecure Element" as SE - -note over Payee, Payer: HTTPS - -title Apple Pay - Native (Current) - -UA->Payer: Basket Page with Pay Button -Payer->UA: Pay with Apple Pay - -UA->CPSP: Display Apple Pay Payment Sheet -CPSP->Payer: Payment Sheet & Request TouchID -Payer->CPSP: Provide TouchID -Payer->CPSP: Provide shipping method and address - -CPSP->SE: Generate payment token -note over SE: Package payment credentials and details,\nencrypt with Apple Pay Servers key -SE->APS: Encrypted Payment Token -APS->CPSP: Re-encrypted Payment Token -note over APS: Re-encrypted with merchant public key - -CPSP->UA: Payment Token & Customer Details -UA->Payee: Payment Token & Customer Details -Payee->MPSP: Payment Token - -note over MPSP: Decrypt payment token on behalf of Merchant,\nwith Merchant private key - -MPSP->Payee: Payment Result - -Payee->UA: Payment Result -UA->Payer: Payment Result -@enduml diff --git a/PaymentFlows/Bitcoin/Basic-Bitcoin-Transfer.pml b/PaymentFlows/Bitcoin/Basic-Bitcoin-Transfer.pml deleted file mode 100644 index 77ba916..0000000 --- a/PaymentFlows/Bitcoin/Basic-Bitcoin-Transfer.pml +++ /dev/null @@ -1,24 +0,0 @@ -@startuml -!includeurl https://raw.githubusercontent.com/w3c/webpayments/gh-pages/PaymentFlows/skin.ipml - -Actor "Payee" as Payee -Participant "Payee Bitcoin Node" as PayeeNode -Participant "Payer Bitcoin Node" as PayerNode -Actor "Payer" as Payer - -title Basic Bitcoin Payment - -Payee->Payee: Generate Bitcoin address -Payee->Payer: Bitcoin address and requested amount -Payer->Payer: Sign transaction - -Payer->PayerNode: Submit transaction -Payer->Payee: Notify Payee that transaction has been submitted - -loop until desired confirmations complete -PayeeNode->Payee: Get confirmed transactions from blockchain -end - -Payee->Payer: Notify payer that transaction has been confirmed - -@enduml \ No newline at end of file diff --git a/PaymentFlows/Bitcoin/Bitcoin-Payment-Protocol-(BIP70).pml b/PaymentFlows/Bitcoin/Bitcoin-Payment-Protocol-(BIP70).pml deleted file mode 100644 index ba17fde..0000000 --- a/PaymentFlows/Bitcoin/Bitcoin-Payment-Protocol-(BIP70).pml +++ /dev/null @@ -1,35 +0,0 @@ -@startuml -!includeurl https://raw.githubusercontent.com/w3c/webpayments/gh-pages/PaymentFlows/skin.ipml - -Database "Invoice Database" as DB -Participant "Payee Website" as Website -Database "Bitcoin Network" as Bitcoin -Participant "Payer Wallet" as Wallet -Actor "Payer (Browser)" as Payer - -title Bitcoin Payment Protocol (BIP70) - -Payer->Website: Request checkout with Bitcoin -Website->Website: Generate Bitcoin address -Website->DB: Store invoice details -Website->Payer: Basket Page with bitcoin: pay link -Payer->Payer: Click bitcoin: link -Payer->Wallet: Wallet handles bitcoin: URL and extracts invoice URL -Wallet->Website: Request invoice -Website->DB: Get invoice details -Website->Website: Create PaymentDetails (Amount, Memo, Ref#, Pay URL) -Website->Website: Create PaymentRequest (Signed PaymentDetails) -Website->Wallet: PaymentRequest containing PaymentDetails -Wallet->Payer: Confirm payment details? -Payer->Wallet: Accept payment -Wallet->Wallet: Generate and sign payment -Wallet->Website: Signed payment -Website->Bitcoin: Submit payment -Website->Wallet: Payment ACK -Wallet->Payer: Confirm payment is complete -loop until payment is confirmed - Bitcoin->Website: Latest confirmed transactions -end - - -@enduml \ No newline at end of file diff --git a/PaymentFlows/Card/MerchantHosted-CardPayment-Current.pml b/PaymentFlows/Card/MerchantHosted-CardPayment-Current.pml deleted file mode 100644 index 7eadf36..0000000 --- a/PaymentFlows/Card/MerchantHosted-CardPayment-Current.pml +++ /dev/null @@ -1,63 +0,0 @@ -@startuml -!includeurl https://raw.githubusercontent.com/w3c/webpayments/gh-pages/PaymentFlows/skin.ipml - -Participant "Payee (Merchant) PSP [Acquirer]" as MPSP -Participant "Payee (Merchant) [Acceptor] Website" as Payee -participant "Payer's (Shopper's) Browser" as UA -Actor "Payer [Cardholder]" as Payer -participant "Issuing Bank [Issuer]" as CPSP - -note over Payee, Payer: HTTPS - -title Legacy Merchant Hosted Card Payment (Current) - -== Negotiation of Payment Terms & Selection of Payment Instrument == - -Payee->UA: Present Check-out page -Payer<-[#green]>UA: Select Checkout with Card -Payer<-[#green]>UA: Select Card Brand -Payer<-[#green]>UA: Payer Fills Form (PAN, Expiry, [Issue Number | Start Date], [CVV], [Billing Address]) -Note right: May be auto-filled from browser - -== Payment Processing == - -Alt - UA->Payee: payload -Else - UA->Payee: Encrypt(payload) - Note right: Custom code on merchant webpage can encrypt payload to reduce PCI burden from SAQ D to SAQ A-EP -End - -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 (payload) - -MPSP-\CPSP: Authorisation Request -CPSP-/MPSP: Authorisation Response - -MPSP-/Payee: Authorisation Result - -== Notification == - -Payee->UA: Result Page - -== Payment Processing Continued: 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 - -== Delivery of Product == - -Payee->Payer: Provide products or services - - -@enduml diff --git a/PaymentFlows/Card/MerchantHosted-CardPaymentwith3DS-Current.pml b/PaymentFlows/Card/MerchantHosted-CardPaymentwith3DS-Current.pml deleted file mode 100644 index 9e583b6..0000000 --- a/PaymentFlows/Card/MerchantHosted-CardPaymentwith3DS-Current.pml +++ /dev/null @@ -1,92 +0,0 @@ -@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 -participant "Payer's (Shopper's) Browser" as UA -Actor "Payer [Cardholder]" as Payer -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 - -== Negotiation of Payment Terms & Selection of Payment Instrument == - -Payee->UA: Present Check-out page -Payer<-[#green]>UA: Select Checkout with Card -Payer<-[#green]>UA: Select Card Brand -Payer<-[#green]>UA: Payer Fills Form (PAN, Expiry, [CVV], [Billing Address]) -Note right: May be auto-filled from browser - - -== Payment Processing == - -UA->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 - - -== 3D Secure == - -Note over UA: At this point, the Merchant or Merchant's PSP can decide if it wishes to invoke 3DS. This is often based upon dynamic factors, e.g. if the card has been used before or if shipping address different from billing address - - 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->UA: 3DS redirect (PAReq message) - UA->CPSPW: 3DS invoke - CPSPW-\UA: 3DS challenge - Payer<-[#green]>UA: Enter 3D Secure credentials - UA-/CPSPW: 3DS response (PARes message) - CPSPW->UA: 3DS response (PARes message) - UA->Payee: 3DS response (PARes message) - UA-\MPSP: 3DS response (PARes message) - - MPSP->MPSP: Verification of PARes signature - -== End of 3D Secure == - - -MPSP-\CPSP: Authorisation Request -CPSP-/MPSP: Authorisation Response - -MPSP-/Payee: Authorisation Result - -== Notification == - -Payee->UA: Result Page - -== Payment Processing Continued: 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 - -== Delivery of Product == - -Payee->Payer: Provide products or services - -@enduml diff --git a/PaymentFlows/Card/MerchantHosted-CardPaymentwithTokenisation-Current.pml b/PaymentFlows/Card/MerchantHosted-CardPaymentwithTokenisation-Current.pml deleted file mode 100644 index dbaad48..0000000 --- a/PaymentFlows/Card/MerchantHosted-CardPaymentwithTokenisation-Current.pml +++ /dev/null @@ -1,58 +0,0 @@ -@startuml -!includeurl https://raw.githubusercontent.com/w3c/webpayments/gh-pages/PaymentFlows/skin.ipml - -Participant "Payee (Merchant) PSP [Acquirer]" as MPSP -Participant "Payee (Merchant) Website [Acceptor]" as Payee -Actor "Payer (Shopper) [Cardholder] Browser" as Payer -participant "Browser Form Filler" as UA -participant "Issuing Bank [Issuer]" as CPSP - -note over Payee, Payer: HTTPS - -title -Merchant Hosted Card Payment with Tokenisation (Current) - -Tokenisation is used to reduce PCI compliance effort. Currently when tokenisation is used in this mode it only attract a level known as SAQ A-EP -end title - -Payee->Payer: Present Check-out page with Pay Button -Payer->Payer: Select Card Payment Method - -Payer->Payer: Select Card Brand -alt - UA->Payer: Form Fill; PAN, Expiry Date, [CVV], [AVS] -else - Payer->Payer: User Fills Form -End - -Payer->MPSP: Tokenisation Request (Card Details) -MPSP->MPSP: Tokenise Card -MPSP->Payer: Card Token - -Payer->Payee: Payment Details & Card Token - -opt - Payee->Payee: Store Token - note right: Merchant can store tokens for future use (a.k.a. Card on File) -end - -Payee-\MPSP: Authorise(Payment Details & Card Token) - -MPSP->MPSP: Detokenise Card - -MPSP-/Payee: Authorisation Result - -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 - -@enduml diff --git a/PaymentFlows/Card/PSPHosted-CardPayment-Current.pml b/PaymentFlows/Card/PSPHosted-CardPayment-Current.pml deleted file mode 100644 index 8169f17..0000000 --- a/PaymentFlows/Card/PSPHosted-CardPayment-Current.pml +++ /dev/null @@ -1,47 +0,0 @@ -@startuml -!includeurl https://raw.githubusercontent.com/w3c/webpayments/gh-pages/PaymentFlows/skin.ipml - -Participant "Payee (Merchant) PSP [Acquirer & Acceptor]" as MPSP -Participant "Payee (Merchant) Site" as Payee -Actor "Payer (Shopper/Customer) [Cardholder] Browser" as Payer -participant "Browser Form Filler" as UA -participant "Payer (Shopper/Customer) PSP [Issuer] Wallet" as CPSP - -note over MPSP, Payer: HTTPS - -title -PSP Hosted Card Payment (Current) - -Payment Pages are hosted at the PSP to removed PCI burden (SAQ-A) as no card details are available on the merchants site -end title - -Payee->Payer: Present Check-out page with Pay Button - -Payer->MPSP: Press Pay - -MPSP->Payer: Payment Method Choice Page -Payer->Payer: Select Card Payment Method - -alt - UA->Payer: Form Fill; PAN, Expiry Date, [CVV], [AVS] -else - Payer->Payer: User Fills Form -End - -Payer->MPSP: payload -MPSP->Payer: Result Page Redirect -Payer->Payee: Result Page Redirect -Payee->Payer: Results Page -MPSP-[#black]>Payee: Payment Notification - -== 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 -@enduml diff --git a/PaymentFlows/CreditTransfer/PISP_under_PSD2_SCT_Flows_Merchant_PISP.pml b/PaymentFlows/CreditTransfer/PISP_under_PSD2_SCT_Flows_Merchant_PISP.pml deleted file mode 100644 index ee40b28..0000000 --- a/PaymentFlows/CreditTransfer/PISP_under_PSD2_SCT_Flows_Merchant_PISP.pml +++ /dev/null @@ -1,47 +0,0 @@ -@startuml -!includeurl https://raw.githubusercontent.com/w3c/webpayments/gh-pages/PaymentFlows/skin.ipml - -participant "Payee (Merchant) Bank [Creditor Agent]" as MB -'Participant "Payee (Merchant) PSP [Intermediary]" as MPSP -Participant "Payee (Merchant) PISP [Initiation]" as MPISP - -Participant "Payee (Merchant) Website [Creditor]" as Payee -'Participant "Payer (Shopper) PISP [Debtor]" as RPISP - -Actor "Payer (Shopper) Browser [Debtor]" as Payer - -participant "Payer (Shopper) Bank [Debtor Agent]" as CB - - -note over MPSP, Payer: HTTPS - -title (SEPA) Credit Transfer With the Merchant proposing his PISP - -Payee->Payer: Basket Page with Pay Button -Payer->MPISP: Press Pay - -MPISP->Payer: Payment Method Choice Page -Payer->MPISP: Select Credit Transfer\nand chooses his preferred PISP -Hnote over MPISP: the Merchant's PISP takes the Merchant data and generates,\n with consent of the Shopper,\n the Transfer initiation message -Payee-> MPISP: Provide Bank Transfer Details (e.g. IBAN) -Payer-> MPISP: OK -MPISP ->Payer: Result Screen "Pending Transfer" -MPISP -> Payee: "Pending Transfer" - - -group ISO20022/SEPA Credit Transfer - MPISP -[#green]> CB: SEPA msg CustomerCreditTransferInitiation\nreal-time - CB -[#green]> MPISP: SEPA msg CustomerPaymentStatusReport\nreal-time - -Hnote over MPISP: the MPISP can use the SEPA Status Report\n to inform both the Shopper and the Merchant's PSP -MPISP -> Payer: Payment approved by Shopper's Bank\nreal-time -MPISP -> Payee: Payment approved by Shopper's Bank\nreal-time - - CB -[#green]> MB : SEPA msg FIToFICustormerCreditTransfer\nbatch - MB -[#green]> MPISP : SEPA msg BankToCustomerDebitCreditNotification\nbatch -end - -MPSP-[#black]>Payee: Payment Notification (Cleared) -Payee-[#black]>Payer: Payment Notification (email) - -@enduml diff --git a/PaymentFlows/CreditTransfer/PISP_under_PSD2_SCT_Flows_Shopper_PISP.pml b/PaymentFlows/CreditTransfer/PISP_under_PSD2_SCT_Flows_Shopper_PISP.pml deleted file mode 100644 index 4d54866..0000000 --- a/PaymentFlows/CreditTransfer/PISP_under_PSD2_SCT_Flows_Shopper_PISP.pml +++ /dev/null @@ -1,47 +0,0 @@ -@startuml -!includeurl https://raw.githubusercontent.com/w3c/webpayments/gh-pages/PaymentFlows/skin.ipml - -participant "Payee (Merchant) Bank [Creditor Agent]" as MB -Participant "Payee (Merchant) PSP [Intermediary]" as MPSP -'Participant "Payee (Merchant) PISP [Initiation]" as MPISP - -Participant "Payee (Merchant) Website [Creditor]" as Payee -Participant "Payer (Shopper) PISP [Debtor]" as RPISP - -Actor "Payer (Shopper) Browser [Debtor]" as Payer - -participant "Payer (Shopper) Bank [Debtor Agent]" as CB - - -note over MPSP, Payer: HTTPS - -title (SEPA) Credit Transfer With the Shopper choosing his preferred PISP - -Payee->Payer: Basket Page with Pay Button -Payer->MPSP: Press Pay - -MPSP->Payer: Payment Method Choice Page -Payer->MPSP: Select Credit Transfer\nand chooses his preferred PISP -Hnote over RPISP: the Shopper's PISP takes the Merchant data and generates,\n with consent of the Shopper,\n the Transfer initiation message -MPSP->RPISP: Redirection to PISP page\n Provide Bank Transfer Details (e.g. IBAN) -Payer-> RPISP: OK -RPISP ->Payer: Result Screen "Pending Transfer" -RPISP ->MPSP: "Pending Transfer" - - -group ISO20022/SEPA Credit Transfer - RPISP -[#green]> CB: SEPA msg CustomerCreditTransferInitiation\nreal-time - CB -[#green]> RPISP: SEPA msg CustomerPaymentStatusReport\nreal-time - -Hnote over RPISP: the PISP can use the SEPA Status Report\n to inform both the Shopper and the Merchant's PSP -RPISP -> Payer: Payment approved by Shopper's Bank\nreal-time -RPISP -> MPSP: Payment approved by Shopper's Bank\nreal-time - - CB -[#green]> MB : SEPA msg FIToFICustormerCreditTransfer\nbatch - MB -[#green]> MPSP : SEPA msg BankToCustomerDebitCreditNotification\nbatch -end - -MPSP-[#black]>Payee: Payment Notification (Cleared) -Payee-[#black]>Payer: Payment Notification (email) - -@enduml diff --git a/PaymentFlows/CreditTransfer/WebInitiatedSEPACreditTransfer-Current.pml b/PaymentFlows/CreditTransfer/WebInitiatedSEPACreditTransfer-Current.pml deleted file mode 100644 index 9ec35cf..0000000 --- a/PaymentFlows/CreditTransfer/WebInitiatedSEPACreditTransfer-Current.pml +++ /dev/null @@ -1,51 +0,0 @@ -@startuml -!includeurl https://raw.githubusercontent.com/w3c/webpayments/gh-pages/PaymentFlows/skin.ipml - -participant "Payee (Merchant) Bank [Creditor Agent]" as MB -Participant "Payee (Merchant) PSP [Intermediary]" as MPSP -Participant "Payee (Merchant) Website [Creditor]" as Payee -participant "Payer's (Shopper's) Browser" as UA -Actor "Payer [Debtor]" as Payer -participant "Payer (Shopper) Bank [Debtor Agent]" as CB - - -note over MPSP, Payer: HTTPS - -title PSP Mediated (SEPA) Credit Transfer (Current) - -== Establish Payment Obligation == - -Payee->UA: Present Check-out page -Payer<-[#blue]>UA: Choose Checkout -UA->MPSP: Request Payment Choice Pay - -MPSP->UA: Payment Method Choice Page -Payer<-[#blue]>UA: Choose` Credit Transfer Payment Method -UA->MPSP: Request Credit Transfer Payment Information -MPSP->UA: Provide Credit Transfer Details (e.g. IBAN) -note right: These details are needed by the Payer to manually invoke the Credit Transfer out-of-band -Payer<-[#blue]>UA: Agree to Payment -UA->MPSP: Payment Obligation Accepted -MPSP->UA: Result Screen "Pending Transfer" - -MPSP-[#black]>Payee: Payment Notification (Pending) - -Note over Payer: Payer now must invoke Credit Transfer manually via some means, e.g. Phone, WebBanking etc. (automated invocation will become possible as part of PSD 2 implementation) - -== ISO20022/SEPA Credit Transfer == - - Payer -[#green]> CB: CustomerCreditTransferInitiation - CB -[#green]> Payer: CustomerPaymentStatusReport - CB -[#green]> MB : FIToFICustormerCreditTransfer - MB -[#green]> MPSP : BankToCustomerDebitCreditNotification - -== Notification == - -MPSP-[#black]>Payee: Payment Notification (Cleared) -Payee-[#black]>Payer: Payment Notification (email) - -== Fulfilment == - -Payee->Payer: Provide products or services - -@enduml diff --git a/PaymentFlows/CrossBorder/CrossBorderCreditTransferWithForeignCurrency.pml b/PaymentFlows/CrossBorder/CrossBorderCreditTransferWithForeignCurrency.pml deleted file mode 100644 index e58b1ea..0000000 --- a/PaymentFlows/CrossBorder/CrossBorderCreditTransferWithForeignCurrency.pml +++ /dev/null @@ -1,123 +0,0 @@ -@startuml -!includeurl https://raw.githubusercontent.com/w3c/webpayments/gh-pages/PaymentFlows/skin.ipml - -title Cross-border credit transfer flows\nInstructed amount is in a currency different\nfrom the Debtor's account currency. - -participant "Debtor\n(Payer)" as DBTR -participant "Debtor Agent\n(Instructing Agent)" as DA -participant "Instructing Reimbursement\nAgent" as IGRA -participant "Instructed Reimbursement\nAgent" as IDRA -participant "CreditorAgent\n(Instructed Agent)" as CA -participant "Creditor\n(Payee)" as CDTR - -== Initiation of Payment Obligation == -||| -Hnote over IGRA -The Debtor and the Creditor have entered into an agreement (or obligation, such as a web purchase, a commercial contract, a securities deal, .....) -which bounds the Debtor to pay the Creditor an agreed amount of money through a cross-border credit transfer, executed through correspondent banks. -In this scenario, the Debtor has an account in a different currency than the currency of the payment, requiring a FOREX, which will be executed -by the DebtorAgent before initiation of the interbank transfer. -end note -||| -DBTR <---> CDTR: Establish Payment Obligation -||| - -== Payment Initiation == -Hnote over DBTR -The Debtor initiates a payment to its bank - the DebtorAgent -end note -DBTR -> DA: CustomerCreditTransferInitiation -activate DA - -DA [#Orange]-> DA : (Internal Process) Execute FOREX for Debtor -activate DA #Orange -note left #Orange -(Internal Process) -The DebtorAgent executes the FOREX -from the Debtor's account currency to the currency -as agreed and established in the payment obligation. -end note -Deactivate DA #Orange -||| -== Payment Clearing == -Hnote over IDRA -The DebtorAgent instructs the payment to the beneficiary (the Creditor) through a credit transfer to the CreditorAgent. -Both DebtorAgent and CreditorAgent do not have a direct relationship in the currency of the credit transfer, -and will therefore use the "COVER" payment method, through their correspondents (or Reimbursement Agents) -end note -DA -> CA: FIToFICustomerCreditTransfer -activate CA -||| -== Payment Settlement ( through COVER Method ) == -Hnote over DA #DodgerBlue -The DebtorAgent issues an interbank credit transfer (COVER Method)to the -InstructingReimbursementAgent, through which the DebtorAgent normally settles -the credit transfers in the currency as defined in the payment obligation -between the debtor and the creditor. -end note - -DA [#Blue]-> IGRA: FinancialInstitutionCreditTransfer (COVER) -activate IGRA #Blue -Hnote over IGRA #DodgerBlue -The InstructingReimbursementAgent has a direct account relationship -with the InstructedReimbursementAgent in the settlement currency -(or through a additional ThirdReimbursementAgent - not illustrated here) -through which the amount of money is transferred from the -InstructingReimbursementAgent to the InstructedReimbursementAgent. -end note - -opt -Hnote over IGRA #DodgerBlue -The InstructingReimbursementAgent confirms to the DebtorAgent -that the funds have been credited through a status message to -indicate a successful payment. -end note -IGRA [#Blue]-> DA: FIToFIPaymentStatusReport (Accepted) -end - -IGRA [#Blue]-> IDRA: FinancialInstitutionCreditTransfer (COVER) -activate IDRA #Blue -Hnote over IDRA #DodgerBlue -The InstructedReimbursementAgent credits the amount of money -on the account of the CreditorAgent, which completes the transfer -of funds from the DebtorAgent to the CreditorAgent as initially -instructed in the Payment Clearing phase. -end note - - -opt -Hnote over IDRA #DodgerBlue -The InstructedReimbursementAgent confirms to the DebtorAgent -that the funds have been credited through a status message to -indicate a successful payment. -end note -IDRA [#Blue]-> IGRA: FIToFIPaymentStatusReport (Accepted) -end -IDRA [#Blue]-> CA: BankToCustomerDebitCreditNotification (Booked/Credit) -deactivate IGRA #Blue -deactivate IDRA #Blue - -activate CA #Blue -||| -== Payment Confirmation == -opt -Hnote over IGRA -The CreditorAgent books the funds on the Creditor's account and -confirms to the DebtorAgent that the funds have been credited -through a status message to indicate a successfull payment. -end note -CA -> DA: FIToFIPaymentStatusReport (Accepted) -end -deactivate CA #Blue - -||| -== Payment Notification == -Hnote over CDTR -The CreditorAgent informs the Creditor that the funds -have been credited on the Creditor's account. -end note -CA -> CDTR: BankToCustomerDebitCreditNotification (Booked/Credit) -deactivate CA -deactivate DA -||| -@enduml diff --git a/PaymentFlows/DirectDebit/SDD-One-Off-e-Mandate.pml b/PaymentFlows/DirectDebit/SDD-One-Off-e-Mandate.pml deleted file mode 100644 index 1c36dbd..0000000 --- a/PaymentFlows/DirectDebit/SDD-One-Off-e-Mandate.pml +++ /dev/null @@ -1,177 +0,0 @@ -@startuml -!includeurl https://raw.githubusercontent.com/w3c/webpayments/gh-pages/PaymentFlows/skin.ipml - -title SEPA Direct Debit with e-mandate\n Nominal B2C one-off case\nRef: EPC016-06 Core SDD RB v9.1 Approved - -participant CB as "Payee (Merchant) Bank [Creditor Agent]" -participant RSP as “ Payee (Merchant)\nRouting Service\nProvider” - -participant CSM as “Clearing & Settlement\nMechanism” -participant WOC as "Payee (Merchant) Website [Creditor]" - -Actor BOD as "Payer (Shopper) Browser [Debtor]" -participant VSP as “ Payer (Shopper)\nValidation Service\nProvider” -participant DB as "Payer (Shopper) Bank [Debtor Agent]" - -WOC -> BOD: Present Checkout Page with Pay Button -BOD -> WOC: Select Direct Debit Payment Method -Autonumber stop - -group ISO20022/SEPA Direct Debit - -== e-Mandate processing == - -Autonumber -‘1 initiation -BOD -> WOC: Initiation\nCreditor’s website proposes a form\n to collect the Debtor’s information(esp. BIC\n Possibility to prefill Debtor’s information if already known -Activate BOD -Activate WOC - -Hnote over BOD : Initiation \nCustomer fills the form of the\n e-Mandate required data - -‘2 mandate request -hnote over WOC : Creditor’s website generates\n e-Mandate request\n (BIC and Creditor’s website URL mandatory) -WOC-[#green]>RSP : e-Mandate request submitted to\n Routing service using URL and\ncredentials (provided by Creditor’s bank or Routing service Provider)\n eom-msg-cred-to-rs-001 -activate RSP - -‘3 mandate request, BIC and Validation service URL -hnote over RSP : RS requests the Directory Service -RSP-[#green]>RSP: resolve VS BIC -hnote over RSP : Directory Service returns\nthe Validation Service URL for the BIC - -‘4 mandate request -hnote over RSP :The Routing Service must present a client certificate\n issued by an EPC approved CA qualifying it\n as legitimate Routing Service\n and the Validation Service must present a server certificate\n issued by an EPC approved CA qualifying it as a legitimate Validation Service - -RSP-[#green]>VSP : e-Mandate request\n(e-mandate enrolment request)\n eom-msg-rs-to-vs-001 -activate VSP - -‘5 mandate request,validation e-mandate proposal -hnote over VSP : VS validates the e-Mandate proposal -VSP -[#green]> VSP : Validates and stores - -‘6 mandate request -VSP -[#green]> RSP : Validation service response\n eom-msg-vs-to-rs-001 -Deactivate VSP - -‘7 mandate request -RSP-[#green]>WOC : Response including URL specific to\n this transaction used later\n to redirect the Debtor’s browser\n eom-msg-rs-to-cred-001 -Deactivate RSP - -‘8 mandate request -WOC-[#green]>BOD: Redirect VS URL -Deactivate WOC - -‘9 mandate request -BOD-[#green]>VSP: goto VS URL -hnote over BOD : Debtor redirected to an authentication screen\n provided by the Validation Service -activate VSP - -’10 Request authentication means -VSP-[#green]>BOD : Authentication form -Deactivate VSP - - -‘11 Request authentication means -Hnote over DB : The Debtor Bank defines\n and provides the\nauthentication means \n(credentials)\n to be used by\nthe Debtors -hnote over BOD : The Debtor must identify\nand authenticate (Authentication credentials) himself\naccording to the instructions received\nfrom the Debtor Bank. - -hnote over BOD : Debtor enters his authentication credentials - -BOD-[#green]>VSP: Authentication Data -activate VSP - -‘12 Request authentication means -hnote over VSP : Validation Service verifies the credentials -VSP-[#green]>VSP - - -‘13 Request authentication means -hnote over VSP : If check successful, validation of\n the authentication means and the\n account access right\n collects the debtor’s IBAN (if unsuccessfull, abort) - -VSP-[#green]>BOD : Displays to the Debtor an authorization form that must \ninclude all data fields of the e-Mandate and advances \nthe transaction state to “Waiting for authorization” -Deactivate VSP - -’14 Authorisation -Hnote over BOD : Debtor checks data and authorizes\n The authorization is defined here as the set of procedures\n agreed between the Debtor and the Debtor Bank \nto assure the clear consent of the Debtor for the\n issuing, amendment and cancellation of an e-Mandate. - -BOD-[#green]>VSP : Authorization data -activate VSP - - -‘15 Authorisation -Hnote over VSP : Validation Service verifies the authorization\n and performs an electronic signature\n of the XML e-Mandate data using the\n e-Operating Model X.509 signing certificate issued\n by an approved EPC Certification Authority. -VSP-[#green]>VSP : e-sign mandate - -’16 Confirmation1 -hnote over VSP : e-Mandate: electronic document\n created and signed in a\nsecure electronic manner -VSP-[#green]>BOD : confirmation message along with the e-Mandate\n data and a link to the Creditor website. -deactivate VSP - -‘17 Confirmation1 -hnote over BOD : Debtor follows the link to the Creditor’s website -BOD-[#green]>WOC: goto Creditor URL -activate WOC - - -‘18 Confirmation1 -hnote over WOC : Generates a request with e-Mandate request identifier\n to retrieve the issued e-Mandate\n eom-msg-cred-to-rs-002 - -WOC-[#green]>RSP : e-Mandate\n Creditor must present credentials\npreviously arranged with RS\n eom-msg-cred-to-rs-002 -Activate RSP - -‘19 Confirmation1 -RSP-[#green]>VSP : e-Mandate\n eom-msg-rs-to-vs-002 -Activate VSP - -’20 e-Mandate -VSP-[#green]>RSP : e-Mandate (signed enveloped message)\n eom-msg-vs-to-rs-002 -Deactivate VSP - -‘21 e-Mandate -RSP-[#green]>RSP: validates signature - -‘22 e-Mandate -RSP-[#green]>WOC : e-mandate\n eom-msg-rs-to-cred-002 -Deactivate RSP - - -‘23 e-Mandate -WOC-[#green]> RSP: Acknowledgement of the e-mandate\n eom-msg-cred-to-rs-002 -Activate RSP - -’24 Confirmation -Hnote over WOC: Presents a confirmation message with e-mandate data -WOC-[#green]>BOD : Confirmation -Deactivate WOC -deactivate BOD - -’25 Ack -RSP-[#green]>VSP : Acknowledgement of the e-mandate \ eom-msg-rs-to-vs-002 -Deactivate RSP -deactivate VSP - -== Collection == -Autonumber 20 -ME-[#green]> CB : Merchant sends "Collection"\nnot earlier than 14 Calendar Days before the Due Date,\nunless otherwise agreed between the Creditor and the Creditor Bank\nCollection includes Mandate-related information -deactivate ME -activate CB -Create CSM -CB-[#green]> CSM : Collection -Deactivate CB -activate CSM -CSM-[#green]> DB : Collection -deactivate CSM - -end -... 14 days or other agreed delay ... -== Settlement at due date == -hnote over CSM : Settlement -CSM-> DB : Debit -activate CSM -deactivate DB -hnote over DB : Debtor account debited -CSM-> CB : Credit -deactivate CSM -deactivate CB -hnote over CB : Creditor account credited -@enduml diff --git a/PaymentFlows/Escrow/CustomerProtect.pml b/PaymentFlows/Escrow/CustomerProtect.pml deleted file mode 100644 index 17e4ade..0000000 --- a/PaymentFlows/Escrow/CustomerProtect.pml +++ /dev/null @@ -1,23 +0,0 @@ -@startuml -!includeurl https://raw.githubusercontent.com/w3c/webpayments/gh-pages/PaymentFlows/skin.ipml - -title Escrow Payment (customer protection) - -participant "User Agent" as UA -participant Merchant as M -participant PSP as P - -UA->M: checkout -M->UA: payment form -UA->P : select escrow -P<->UA: process payment -P->UA: payment finished -UA->M: payment finished -opt direct notification -P->M: payment finished -end -M->UA: provide service/goods -M->P: delivery finished -P<->UA: confirm delivered -P->M: release settlement -@enduml diff --git a/PaymentFlows/ILP/Interledger-UniversalMode.pml b/PaymentFlows/ILP/Interledger-UniversalMode.pml deleted file mode 100644 index 4745e96..0000000 --- a/PaymentFlows/ILP/Interledger-UniversalMode.pml +++ /dev/null @@ -1,96 +0,0 @@ -@startuml -!includeurl https://raw.githubusercontent.com/w3c/webpayments/gh-pages/PaymentFlows/skin.ipml - -Participant "Payee Website" as Website -Participant "Payee PSP" as PayeePSP -Participant "Cn" as ConnectorN <> -Participant "Ln-1" as LedgerN1 <> -Participant "Cn-1" as ConnectorN1 <> -Participant "Ln-2" as LedgerN2 <> -Participant "C3" as Connector3 <> -Participant "L2" as Ledger2 <> -Participant "C2" as Connector2 <> -Participant "L1" as Ledger1 <> -Participant "C1" as Connector1 <> -Participant "Payer PSP" as PayerPSP -Actor "Payer (Browser)" as Payer - -title Interledger Protocol - -Payer->Website: Request checkout via ILP -Website->Payer: Destination account, required amount, currency -Payer->PayerPSP: Get quote -note over PayerPSP: Perform pathfinding -PayerPSP->Payer: Proposed path and cost -Payer->PayerPSP: Confirm payment -== Proposal == -PayerPSP->Connector1: Propose -activate Connector1 -PayerPSP->Connector2: Propose -activate Connector2 -PayerPSP->Connector3: Propose -activate Connector3 -PayerPSP->ConnectorN1: Propose -activate ConnectorN1 -PayerPSP->ConnectorN: Propose -activate ConnectorN -Connector1->PayerPSP: Accepted -deactivate Connector1 -Connector2->PayerPSP: Accepted -deactivate Connector2 -Connector3->PayerPSP: Accepted -deactivate Connector3 -ConnectorN1->PayerPSP: Accepted -deactivate ConnectorN1 -ConnectorN->PayerPSP: Accepted -deactivate ConnectorN -== Preparation == -activate PayerPSP -PayerPSP->Connector1: Prepared -activate Connector1 -Connector1->Ledger1: Prepared -activate Ledger1 -Ledger1->Connector2: Prepared -activate Connector2 -Connector2->Ledger2: Prepared -activate Ledger2 -Ledger2->Connector3: Prepared -activate Connector3 -Connector3->LedgerN2: Prepared -activate LedgerN2 -LedgerN2->ConnectorN1: Prepared -activate ConnectorN1 -ConnectorN1->LedgerN1: Prepared -activate LedgerN1 -LedgerN1->ConnectorN: Prepared -activate ConnectorN -ConnectorN->PayeePSP: Prepared -activate PayeePSP -PayeePSP->Website: Payment Prepared -Website->PayeePSP: Execute Payment -== Execution == -PayeePSP->Website: Payment Executed -PayeePSP->ConnectorN: Execute -deactivate PayeePSP -ConnectorN->LedgerN1: Execute -deactivate ConnectorN -LedgerN1->ConnectorN1: Execute -deactivate LedgerN1 -ConnectorN1->LedgerN2: Execute -deactivate ConnectorN1 -LedgerN2->Connector3: Execute -deactivate LedgerN2 -Connector3->Ledger2: Execute -deactivate Connector3 -Ledger2->Connector2: Execute -deactivate Ledger2 -Connector2->Ledger1: Execute -deactivate Connector2 -Ledger1->Connector1: Execute -deactivate Ledger1 -Connector1->PayerPSP: Execute -deactivate Connector1 -PayerPSP->Payer: Payment confirmation -deactivate PayerPSP - -@enduml \ No newline at end of file diff --git a/PaymentFlows/PayPal/MerchantPSPIntermediated-PayPal-Current.pml b/PaymentFlows/PayPal/MerchantPSPIntermediated-PayPal-Current.pml deleted file mode 100644 index 10c3d22..0000000 --- a/PaymentFlows/PayPal/MerchantPSPIntermediated-PayPal-Current.pml +++ /dev/null @@ -1,80 +0,0 @@ -@startuml -!includeurl https://raw.githubusercontent.com/w3c/webpayments/gh-pages/PaymentFlows/skin.ipml - -Participant "Payee (Merchant) PSP" as MPSP -Participant "Payee (Merchant) Site" as Payee -Actor "Payer (Shopper) Browser" as Payer -participant "Payer (Shopper) PSP (PayPal)" as CPSP - -note over MPSP, CPSP: HTTPS - -title Merchant PSP Intermediated PayPal Payment (REST API) (Current) - -Payee->Payer: Present Checkout Page with Pay Button - -Payer->Payer: Select PayPal Payment Method - -Payer-\Payee: Payment Page Request - -Payee-\MPSP: Payment Page Request - -MPSP<->CPSP: Create Payment - -MPSP-/Payee: HTTP Redirect information - -Note right: This data is information about the page to redirect to - -Payee-/Payer: HTTP Redirect - -Note right: The merchant site converts the info to a HTTP 301 to give the Merchant PSP control - -Payer-\MPSP: Payment Request - -MPSP-/Payer: HTTP Redirect - -Note right: HTTP Direct now send the shopper to the PayPal site - -Payer-\CPSP: Payment Initiation - -CPSP-/Payer: Authentication Page - -Payer-\CPSP: Authenticate -note right: Typically a username & password - -CPSP-/Payer: Payment Page - -opt - Payer<->CPSP: Instrument Choice - note right: Payer can change from default payment instrument -end - -Payer->Payer: Approval - -Payer-\CPSP: Payment Approval - -CPSP-/Payer: Payment Response Redirect - -Payer-\MPSP: Payment Response - -MPSP<->CPSP: Execute Payment - -MPSP-/Payer: Result Page Redirect - -Payer<->Payee: Get Result Page - - -... asynchronous notification ... -Opt - CPSP->Payer: Payment Notification (email) -End - -MPSP->Payee: Payment Notification - -Opt - Payee->Payer: Payment Notification (email) -End - -Note right: Provides out of band confirmation to protect against failure/modification at browser - - -@enduml diff --git a/PaymentFlows/PayPal/PayPal-Current.pml b/PaymentFlows/PayPal/PayPal-Current.pml deleted file mode 100644 index 55fe956..0000000 --- a/PaymentFlows/PayPal/PayPal-Current.pml +++ /dev/null @@ -1,62 +0,0 @@ -@startuml -!includeurl https://raw.githubusercontent.com/w3c/webpayments/gh-pages/PaymentFlows/skin.ipml - -Participant "Payee (Merchant) Site" as Payee -Actor "Payer (Shopper) Browser" as Payer -participant "Payer (Shopper) PSP (PayPal)" as CPSP - -note over MPSP, CPSP: HTTPS - -title PayPal Payment (REST API) (Current) - -Payee->Payer: Present Checkout Page with Pay Button - -Payer->Payer: Select PayPal Payment Method - -Payer-\Payee: Payment Page Request - -Payee<->CPSP: Create Payment - -Payee-/Payer: HTTP Redirect - -Note right: HTTP Direct now send the shopper to the PayPal site - -Payer-\CPSP: Payment Initiation - -CPSP-/Payer: Authentication Page - -Payer-\CPSP: Authenticate -note right: Typically a username & password - -CPSP-/Payer: Payment Page - -opt - Payer<->CPSP: Instrument Choice - note right: Payer can change from default payment instrument -end - -Payer->Payer: Approval - -Payer-\CPSP: Payment Approval - -CPSP-/Payer: Payment Response Redirect - -Payer-\Payee: Payment Response - -Payee<->CPSP: Execute Payment - -Payee-/Payer: Result Page - - -... asynchronous notification ... - -CPSP->Payer: Payment Notification (email) - -Opt - Payee->Payer: Payment Notification (email) -End - -Note right: Provides out of band confirmation to protect against failure/modification at browser - - -@enduml diff --git a/PaymentFlows/RealTime/RealTimePayments.pml b/PaymentFlows/RealTime/RealTimePayments.pml deleted file mode 100644 index ccde849..0000000 --- a/PaymentFlows/RealTime/RealTimePayments.pml +++ /dev/null @@ -1,77 +0,0 @@ -@startuml -!includeurl https://raw.githubusercontent.com/w3c/webpayments/gh-pages/PaymentFlows/skin.ipml - -title Real Time Payments Service flows\nBased on a distributed architecture service\nSingle currency settlement - -participant Debtor -participant DebtorAgent -participant RealTimeSettlementService -participant CreditorAgent -participant Creditor - -== Initiation of Payment Obligation == -Hnote over RealTimeSettlementService -The Debtor and the Creditor have entered into an agreement (or obligation, such as a web purchase, a commercial contract, a securities deal, .....) -which bounds the Debtor to pay the Creditor an agreed amount of money through a credit transfer, executed through a distributed real time payment service. -end note -Debtor <---> Creditor: Establish Payment Obligation - -== Payment Initiation == -Hnote over Debtor -The Debtor initiates a payment from its bank - the DebtorAgent -end note -Debtor -> DebtorAgent: CustomerCreditTransferInitiation -activate DebtorAgent -||| -== Payment Clearing == -Hnote over RealTimeSettlementService -The DebtorAgent instructs the payment to the beneficiary (the Creditor) -through a credit transfer to the CreditorAgent. -The CreditorAgent will receive the amount of money through the real time -payment settlement service. -end note -DebtorAgent -> CreditorAgent: FIToFICustomerCreditTransfer -activate CreditorAgent -||| -== Payment Settlement == - -Hnote over RealTimeSettlementService #DodgerBlue -Both DebtorAgent and CreditorAgent are participants in the real time payments settlement -service and they have both an account in the system. The DebtorAgent issues an interbank -credit transfer to the real time settlement service instructing to move the amount of money -(the funds) from its own account to the account of the CreditorAgent. -end note - -DebtorAgent [#Blue]-> RealTimeSettlementService: FinancialInstitutionCreditTransfer -activate DebtorAgent #Blue -activate RealTimeSettlementService #Blue -Hnote over RealTimeSettlementService #DodgerBlue -Once the movement of the amount of money is confirmed, -the realtime payments settlement service sends a status message -to indicate the transfer was accepted to both DebtorAgent and CreditorAgent. -end note -RealTimeSettlementService [#Blue]-> DebtorAgent: FIToFIPaymentStatusReport (Accepted) -RealTimeSettlementService [#Blue]-> CreditorAgent: FIToFIPaymentStatusReport (Accepted) -deactivate RealTimeSettlementService #Blue -activate CreditorAgent #Blue -||| -== Payment Confirmation == -Hnote over RealTimeSettlementService #DodgerBlue -The CreditorAgent books the funds on the Creditor's account and confirms to -the DebtorAgent that the funds have been credited through a status message -to indicate a successfull payment. -end note -CreditorAgent -> DebtorAgent: FIToFIPaymentStatusReport (Accepted) -deactivate CreditorAgent #Blue -deactivate DebtorAgent -deactivate DebtorAgent #Blue -||| -== Payment Notification == -Hnote over Creditor -The CreditorAgent informs the Creditor that the funds -have been credited on the Creditor's account. -end note -CreditorAgent -> Creditor: BankToCustomerDebitCreditNotification (Booked/Credit) -deactivate CreditorAgent -||| -@enduml \ No newline at end of file diff --git a/PaymentFlows/SamsungPay/SamsungPayInit.pml b/PaymentFlows/SamsungPay/SamsungPayInit.pml deleted file mode 100644 index 23cd010..0000000 --- a/PaymentFlows/SamsungPay/SamsungPayInit.pml +++ /dev/null @@ -1,51 +0,0 @@ -@startuml -!includeurl https://raw.githubusercontent.com/w3c/webpayments/gh-pages/PaymentFlows/skin.ipml - -participant User -participant "SamsungPay App" as SPA -participant "SamsungPay Server" as SPS -participant "Token Service Provider" as CI -participant "Card Issuer (Bank)" as B - -title SamsungPay Initialization Process (unofficial) - -opt User Registration -User<->SPA: launch SamsungPay App -SPA<->SPS: login with SamsungPay Account -end -opt Adding Card -User<->SPA: launch SamsungPay App -opt OCR read via Camera -SPA->SPA: OCR read credit card via Camera -end -SPA->SPA: key-in/confirm Card Info -SPA->SPA: set user's fingerprint -SPA->SPS: send credit card info as encrypted -SPS->SPS: decrypt card info -SPS->CI: send credit card info as re-encrypted - -CI<->B: Tokenization Auth Request - - -CI->CI: generate token -CI->SPS: send token -SPS->SPA: send token -SPA->SPA: store card token into trust zone \nof Knox Sandbox\n (can be active or inactive) - -opt auth user (e.g. via OTP) -CI->CI: generate activation code -CI->B: activ code -B->User: send token activation code -User->SPA: input code -SPA->SPS: -SPS->CI: -CI->CI: validate activation code -end - -CI->CI: activate token -CI->SPS: notify token status change -SPS->SPA: notify token status change - -end - -@enduml diff --git a/PaymentFlows/SamsungPay/SamsungPayUse.pml b/PaymentFlows/SamsungPay/SamsungPayUse.pml deleted file mode 100644 index bf1eda0..0000000 --- a/PaymentFlows/SamsungPay/SamsungPayUse.pml +++ /dev/null @@ -1,27 +0,0 @@ -@startuml -!includeurl https://raw.githubusercontent.com/w3c/webpayments/gh-pages/PaymentFlows/skin.ipml - -title Using SamsungPay (unofficial) - -participant User as U -participant "SamsungPay App" as SPA -participant "SamsungPay Server" as SPS -participant "Store / POS" as S -participant "Card Issuer" as CI - -U->S: choose goods -S->U: show bill -U->SPA: launch SamsungPay App -SPA->SPA: select cardtype -SPA->SPA: user authentication \nwith fingerprint -SPA->SPA: generate One Time Token ("Cryptogram") \n(either with static or dynamic Token, \nand time-based seed) -SPA->S: send OTT via MST or NFC -SPA<->SPS: store payment history -S<->CI: get card approval with OTT -S->U: show payment result -opt -U->S: sign on receipt -end -S->U: deliver goods - -@enduml diff --git a/PaymentFlows/Taler/taler-pay.pml b/PaymentFlows/Taler/taler-pay.pml deleted file mode 100644 index 09b3195..0000000 --- a/PaymentFlows/Taler/taler-pay.pml +++ /dev/null @@ -1,39 +0,0 @@ -@startuml -!includeurl https://raw.githubusercontent.com/w3c/webpayments/gh-pages/PaymentFlows/skin.ipml - -Actor "Payer (Shopper) Browser" as Payer -Participant "Payee (Merchant) Site" as Payee -Participant "Taler Exchange" as Exchange - -note over Payer, Payee: Tor/HTTPS -note over Payee, Exchange: HTTP/HTTPS - -title Taler (Payment) - -== Establish Payment Obligation == - -opt -Payer->Payer: Select Taler payment method (skippable with auto-detection) -end - -Payer->Payee: Choose goods - -Payee->Payer: Send signed digital contract proposal - -== Execute Payment == - -opt -Payer->Payer: Affirm contract -end - -Payer->Payee: Send payment - -Payee->Exchange: Forward payment - -Exchange->Payee: Confirm payment - -== Fulfilment == - -Payee->Payer: Provide products or services - -@enduml diff --git a/PaymentFlows/Taler/taler-withdraw.pml b/PaymentFlows/Taler/taler-withdraw.pml deleted file mode 100644 index fa06406..0000000 --- a/PaymentFlows/Taler/taler-withdraw.pml +++ /dev/null @@ -1,33 +0,0 @@ -@startuml -!includeurl https://raw.githubusercontent.com/w3c/webpayments/gh-pages/PaymentFlows/skin.ipml - -Actor "Customer Browser" as Customer -Participant "Bank Site" as Bank -Participant "Taler Exchange" as Exchange - -note over Customer, Bank: HTTPS -note over Customer, Exchange: HTTPS -note over Bank, Exchange: SEPA - -title Taler (Withdraw coins) - -Customer->Bank: user authentication -Bank->Customer: send account portal - -Customer->Customer: initiate withdrawal (specify amount and exchange) - -Customer->Exchange: request key material and wire transfer data -Exchange->Customer: send key material and wire transfer data - -Customer->Bank: execute withdrawal - -opt -Bank->Customer: request transaction authorization -Customer->Bank: transaction authorization -end - -Bank->Customer: withdrawal confirmation -Bank->Exchange: execute wire transfer - - -@enduml diff --git a/PaymentFlows/skin.ipml b/PaymentFlows/skin.ipml deleted file mode 100644 index f7e1ed2..0000000 --- a/PaymentFlows/skin.ipml +++ /dev/null @@ -1,11 +0,0 @@ -Autonumber - -skinparam { -backgroundColor transparent -defaultFontName Lucida Sans -shadowing false -} -skinparam sequence { -DividerBackgroundColor transparent -LifeLineBackgroundColor transparent -} diff --git a/TargetFlows/Card/MerchantHosted-CardPayment-TargetWithComplexApp.pml b/TargetFlows/Card/MerchantHosted-CardPayment-TargetWithComplexApp.pml deleted file mode 100644 index 7e120d3..0000000 --- a/TargetFlows/Card/MerchantHosted-CardPayment-TargetWithComplexApp.pml +++ /dev/null @@ -1,91 +0,0 @@ -@startuml -!includeurl https://raw.githubusercontent.com/w3c/webpayments/gh-pages/PaymentFlows/skin.ipml - -Participant "Payee (Merchant) PSP [Acquirer]" as MPSP -Participant "Payee (Merchant) [Acceptor] Website" as Payee -participant "Payer's (Shopper's) Browser" as UA -Actor "Payer [Cardholder]" as Payer - -participant "Payment Mediator" as UAM -participant "Payment App" as PSPUI - -participant "Issuing Bank [Issuer]" as CPSP - -note over Payee, PSPUI: HTTPS - -title Legacy Merchant Hosted Card Payment (Target) - -== Negotiation of Payment Terms & Selection of Payment Instrument == - -Payee->UA: Present Check-out page -Payer<-[#green]>UA: Select Checkout -Payer<-[#green]>Payee: Establish Payment Obligation (including delivery obligations) -Payee->UA: Payment and delivery details - -UA->UAM: PaymentRequest (Items, Amounts, Shipping Options ) -note right: PaymentRequest.Show() -opt - Payer<-[#green]>UAM: Select Shipping Options - UAM->UA: Shipping Info - note right: shippingoptionchange or shippingaddresschange events - - UA->UAM: Revised PaymentRequest -end -Payer<-[#green]>UAM: Select Card Payment Instrument - -Payer<-[#green]>UAM: Authorise - -UAM<-[#green]>PSPUI: Invoke Card Payment App (Instrument) - -UAM->PSPUI: PaymentRequest without Shipping Options - - - PSPUI<->CPSP: Authorisation - - PSPUI<->UAM: Payment Token - -UAM->UA: Payment Token - -Note Right: Show() Promise Resolves - - -== Payment Processing == - - UA->Payee: Payment Token - -opt - Payee->Payee: Store Token - note right: Merchant can store card details if it is a reusable token however PaymentRequest message will need to support this -end - - Payee-> UA: Token Stored Successfully - -== Notification == - -UA->UAM: Payment Completetion Status - -note over UAM: response.complete(status) - -UAM->UA: UI Removed - -note over UAM: complete promise resolves - -UA->UA: Navigate to Result Page - -== Payment Processing Continued: 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 - -== Delivery of Product == - -Payee->Payer: Provide products or services - - -@enduml diff --git a/TargetFlows/Card/MerchantHosted-CardPayment-TargetWithSimpleApp.pml b/TargetFlows/Card/MerchantHosted-CardPayment-TargetWithSimpleApp.pml deleted file mode 100644 index d51def3..0000000 --- a/TargetFlows/Card/MerchantHosted-CardPayment-TargetWithSimpleApp.pml +++ /dev/null @@ -1,101 +0,0 @@ -@startuml -!includeurl https://raw.githubusercontent.com/w3c/webpayments/gh-pages/PaymentFlows/skin.ipml - -Participant "Payee (Merchant) PSP [Acquirer]" as MPSP -Participant "Payee (Merchant) [Acceptor] Website" as Payee -participant "Payer's (Shopper's) Browser" as UA -Actor "Payer [Cardholder]" as Payer - -participant "Payment Mediator" as UAM -participant "Payment App" as PSPUI - -participant "Issuing Bank [Issuer]" as CPSP - -note over Payee, PSPUI: HTTPS - -title Legacy Merchant Hosted Card Payment (Target) - -== Negotiation of Payment Terms & Selection of Payment Instrument == - -Payee->UA: Present Check-out page -Payer<-[#green]>UA: Select Checkout -Payer<-[#green]>Payee: Establish Payment Obligation (including delivery obligations) -Payee->UA: Payment and delivery details - -UA->UAM: PaymentRequest (Items, Amounts, Shipping Options ) -note right: PaymentRequest.Show() -opt - Payer<-[#green]>UAM: Select Shipping Options - UAM->UA: Shipping Info - note right: shippingoptionchange or shippingaddresschange events - - UA->UAM: Revised PaymentRequest -end -Payer<-[#green]>UAM: Select Card Payment Instrument - -Payer<-[#green]>UAM: Authorise - -UAM<-[#green]>PSPUI: Invoke Card Payment App (Instrument) - -UAM->PSPUI: PaymentRequest without Shipping Options - -PSPUI->UAM: Card Details (e.g. PAN, Expiry, CVV) - - -UAM->UA: Card Details (e.g. PAN, Expiry, CVV) - -Note Right: Show() Promise Resolves - - -== Payment Processing == - -note over UA: Payment Processing is unchanged from Pre-WebPayment - -Alt - UA->Payee: payload -Else - UA->Payee: Encrypt(payload) - Note right: Custom code on merchant webpage can encrypt payload to reduce PCI burden from SAQ D to SAQ A-EP -End - -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 (payload) - -MPSP-\CPSP: Authorisation Request -CPSP-/MPSP: Authorisation Response - -MPSP-/Payee: Authorisation Result - -== Notification == - -UA->UAM: Payment Completetion Status - -note over UAM: response.complete(status) - -UAM->UA: UI Removed - -note over UAM: complete promise resolves - -UA->UA: Navigate to Result Page - -== Payment Processing Continued: 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 - -== Delivery of Product == - -Payee->Payer: Provide products or services - - -@enduml diff --git a/TargetFlows/Card/TPAC2015 Flows/MerchantHosted-CardPayment-CGProposal.pml b/TargetFlows/Card/TPAC2015 Flows/MerchantHosted-CardPayment-CGProposal.pml deleted file mode 100644 index 3da5aef..0000000 --- a/TargetFlows/Card/TPAC2015 Flows/MerchantHosted-CardPayment-CGProposal.pml +++ /dev/null @@ -1,30 +0,0 @@ -@startuml -Autonumber - -Participant "Payee (Merchant) PSP" as MPSP -Participant "Payee (Merchant) Site" as Payee -Actor "Payer (Shopper) Browser" as Payer -Participant "Browser Payment Agent/Wallet" as UA -Participant "Payer (Shopper) PSP Wallet [aka Issuer Wallet]" as CPSP - -note over Payee, Payer: HTTPS - -title Legacy Merchant Hosted Card Payment (CG Proposal) - -Payee->Payer: Basket Page with Pay Button -Payer->Payer: Press Pay -Payer->UA: Select Payment Instrument - -UA-\MPSP: Authorise -Note right - Auth goes direct from Browser to Payee's nominated PSP (see - https://web-payments.org/specs/source/web-payments-api/#payment-flow-overview - 6.1) -End note - -MPSP-/UA: Authorisation Response - -UA->Payee: Authorisation Response -Payee->Payer: Result Page - -@enduml diff --git a/TargetFlows/Card/TPAC2015 Flows/MerchantHosted-CardPayment-GoogleProposal.pml b/TargetFlows/Card/TPAC2015 Flows/MerchantHosted-CardPayment-GoogleProposal.pml deleted file mode 100644 index 9f83247..0000000 --- a/TargetFlows/Card/TPAC2015 Flows/MerchantHosted-CardPayment-GoogleProposal.pml +++ /dev/null @@ -1,42 +0,0 @@ -@startuml -autonumber -Participant "Payee (Merchant) PSP" as MPSP -Participant "Payee (Merchant) Site" as Payee -Actor "Payer (Shopper) Browser" as Payer -participant "Browser Payment Agent/Wallet" as UA -participant "Payer (Shopper) PSP Wallet [aka Issuer Wallet]" as CPSP -participant "Issuer Website" as CPSPW - - -note over Payee, Payer: HTTPS - -title Legacy Merchant Hosted Card Payment (Google Proposal) - -Payee->Payer: Basket Page with Pay Button -Payer->Payer: Press Pay - -Payer->UA: Select Payment Instrument - -Opt - CPSP->UA: Payment Instrument data - Note left - If 3rd Party provides extension, - e.g. LastPass, MasterPass, Barclaycard - End note -End - -UA->Payer: Payment Instrument data - -Alt - Payer->Payee: Payment Instrument Data -Else - Payer->Payee: Encrypt(Payment Instrument Data) - Note right: Custom code on merchant webpage can encrypt payload -End - -Payee-\MPSP: Authorise(Payment Instrument data) -MPSP-/Payee: Authorisation Result - -Payee->Payer: Result Page - -@enduml diff --git a/TargetFlows/Card/TPAC2015 Flows/MerchantHosted-CardPaymentwith3DS-CGProposal.pml b/TargetFlows/Card/TPAC2015 Flows/MerchantHosted-CardPaymentwith3DS-CGProposal.pml deleted file mode 100644 index f154756..0000000 --- a/TargetFlows/Card/TPAC2015 Flows/MerchantHosted-CardPaymentwith3DS-CGProposal.pml +++ /dev/null @@ -1,41 +0,0 @@ -@startuml -Autonumber - -Participant "Payee (Merchant) PSP" as MPSP -Participant "Payee (Merchant) Site" as Payee -Actor "Payer (Shopper) Browser" as Payer -Participant "Browser Payment Agent" as UA -Participant "Payer (Shopper) PSP Wallet [aka Issuer Wallet]" as CPSP -Participant "Issuer Website" as CPSPW - -note over Payee, Payer: HTTPS - -title Legacy Merchant Hosted Card Payment (CG Proposal) - -Payee->Payer: Basket Page with Pay Button -Payer->Payer: Press Pay -Payer->UA: Select Payment Instrument - -UA-\MPSP: Auth -Note right - Auth goes direct from Browser to Payee's nominated PSP (see - https://web-payments.org/specs/source/web-payments-api/#payment-flow-overview - 6.1) -End note - -Opt - MPSP-/Payee: 3DS invoke - Payee->CPSPW: 3DS invoke - CPSPW-\Payer: 3DS challenge - Payer-/CPSPW: 3DS response - CPSPW->Payee: 3DS response - Payee-\MPSP: Authentication(3DS token) -End - - -MPSP-/UA: Auth Response - -UA->Payee: Auth Response -Payee->Payer: Result Page - -@enduml diff --git a/TargetFlows/Card/TPAC2015 Flows/MerchantHosted-CardPaymentwith3DS-GoogleProposal.pml b/TargetFlows/Card/TPAC2015 Flows/MerchantHosted-CardPaymentwith3DS-GoogleProposal.pml deleted file mode 100644 index b3cadc7..0000000 --- a/TargetFlows/Card/TPAC2015 Flows/MerchantHosted-CardPaymentwith3DS-GoogleProposal.pml +++ /dev/null @@ -1,54 +0,0 @@ -@startuml -autonumber -Participant "Payee (Merchant) PSP" as MPSP -Participant "Payee (Merchant) Site" as Payee -Actor "Payer (Shopper) Browser" as Payer -participant "Browser Payment Agent/Wallet" as UA -participant "Payer (Shopper) PSP Wallet [aka Issuer Wallet]" as CPSP -participant "Issuer Website" as CPSPW - - -note over Payee, Payer: HTTPS - -title Legacy Merchant Hosted Card Payment with 3DS (Google Proposal) - -Payee->Payer: Basket Page with Pay Button -Payer->Payer: Press Pay -Payer->UA: Select Payment Instrument - -Opt - CPSP->UA: Payment Instrument data - Note left - If 3rd Party provides extension, - e.g. LastPass, MasterPass, Barclaycard - End note -End - -UA->Payer: Payment Instrument data - -Alt - Payer->Payee: Payment Instrument Data -Else - Payer->Payee: Encrypt(Payment Instrument Data) - Note right: Custom code on merchant webpage can encrypt payload -End - -Payee-\MPSP: Authorise(Payment Instrument data) - -Opt - MPSP-/Payee: 3DS redirect - Payee->Payer: 3DS redirect - Payer->CPSPW: 3DS invoke - CPSPW-\Payer: 3DS challenge - Payer-/CPSPW: 3DS response - CPSPW->Payer: 3DS response - Payer->Payee: 3DS response - Payee-\MPSP: Authentication(3DS token) -End - - -MPSP-/Payee: Authorisation Result - -Payee->Payer: Result Page - -@enduml diff --git a/TargetFlows/PaymentRequestAPI.pml b/TargetFlows/PaymentRequestAPI.pml deleted file mode 100644 index bb18541..0000000 --- a/TargetFlows/PaymentRequestAPI.pml +++ /dev/null @@ -1,92 +0,0 @@ -@startuml -!includeurl https://raw.githubusercontent.com/w3c/webpayments/gh-pages/PaymentFlows/skin.ipml - -participant "Payment Processor" as MPSP -Participant "Payee (Merchant) Website" as Payee -participant "Payer's (Shopper's) Browser" as UA -Actor "Payer" as Payer -participant "Payment Mediator" as UAM -participant "Payment App" as PSPUI -participant "Payment Provider" as CPSP - -note over Payee, PSPUI: HTTPS - -title Generic Payment Request API Flow V1 - -== Negotiation of Payment Terms & Selection of Payment Instrument == - -Payee->UA: Present Check-out page -Payer<-[#green]>UA: Select Checkout -Payer<-[#green]>Payee: Establish Payment Obligation (including delivery obligations) -Payee->UA: Payment and delivery details - -UA->UAM: PaymentRequest (Items, Amounts, Shipping Options ) -note right: PaymentRequest.Show() -opt - Payer<-[#green]>UAM: Select Shipping Options - UAM->UA: Shipping Info - note right: shippingoptionchange or shippingaddresschange events - - UA->UAM: Revised PaymentRequest -end -Payer<-[#green]>UAM: Select Payment Instrument - -Payer<-[#green]>UAM: Authorise - -UAM<-[#green]>PSPUI: Invoke Payment App (Instrument) - -UAM->PSPUI: PaymentRequest without Shipping Options - -opt - PSPUI<->CPSP: Method specific processing (e.g. Authorise Payment / Tokenise Payment Instrument) - - opt - PSPUI<->UAM: UI Challenge/Response - end -end - -PSPUI->UAM: Payment App Response - - -UAM->UA: Payment App Response - -Note Right: Show() Promise Resolves - -== Payment Processing == - -UA-\Payee: Payment App Response - -opt - Payee-\MPSP: Finalise Payment - MPSP-\CPSP: Finalise Payment - CPSP-/MPSP: Payment Response - MPSP-/Payee: Payment Response -end - -== Notification == - -UA->UAM: Payment Completetion Status - -note over UAM: response.complete(status) - -UAM->UA: UI Removed - -note over UAM: complete promise resolves - -UA->UA: Navigate to Result Page - -== Payment Processing Continued == - -opt - Payee-\MPSP: Finalise Payment - MPSP-\CPSP: Finalise Payment - CPSP-/MPSP: Payment Response - MPSP-/Payee: Payment Response -end - - -== Delivery of Product == - -Payee->Payer: Provide products or services - -@enduml \ No newline at end of file diff --git a/images/callback_flow.puml b/images/callback_flow.puml deleted file mode 100644 index 843b7d3..0000000 --- a/images/callback_flow.puml +++ /dev/null @@ -1,42 +0,0 @@ -@startuml - -Participant "Payee Webserver" as Webserver -Participant "Checkout Page" as Webpage -Participant "Payer Browser" as Browser -Participant "Payer Payment App" as App -Actor "Payer" as Payer - -title Using callbacks for payment app to payee comms - -Webserver->Browser: Checkout Page with Pay Button - -create Webpage -Browser->Webpage : Render page - - -Payer->Webpage: Press Pay - -Webpage->Browser: requestPayment(Payment Request) -Browser->Webpage: Promise - -Browser->Payer: Get Payment App selection -Payer->Browser: Select Payment App - -create App -Browser->App: Payment Request - -group Payer interacts with app - App->Payer - Payer->App -end - -opt User interaction prompts app to get updated payment details - App->Webserver: Get new payment request - Webserver->App: Updated payment request -end - -App->Browser: Payment Response -Browser->Webpage: Resolve Promise\n(Payment response) -Webpage->Webserver: Payment Response - -@enduml