[use cases] Payee initiated Processing (or Funds Transfer)

Hi Manu et all,

Here is my proposal for a new use case : < Payee initiated processing >. All comments appreciated!

As a pull request:
https://github.com/w3c/webpayments-ig/pull/1

And content :
https://github.com/valca/webpayments-ig/commit/6603b3411f38d6a5bcf8068a4c14a8d8a2bbab3f

Raw text might be a bit easier to read:

*********
Payee-initiated Processing (or "Funds Transfer")

When a customer wants to make a purchase, the merchant requests from the customer's payment agent an Instrument Proof (other names? consent/instrument/hold?). The merchant sends this proof to its processor to initiate the funds transfer. The processor can return a Payment Proof to the merchant.

Basic Flow

Continuing from flow in 3.1
1. Payment Request is sent to Payment Agent via User Agent
2. Payment Agent sends Instrument Proof to Payee (direct callback or via User Agent)
3. Payee sends payment details and Instrument Proof to its Processor
4. Processor returns a Payment Proof to the merchant

Examples

- Customer POV: John goes to CandyCart.com and clicks "buy" to purchase chocolates. After selecting his bank's virtual card, his browser re-directs him to his bank's wallet, which acts as a payment agent. John approves the payment and his virtual card generates an Instrument Proof cryptogram that signs the transaction and captures his content. The cryptogram is sent to the merchant, which completes the purchase after verification.
- Merchant POV: CandyCart.com presents John with an array of chocolates to buy. After John has approved his cart and selected his bank's virtual card to pay with, CandyCart.com generates a Payment Request and sends it to John's Payment Agent. It receives an Instrument Proof from the payment agent and forwards it to CardProcessingCo, along with payment details, for processing the payment. It gets a Payment Proof from CardProcessingCo in return, which completes the purchase.
- Processor POV: CardProcessingCo receives a payment processing request from CandyCart.com. Because it is using standard Instrument Proof cryptograms, CardProcessingCo can handle the request as any other card payment.

Motivations

In this use case, the merchant triggers the payment processing using its processor. This flow is the closest to legacy card scheme flows (also, the one used in brick and mortar stores), and it is expected that supporting it will ease integration in current merchant systems.

An Instrument Proof in this use case is intended has a guarantee of possession by the customer of a valid, compatible payment instrument and that the customer has given consent for the payment. For comparison, a Payment Proof guarantees that the customer holds the corresponding funds and the funds will be transferred. These guarantees are typically provided by a Payment Scheme, therefore the format for these proofs will have to be scheme extensible.

Pre-conditions

- A number of payment agents are available on the customer device and at least one is supported by the merchant.
- A payment agent and payment instrument has been selected by the customer, and a payment request has been sent to the payment agent.

Post-conditions

- The payment agent has delivered an Instrument Proof (or a payment refusal)
- The merchant has obtained a Payment Proof from its processor
________________________________
This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus.