Re: [w3c/payment-handler] "Middleman Id/Commission %/Payeeer" provision (#335)

Hi @ianbjacobs et al.

I'm beginning to sense some reticence on your behalf regarding the homing of disbursement functionality in the Web Payments and Web Handler space. (Actually it's starting to feel like total push-back but I'm probably just being paranoid ;-) No matter, suffice it to say ILP and and payment-pointers are as useful as teats on a bull when it comes to end-user/customer/retail/web txns. So refusing to follow the bait and switch, please let me quote the following from the specs: -

> The payment method: the means that the payer uses to pay the payee (e.g., a basic card payment). 
> **The payment method provider establishes the ecosystem to support that payment method.**

@square have provided [multi-party transactions](https://docs.connect.squareup.com/payments/transactions/overview#mpt-overview)
@stripe supports a Web App [fee structure](https://stripe.com/docs/connect/direct-charges#collecting-fees)
@paypal [payouts](https://developer.paypal.com/docs/api/payments.payouts-batch/v1/) are the most flexible of the lot

The _ecosystem_ has been provided. The Web Payments API needs to support it!

**_It is absolutely essential that these willing and industry leading implementors be involved in the design of suitable/appropriate payment requests. What did they say at the F2F?_**

> The details of how to fulfill a payment request for a given payment method is an 
> implementation detail of a payment handler. 
>
> Steps to check if a payment can be made:
>  How a payment handler determines whether it, or the user, can potentially "make a payment" 
>      is also an implementation detail of a payment handler.

 If a Payment Handler can't handle disbursements then it can always say "no". (See the "data : bobPaySpecificFields") or, as I much prefer, in the "payments" manifest file, sepcify a URL that downloads the Web App Manifest for the Multi-Party Payment Handler functionality)

_OR_

EXAMPLE 1: The `methodData` argument

```
const methodData = [
  {
    supportedMethods: "basic-card",
    data: {
      supportedNetworks: ["visa", "mastercard"],
    },
  },
  {
    supportedMethods: "https://example.com/bobpay",
    data: {
      merchantIdentifier: "XXXX",
      bobPaySpecificField: true,
   **bobBayDisbursementSupport: true**
    },
  },
];
```

> 1.1 Goals and scope
> 
> Standardize (**_to the extent that it makes sense_**) the communication flow between a merchant, 
> user agent, and payment method provider.

The payment-disbursement is opaque to the spec-writers! This is the business flow: -

1) Super Mini Cabs has previously struck a deal with PayPal and Square for fees and service
2) Fred wants to register as a driver with Super Mini Cabs
3) Fred must create a SMC account with email and a choice of PayPal or Square customer ID. (SMC's PWA may offer a convenient link)
4) Once the confirmation email has been clicked (and some OOB account id verification may be possible) Fred is good to go.

**How hard can that be?**

For comparison, have you seen the W3C [Credential Management API???](https://w3c.github.io/webappsec-credential-management/) That requires an intimate/endoscopic understanding of Google, Facebook et al. 

> The following are out of scope for this specification:
>  Create a new payment method.
>  Integrate directly with payment processors.
> 

Kushdi! No one is asking the API to do that. Just to provide a reasonably "standard" way to delineating payment disbursements.

Are we on the same page? 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/payment-handler/issues/335#issuecomment-483920980