"Middleman Id/Commission %/Payeeer" provision

[richardPAG]

Is there a provision in this API for a PWA vendor/supplier to identify (a (pre)registered relationship) with a Payment Handler in order to charge commission and/or a flat fee for a Payment Request?

For the sake of example, let's say a much smaller version of Uber who doesn't have a direct relationship with VISA, MasterCard etc but needs to charge the User/Payer as well as the Driver/Payee a fee for using the PWA service. IOW, the Payment Handler must split the payment to multiple payees. (Don't know if this is already happening in certain tax jurisdictions.) Super-Mini-Cabs has registered with PayPal and will accept payments via that instrument. How do they get the cut sans friction and without having to chase the driver for it after the fact?

If not possible/legal is there a facility via the Payment Request API for adding an Item that does not further attract the Payment Handlers fees on top?

[rsolomakhin]

Not super clear on this use case, but it sounds like the payment handler would be in the correct position to determine where the funds should be transfered, based on the hostname of the merchant.

[ianbjacobs]

Hi @richardPAG,

Let me see if I have understood the use case. (And please correct me if not.)

• The merchant displays a total T.
• The user chooses a payment handler that wishes to impose a surcharge for the use of the payment handler (say, 1 USD).
• The user chooses to pay with some payment method owned by PMO.
• The following transactions should happen:
  • The user agrees to pay T to the merchant via PMO
  • The user agrees to pay $1 to the payment handler owner via PMO

Does that sound correct? My sense is that the following should happen:

• When the user installs the payment handler and sets it up, the user provides credentials and also agrees to pay the $1 fee via the same payment credentials.
• When the user says "ok" in the payment handler:
  • The payment handler owner uses the credentials for payment of the $1 by PMO to the payment handler owner.
  • The payment handler separately does whatever it does for the merchant part (T), whether it means returning credentials to the merchant for subsequent authorization, or initiating the payment via a server (e.g., for a credit transfer).

Within the payment handler, the user would see clear messaging:

• Do you agree to pay T to merchant?
• Do you agree to pay us $1?
• If so, push ok.

Ian

[richardPAG]

@rsolomakhin Yes that would be "normal" but require predetermined formal agreements between PayPal and Super-Mini-Cabs. Negotiation, contracts etc. Given that PayPal et al currently allow merchants to simply register on-line what you are describing is a retrograde step IMHO. So, yes, it would be fantastic if all payment providers could introduce a registration step that would ask "What percentage to skim off the top for you?" before charging their commission/fees, but I was wondering if the Payment Request/Handler APIs was not a logical place for it?

[richardPAG]

Hi @ianbjacobs

The following transactions should happen:
The user agrees to pay T to the merchant via PMO
The user agrees to pay $1 to the payment handler owner via PMO

Not sure if this is the case. Most seem to want to hide fees so that

• The user agrees to pay T for all products/services via PMO
• The PMO deducts Middleman PWA fees and sends to account
• The PMO deducts its own fees
• The PMO sends residue to Merchant

If that is not the case then the rest of your idea sounds good!

[ianbjacobs]

Hi @richardPAG,

I am hearing this (please correct me if I'm wrong):

• The merchant and the payment method owner reach a private agreement about fees.
• The user pays the payment method owner. Then the payment method owner disburses
  money (T - fees) to the merchant.

How this would work with payment request API would likely depend on the payment method.
For example, in the private agreement, the merchant might give the PMO the merchant's bank
account number, and the PMO could transfer "T - fees" on the server side.

It is not yet clear to me that Payment Request API plays any special role here, but rather it is the payment method data and private arrangements that do the work. It also sounds like it's feasible
with the right payment method data and agreements.

Ian

[richardPAG]

Thanks for the reply @ianbjacobs

It is not yet clear to me that Payment Request API plays any special role here,

The extremely important role it plays is to standardize the relationship between the four parties that will become more and more the norm with e-commerce transactions.

1. The User/Payer
2. The Agent/Middleman/Franchiser
3. The Payment Method Owner
4. The Merchant/Vendor

If it has to be your original and additional idea of "Do you agree to pay $1" then fine. But we cant'l have Mom & Pop Super-Mini-Cabs asking Ernst&Young to strike the same relationship/rates with PayPal, AliPay, etc

Thanks to you people. soon the browser will contain almost all the infrastructure needed for friction-less eCommerce but you are explicitly excluding small players or startups in the PWA field from gaining critical mass without going IPO :-(

The PWA vendor does not want to have to chase the merchant for money. The merchant does not want to chase the PWA vendor/franchiser for money. And we all want to be able to chop and change PMO when ever we like and can do so because W3C have made it easy and standard.

I suppose minimum support would be a standard optional AgentID which the PMO may consult when determining to accept or reject a payment request. This would be obtained in a similar fashion to Google Maps AppId, or Oauth2.0 tokens for Google+, Facebook etc? Just thinking out loud. Sorry.

[richardPAG]

Oh, forgot to stress it is essential that merchant and agent must have maximum PCI DSS compliance of SAQ!

I suppose the easiest way to think of the "use case" is the gig-economy. Make sense?

[rsolomakhin]

Ah, cool. I think I get it. So you would want a merchant to specify 'max_fee_acceptable': '1%' and payment handler to specify 'min_fee_required': '0.5%' and have the browser filter and sort payment handlers based on the "spread" to select the lowest possible fees for the user. Interesting concept! Did I describe your idea correctly?

[ianbjacobs]

I am still working to understand the use case. Thanks for the continued discussion.

My assumption is that a merchant would only agree to be paid less than the total (T) if the merchant had already agreed to that. This could be done when registering to accept the payment method
(as is the case today). I am hearing the idea that the fees could also include money that is paid to PWAs.

@rsolomakhin's comment is interesting, but I don't hear this to be about lowering user fees. The user always pays "T". What changes is how T is divided up among the other parties. This suggests that (fortunately), the browser shouldn't have any particular role to play here.

So, assuming that there is some prior agreement that "fees will be paid," is the idea that the fees are determined on a per-transaction basis?

If that's the case, then:

• The merchant provides some fee information and any other information needed (e.g., merchant ID).
• The payment handler can respond true() or false() to hasEnrolledInstrument() depending on whether the fee affects the payment handler's ability to fulfill the transaction requirements.
• The PMO divides up T accordingly and makes payments to the merchant and PWA.

Is this any closer to the use case?

If it is, it continues to sound very payment method specific to me, rather than a general purpose PR API feature.

[richardPAG]

@rsolomakhin to be honest I haven't thought through implementation details thoroughly enough. I only discovered there was such a thing as a Payment Handler API last week and I'm having to look at this in my spare time. (Please let me say how exciting the Web Payments stuff is at the moment! IIUC, from I/O 2017 (I think?) PayPal is working with Chrome so that a user does not have to install any additional software to make payments! No Native App, no Google Pay library, no Stripe trying to take over the UI, just register with PMO then make payments. Too easy!)

@ianbjacobs I think I am confusing people too much. The most important take away from this topic, that I hope everyone agrees on, is that Web Transactions in the Gig Economy more and more need disbursement functionality. And the Payment Manager/Request APIs is the natural home of the industry standard implementation.

But to discuss further . . .

While I like the terms Agent or Franchiser the PWA owner/vendor is and remains the "Merchant" in the transaction as per your spec definition. Dickie's PWA has a relationship with the PMO, is authorized by the User to deduct funds, and is the source of instruction/truth on txn outcomes.

I've back-flipped on specifying and AgentID to the API :-( As the API is being driven by Dicky the additional parameter could be FranchiseeID or SubAccount or JointVenture which is also registered with the PMO.

Furthermore, your API quite rightly does no maths so the PWA will just instruct the PMO to send $10 (minus PMO fees if any) to Dickies PWA and $90 to the "real" merchant minus PMO fees. (How the PMO fees are broken up between User, PWA, and Merchant is left as an exercise for the PMO but let's all agree it's doable.

TODO:

1. How is PWA approval to act as Agent for the Merchant discerned by PMO apart from just having the MerchantID? Only depositing? Heuristics? Don't want it done downstream at PMO.
2. What stops the PWA charging too much? What stops the PMO?
3. What stops a PWA spoofing a Merchant and taking money and providing no fees and services?

I don't see any big/unsolvable problems.

The Use Case is valid and needs to be addressed right?

PS. Some may ask "What's in it for the PMO? Why should they bother?". Not much I suppose but that must not deter W3C from specifying the functionality! If Google Pay offers disbursement options and ALiPay or PayPal don't then I'll put money on which PMO PWA vendors/authors and ultimately merchants will support/mandate.

We finally have a way to monetize PWAs without just advertising!

[richardPAG]

I suggest PayPal would find it easy to hook your API spec into into existing PMO functionality such as Payouts?

(Don't think we need multiple currencies here? Eg: - $10 in Virgin-Islands coconuts or Jersey Gerbils)

Is the encrypted member id enough?

[ianbjacobs]

@richardPAG,

Thank you for continuing to add to the discussion. I admit I do not yet fully understand the use case requirements and whether any changes are need to either the Payment Handler API or the Payment Request API, or whether the use case is enabled simply through the exchange of the relevant payment method data.

Perhaps the way forward is for you to experiment:

• Define your own payment method (with a URL identifier and whatever data model you need)
• Create an experiment merchant site
• Create a Web-based payment handler

The question from the standards perspective is: does the API suffice or need changes?

Ian

[richardPAG]

Thanks @ianbjacobs,

The Payment Handler and Request APIs will be affected but only slightly: -

The PaymentRequestEvent and the Details arguments will now contain a modified version of type PaymentCurrencyAmount: -

   total: {
       label: "Total due",
       amount: { currency: "USD", value: "65.00" },
       disbursement: [
           {
            payeeId: "XYZ",
            value: "5.00"
           },
           {
            payeeId: "ABC",
            value: "60.00"
           }
   }

Please tell me if that is still not clear?

The "disbursement" attribute can be optional but I suggest there should be someway of identifying the request so that non-supporting PMOs can throw an exception. It is up to the handler to validate that the sum of the disbursement items matches the total.value.

Make sense?

PS. I only read the specs in detail last night (again well done!) but am still at a loss as to why you are using a ServiceWorker for this implementation. I'm not saying it's an antipattern but: -

1. Client/UI is always present for payments. Essential for authorization.
2. No need for separate thread as UI has async capabilities and is waiting anyway
3. No background processing required or sanctioned
4. The UA will never receive an event or condition that would cause it to say "Hey better fire up that SW with a payment handler for this."

Look, I know a bit about ServiceWorker extensibility (please see Background Geolocation) just not enough to see the requirement here.

Anyway I'm going to hit BobPay this w/e. (Hope you're getting the resources you deserve!)

[rsolomakhin]

One reason to use Service Workers is for the CanMakePayment event.

[ianbjacobs]

@richardPAG, thank you for the code. That helps me understand that you would like the merchant to specify how the payment should be divided up and to which parties.

This is definitely a new use case, and so I would like to ask others (here on GitHub and in other conversations) to help flesh it out.

It is not yet clear to me that the very generic approach you sketched would work across payment methods. (I realize you are using it to help communicate; it's not a fleshed out proposal.) But what comes to mind is this:

• Today Payment Request makes possible for a single party to collect credentials for payment (which may be used however that party chooses to use them) OR for a payment handler to cause payment(s) to happen (however that payment handler chooses to do so).

• For the case where the merchant does the disbursement with credentials it receives,
  Payment Request would work as-is.

• For the case where the payment handler does the disbursement, the payment handler
  today would need to receive all the account information necessary from the merchant (or
  other party calling PR API). This account information would need to be part of the request
  data sent by the merchant.

• Discussions we've had up to now have assumed that the request data is (potentially)
  about a single account: the merchant's. Your use case involves request data that may
  relate to multiple accounts, and how funds are disbursed to those accounts.

• One way to imagine changing Payment Request API is to move away from the implicit model
  ("this is about the origin that called the API") to an explicit model (where the merchant identifies N payees and the M payment methods accepted by each payee). I would not recommend that we do anything that sophisticated until we have a much better understanding of the use case and how widespread it is or is likely to be. In short: I would not recommend that we think about changing Payment Request until we have more experience with this.

• To get experience, I suggest definition of a new payment method. The payment method
  could make some assumptions, like "all the parties accept credit card payments and ACH
  payments." Then you could define the request data so that, FOR EACH PAYEE, the merchant
  specifies:

  • Payee identity
  • Payee account
  • Disbursement amount

• You can, of course, make additional assumptions, such as "For each payee, the payment handler
  will know how to pay that payee." However, that would result in a lot of 1-to-1 relationship establishments that would increase friction.

All of this to say: I suggest experimenting with your own payment method first!

I hope that helps,
Ian

Ian

[richardPAG]

@rsolomakhin

One reason to use Service Workers is for the CanMakePayment event.

Sorry, I can't see anything here that would require a Service-Worker to implement. Can you please explain a little more?

@ianbjacobs I too would very much like to hear from others on this! You clearly have a better grasp of all the issues than I.

A couple of things to bear in mind though regarding the scope of this functionality: -

1. The disbursement is opaque to the User/Payer (as is the case everywhere today)
2. The disbursement infrastructure can not introduce an additional PCI DSS compliance burden.
3. The User's UA has no knowledge of destination accounts

Re: .2 I am hoping that an encrypted PMO ID of a payee can be stored in the PWA database without attracting more severe PCI DSS requirements?

Yes, there would be many additional 1:1 relationships between Payee/PMO but the friction would only be incurred at Merchant <=> PWA/Account registration time.

Sure we have lost the ease to chop and change PMO at will, but that's it. Right?

After thought: - (Out of UA scope) When merchant registers with PWA they are presented with a list of PMOs supported by the the PWA at which point the merchant can select one and then either enter their PMO unique ID or register.

One API, two uses: -

1. As now, allows users via UA to make/approve purchases from merchant via PWA
2. Allows PWA and Merchant to agree via UA on mutually acceptable payment method. (Result still needs to be stored in PWA DB but leverages what the Merchant has already registered in the UA)

[rsolomakhin]

@richardPAG wrote:

I can't see anything here that would require a Service-Worker to implement. Can you please explain a little more?

The browser can fire a CanMakePaymentEvent in the service worker to determine whether that service worker should be offered to the user as one of the payment handlers. No payment handler UX is displayed at this time, so it does not make sense to load a PH web page. The SW works best for this type of use cases.

[richardPAG]

@rsolomakhin not sure if I'm being really stupid here or you're being incredibly terse?

I put it to you that there is absolutely nothing in the CanMakePaymentEvent that requires it to execute in the context of a ServiceWorker. That Event could just as happily execute in the main UI thread.

By saying "The broswer can fire" you seem to be implying that this may occur for reasons other than a user-driven payment request. If so, please specify.

I think it would cut to the chase and save time if you could preface your answer with "You cannot do X in the main thread" or "ServiceWorkers are essential here to provide Y functionality". I know I'm being a bit thick here but I just keep hearing you saying "We need ServiceWorkers because we need to use Events and Javascript".

[ianbjacobs]

Hi @richardPAG,

In the past we have talked about using service workers for:

• Asynchronous updates to the capabilities of a payment handler
• Offline payments
• Asynchronous pushes from servers for user authentication.

Also, it is not clear whether, for security reasons, payment handlers should run in the main thread.

Please note that I am neither a security expert nor a service worker expert; I am trying to recall previous conversations.

Ian

[richardPAG]

Cool. Thanks @ianbjacobs I am looking at BobPay and was wondering if the PaymentMethodManifest allowed the SW to be instantiated in the BobPay.xyz domain. Anyway forget SWs it's the "disbursement" functionality I'm after and will leave it with you. Good luck!

*** UPDATE: I have been really stupid :-) Or more importantly, the UA guys are bloody brilliant!!!

IIUC The UA checks the PaymentManifest and for any previously unregistered/unknown and URL-based payment methods it then fetches the specified PaymentWebApp Manifest. (I had no idea why the latent support for registering a serviceworker via the manifest was there until now.) The UA then fires the SW up in the scope of the Payment Handler(s) domain, so if we have PayPal, AliPay, and BobPay supported methods then we'll have 3xServiceWorkers all ready to respond, when needed, to their respective "canmakepayment" and "paymentrequest" events. This is just too sexy for words!!!

Amazing levels of demarcation and isolation. Formidable!

[richardPAG]

Another similar remittance use case: -

PWA via PMO disburses Delivery Fees to 3rd party at txn time?

[richardPAG]

I would not recommend that we do anything that sophisticated until we have a much better
understanding of the use case and how widespread it is or is likely to be. In short: I would not
recommend that we think about changing Payment Request until we have more experience
with this.

I wouldn't recommend it either! We need to manage scope on this and realize none of us are Neil Armstrong here when it comes to disbursements, so let's all be humble enough to not re-invent the wheel?

Just been looking for similar existing disbursement functionality and sure enough great minds think alike :-)

Look, I have no interest in PayPal, I don't have a PayPal account, and first visited their Web Site last week. Having said that they're clearly ahead of the game and the pack! Just give them the PayPal IDs and amounts and it's done. They could have a POC up and running in a week!

Up to you guys if you need a new/additional Payment Method or whether the mere presence of the Disbursement object suffices to identify a Payout txn.

Let's go!

NB: I hope someone/anyone can please, please PLEASE confirm that I (the PWA vendor) can store encrypted PMO/PayPal IDs on my database without triggering more onerous PCI DSS compliance? Pretty please?

FWIW. Stripe seems to support the concept of Application_Fees on their Charges object. Couldn't find any multiple account logic in their API that would dove-tail with Web Payments like PayPal. I could be wrong.

Collecting application fees

With Connect, your platform can take an application fee on direct charges and subscriptions.
To assess an application fee on a charge, pass an optional application_fee_amount value as a
positive integer:

IMPORTANT

There are no additional Stripe fees on the application fee itself

[ianbjacobs]

@richardPAG,

I can't speak authoritatively about PCI compliance issues. However, we do have some notes from previous discussions with PCI:
https://github.com/w3c/payment-request-info/wiki/FAQ#rules-and-regulations-questions

Summary: If you are a merchant, then using PR API versus a form should not have an impact on PCI compliance. If you are payment handler developer, see PCI FAQ 1283.

Meanwhile, we discussed the disbursement use case briefly on our teleconference today:
https://www.w3.org/2019/03/21-wpwg-minutes#item03

I'll see if we can spend some more time at our upcoming face-to-face meeting.

One note: I may be focused elsewhere for the next couple of weeks for meeting planning; I will be back here when I can!

[richardPAG]

Thanks @ianbjacobs for the pointers, your time, and interest!

I'm confident the Disbursement idea is in front of the right people and getting the exposure it deserves. (Unlike Background Geolocation). I'll leave it with you (and the 49 others attending :-)

It's a great shame you weren't the first W3C person I came across.

[ianbjacobs]

@richardPAG, thanks so much for the kind words. I'm happy to work with passionate and collaborative people!

Ian

[richardPAG]

Just some more justification. As if it was needed. It appears that if you haven't heard of disbursements/multi-party txns then you've been living under a rock :-)

Good luck next week!

[ianbjacobs]

Hi @richardPAG,

I've put some more thought into this question of multi-party payouts. The references to PayPal and Square you provided were helpful. In each case, there is a notion of identity (specific to the payment system) that is necessary in order to identify beneficiaries.

I'm not at all familiar with standardization efforts in this space. However, I believe that our Interledger Protocol friends (cc @adrianhopebailie) are doing something relevant: payment pointers:
https://interledger.org/rfcs/0026-payment-pointers/

So it's conceivable an ILP-based solution could work here, and it would have the advantage of working across a variety of settlement methods.

• The payment request includes the relevant amounts and payment pointers for beneficiaries. I don't know how much security is required in passing those parameters to a payment handler.
• An ILP payment handler could disburse payments to those parties.
• The payment handler would then return some sort of receipt to the merchant.

@adrianhopebailie, has this use case come up in the ILP community?

Ian

[richardPAG]

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
@stripe supports a Web App fee structure
@paypal payouts 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??? 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?

[ianbjacobs]

@richardPAG,

I don't mean to express reticence. I'm still working on my understanding of the use case and role of a standard. Please bear with me.

My assumption is that for any of the payment methods you named (paypal, square, stripe), each one would have its own internal approach to managing disbursements. Thus, the request data would be specific to each one of those. I have not approached any of those companies to ask whether they would be interested in standardizing the request payload or identity system (for identifying beneficiaries). Is the role you imagine for the standard to create a common request payload across those payment methods that support disbursement?

Another way of putting the question is: if square and stripe and paypal can (already?) do disbursements with their own payment method specific data models, what additional capability is needed in payment request API?

Ian

[richardPAG]

I don't mean to express reticence. I'm still working on my understanding of the use
case and role of a standard. Please bear with me.

Cool. My bad. Sorry.

Is the role you imagine for the standard to create a common request payload across those
payment methods that support disbursement?

Yes. each one would have its own internal approach to managing disbursements BUT it is you and the Web Payments API that provide the Rosetta Stone or Payment Prism allowing Payment Handlers to standardize on disbursement instruction from the merchant.

I know I have way over-simplified what needs to be done on the Payment handler end. (Some will want a flat commission, others charge plus commission, others commission free on the merchant account, volume discounts/penalties may cut in at X txns or Y $s, and so on . . .) but all of that down stream processing is ancillary to fundamental transaction processing of Joe Customer is paying $10.00 for goods and services.

We really need payment handlers to be driving the loop but it shouldn't take long. Please just ask everybody/anybody what business requirements and/or functionality is not supported by: -

total: {
       label: "Total due",
       amount: { currency: "USD", value: "65.00" },
       disbursement: [
           {
            payeeId: "XYZ",
            value: "5.00"
           },
           {
            payeeId: "ABC",
            value: "60.00"
           }
   }

No separate currencies.
Sum of the parts must equal the whole. (PH vetted not API)
Accounts must exist.
PaymentId is opaque and meaningful only to the handler.
Maybe: - If present and I don't support multi-accounts reject the promise.

Are you able to run that up the flag-pole with some Payment Handlers? Are there any here?

[richardPAG]

BTW. In case it wasn't clear, the Payee/Customer has no knowledge or visibility to the disbursement details. The payeeId(s) are held in Super Mini Cabs database.

[ianbjacobs]

@richardPAG,

In practice, each system is going to have its own internal identity system ("XYZ", "ABC", etc.).

If we expected disbursements to be handled by "arbitrary" payment handlers, having a standardized description of identity would make sense. But for the moment, at least, it seems disbursements will be done by known payment handlers (for the payment method supported by each handler). So the merchant will say "Square, do this. PayPal, do this. Stripe, do this."

Perhaps the piece I am missing is: what is the use case where the disbursement could be carried out within a payment method not already known by the merchant?

[richardPAG]

In practice, each system is going to have its own internal identity system ("XYZ", "ABC", etc.).

Absolutely, as honoured and reflected in the existing spec eg: -

       supportedMethods: "https://example.com/bobpay",
       data: {
             merchantIdentifier: "XXXX",

If we expected disbursements to be handled by "arbitrary" payment handlers, having a
standardized description of identity would make sense.

Let me just point out that the existing Payments API has never catered for "arbitrary" payment handlers. The level of standardization required is simply a recognized slot for merchants to communicate with payment handlers.

My proposed "disbursement" dictionary is analogous to the Web App Manifest(s) identified by the PWA/merchant in the Payment Handler Manifest. That is, meaningful only to the target payment handler.

Perhaps the piece I am missing is: what is the use case where the disbursement could be
carried out within a payment method not already known by the merchant?

Forgive me if I bristle but currently, apart from basic-card, which payments can be carried out within a payment method not already known by the merchant?

The use case is unchanged from that I outlined previously: -

The merchant has pre-approved a number of modern payment handler(s) knowing they support multi-party transactions. The necessary payment handler hooks have been identified and registered in the Payment Handler Manifest. The PWA/Super-Mini-Cabs/Me can rest/code safe in the knowledge that regardless of the end/chosen Payment Handler, the generic disbursement dictionary will cater for the handshake/instruction.

This simply must be standardized/made available!

Once again, let me stress the goals of your spec: -

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.

Cheers Richard

BTW. What App/ServiceWorker is used for "basic-card"

[ianbjacobs]

"the existing Payments API has never catered for "arbitrary" payment handlers."

Basic Card is designed to allow arbitrary payment handlers. Whether or not the ecosystem decides to pursue that path is another question. The architecture allows (in multiple ways) for payment handlers to evolve and be used without the merchant having to adjust their code. Obviously for proprietary payment methods, we do not expect arbitrary payment methods.

Forgive me if I bristle but currently, apart from basic-card, which payments can be carried out within
a payment method not already known by the merchant?

I anticipate our current work on the SRC payment method will also go in this direction.

What App/ServiceWorker is used for "basic-card"

I have seen demos (but not necessarily shipping code) from companies such as Klarna and Worldline. As I mentioned, the ecosystem may not choose to build payment handlers for basic card, but the architecture supports the openness.

regardless of the end/chosen Payment Handler, the generic disbursement dictionary will cater for the handshake/instruction.

I believe I now understand what you would like (and your disbursement / payeeID / value code above reflects this).

It is conceivable that merchants and payment method owners could benefit from a standardized "disbursement description." I suspect that would be just a piece of the payment request data for each payment method.

I don't mind asking our colleagues at the companies you mentioned to see if there is interest. I imagine if there is interest from the largest players in this space, that would help to jump start the work.

I will ask around and report back.

Ian

[richardPAG]

Really appreciate it Ian. And thanks for continuing to listen.

[marcoscaceres]

@richardPAG, modified your offensive comment above. We remind you of our code of conduct.

[ianbjacobs]

@richardPAG,

I wrote to the three companies you mentioned and heard back from two of them. I did not ask to share responses publicly, so I won't do so here.

One person answered that they did not think it was appropriate for Payment Request to manage disbursement details.

The other person acknowledged the use case and made some observations. However, the comments did not address directly the value of standardization of proportion and beneficiary information. I followed up and asked for clarification but have not yet heard back.

I wanted to give you an update (2 weeks after I indicated I would reach out). I will let you know if I hear additional feedback.

[richardPAG]

@ianbjacobs Thanks for the update!

One person answered that they did not think it was appropriate for Payment Request to
manage disbursement details.

I would be very curious to know how they can describe as inappropriate functionality they already surface this via Payment Requests from their bespoke proprietary API solutions? You don't necessarily need to identify them here as I have provided links to their existing and fully supported developer offerings. What is required is a standard way of solving already accepted business requirements.

@square have provided multi-party transactions
@stripe supports a Web App fee structure
@paypal payouts are the most flexible of the lot

The other person acknowledged the use case and made some observations. However,
the comments did not address directly the value of standardization of proportion and
beneficiary information.

If "standard" Web Payments are not an issue then why are we all here? What I propose will permit (relative) freedom of movement/choice of Payment Provider to all PWA manufactures by not locking them into proprietary bespoke solutions: -

1. Super Mini Cabs supports PayPal, Square, and Stripe
2. Driver Fred can choose one that he has an account with
3. Everyone gets paid in the one txn

I must not be articulating the brilliance of this feature because it will revolutionize web payments and most importantly provide a way for PWA vendors to monetize the App!

I followed up and asked for clarification but have not yet heard back.

Thanks again.

Can we please try to tackle this another way briefly? You show me how you as Super Minicabs would take the money from the end-user and pay your driver without getting slapped with a severe PCI DSS burden?

No one else see the potential here?

[richardPAG]

Another avenue worth exploring would be Google Pay. I'm sure you must have contacts at Google Pay. They don't seem to support disbursements/multi-accounts at present but could sweep the market up by being the first to integrate with the propose standard.

Downside could be that Google Play and the iStore fade away as marketplaces and the one-off payment model fades into history?

[richardPAG]

A couple of related stack overflow questions FYI
https://stackoverflow.com/questions/34585903/commission-base-payment-gateway
https://stackoverflow.com/questions/46243227/monetize-a-pwa-which-to-use-for-monetizing-a-progressive-web-app

This will be huge!

Maybe "down the track" your SRC and FIDO2 stuff will take off but the simple KISS solution I propose now at least opens the door and is nothing short of a paradigm-shift-enabler.

[ianbjacobs]

@richardPAG, we are still early in this conversation. I will continue to ask around. I also invite others to weigh in on this thread for what they perceive as the standardization opportunity.

[richardPAG]

Great! Thanks @ianbjacobs.

[richardPAG]

@ianbjacobs Just curious about the support for PaymentCurrencyAmount in the specification as opposed to a globally payment qualified currency: - "required value amount". IOW does any payment processor permit differing currencies for say tax and discount?

If they don't, would this latent support ever be implementable?

[ianbjacobs]

@richardPAG,

I don't know enough to answer the question about what processors might offer or allow.

Several thoughts occur to me:

• We had some early discussions about dynamic currency conversion:
  Should it be possible to provide "total" amounts in more than one currency payment-request#3

  At the time we decided that we would not (in version 1 at least) include support for
  currency changes per payment method.

  My recollection is also that we thought that payment handlers could offer different currency
  conversion services, and we wanted to learn more from real world deployments.

• We have also had discussions about split tender payments; I think there remains interest in
  addressing those (which might also include some use cases like "paying with points and
  another payment method"). I mention this because it seems to me that the fine-grain change
  you mention regarding currency might also be applicable in a multi-tender scenario.

Ian

[richardPAG]

Thanks @ianbjacobs for the explanation.

WRT. Disbursements please see a discouraging Stripe comment in stackoverflow.

I hope this illustrates one of the very strong reasons we need a standard interface here.

[richardPAG]

Also some feedback from Square. HTH

[adrianhopebailie]

Hi @richardPAG sorry for the slow response, I think I finally understand your use case properly.

Something worth noting upfront is that the API intentionally differentiates between generic payment data and payment-method-specific data.

For example, the total is generic but supportedNetworks in a basic-card request is specific to basic-card. Basically, anything that is passed in the data field of an object in the payment method data array (example below) is specific to the payment method.

This allows us to keep the standardized API surface small but still allows payment methods to innovate.

It does happen that we identified some data element that is payment-method-specific that could be elevated to the generic data model. An example is billing address which is specified for basic-card but we increasingly see is applicable to all payment methods.

I believe disbursements could be in the same category. i.e. The payment methods that support it will specify how to use the feature in their own data models and if there is agreement that this is worth elevating based on experience from its use then we will do that.

So initially I'd anticipate a request to look like this (using the 3 examples of payment methods that already support this to some extent):

const methodData = [
  {
    supportedMethods: "https://square.com/",
    data: {
      parties: [{ 
        merchantId: "super-mini-cabs",
        portion: 0.1
      },{ 
        merchantId: "driver-fred",
        portion: 0.9
      }],
    },
  },
  {
    supportedMethods: "https://stripe.com",
    data: {
      application_fee_amount: 1.00,
    },
  },
  {
    supportedMethods: "https://paypal.com",
    data: {
      payouts: [{ 
        paypalId: 12478764,
        amount: 1.00
      },{ 
        paypalId: 23448764,
        amount: 9.00
      }],
    },
  },
];

This is obviously completely made up but already it's clear that some standard here would be a challenge.

• Are disbursements explicit or calculated on a ratio?
• How do we standardize on payee identifiers?

Another 2 observations:

1. In your use case I would assume SMC to already know, at the time they invoke the API, which payment method Fred has chosen to use. So constructing a request that is specific to that payment method seems likely I see little value in constructing a request for multiple methods with a standardized disbursement data payload or am I missing something?
2. This case only really applies when the payment handler invokes the payment which we see as an increasingly rare case. Rather it seems more likely that the payment handler will return some credential that the merchant uses to pull the payment. At this point I'd expect the PWA to pull the payment and deal with disbursing the funds to the driver, no?

[richardPAG]

@adrianhopebailie Thanks for the response. You may well have just answered my original question! methodData looks to flow from SMC though to the PaymentRequestEvent so could very well be the "best" solution? Just up to Payment Handlers to specify the contents. Not the best solution, but it's sure better than nothing!

Are disbursements explicit or calculated on a ratio?

Explicit.

How do we standardize on payee identifiers?

You don't. The same way you currently don't standardize on Merchant identifiers as I have explained in this thread.

Observations: -

1. SMC knows Fred's Payment Provider and Jack's (which maybe different). The value comes from allowing SMC to provide support for a variety of providers. With a standard API. Is your contention that SMC should just really cater for native bespoke Javascript libraries from each payment provider?

NB The options are never shown the the Payer! They are made available to each driver when they sign up.

2. "This case only really applies when the payment handler invokes the payment which we see as an increasingly rare case. " The Payment Handler invokes the payment? I have no idea what you mean with (2).

[richardPAG]

Before I get too excited :-( Let me guess. the problem is MethodData is a "frozenArray" of types and because the disbursements are explicit values that can vary up until shipping method et al have been specified it is not suitable as a method of communicating between PWA vendor and Payment Handler?

[richardPAG]

Hi @adrianhopebailie Did I misunderstand you?

Hi @ianbjacobs is there a conversation still going on about this feature? Any feedback?

[adrianhopebailie]

The value comes from allowing SMC to provide support for a variety of providers. With a standard API. Is your contention that SMC should just really cater for native bespoke Javascript libraries from each payment provider?

I think so, if we are talking about the same thing. If you look at my example code, there are 3 payment methods that the merchant accepts and all have different ways of expressing split disbursement.

That example would work with the API as it is today. No changes needed.

However, I am contending in observation 1 that it's even simpler than that. Since the merchant (SMC) already knows the payment method that the affiliate (Fred) has chosen to receive their disbursement with they can make the API call with only the disbursement details for that payment method.

I.e. If Fred chose Square then why would SMC call PR API with options for the rider to pay via PayPal?

If you are talking about the rider paying via PayPal and Fred still getting paid via Square then we're in a whole new regulatory realm where someone is acting as an intermediary and receiving the funds via PayPal first before making the payout via Square.

That's not in scope for us.

Earlier in this thread you said:

Yes. each one would have its own internal approach to managing disbursements BUT it is you and the Web Payments API that provide the Rosetta Stone or Payment Prism allowing Payment Handlers to standardize on disbursement instruction from the merchant.

I don't agree with this. We are trying to standardise enough to support as many use cases as we can and then get out of the way. Each payment system will have different ways that they support split payouts, it's not up to us to standardize those (unless they all join the WG and ask to use it as a forum to do that).

TL;DR: I support the use case and think it could be very popular but I think it's doable today without needing to make any changes to the API.

If you disagree it would be useful if you proposed a concrete API change that would be required to enable what you have in mind. (Or point out where I am misunderstanding something, which is also very possible).

p.s. Regarding:

This case only really applies when the payment handler invokes the payment which we see as an increasingly rare case.

There are two models of operation for the API that determines what is returned to the merchant via the PR API:

1. The PH returns some credentials (e.g. card details) to the merchant who uses those to invoke the payment
2. The PH invokes the payment (e.g. over Bitcoin) and returns a "proof of payment" to the merchant (or similar)

[adrianhopebailie]

Let me guess. the problem is MethodData is a "frozenArray" of types and because the disbursements are explicit values that can vary up until shipping method et al have been specified it is not suitable as a method of communicating between PWA vendor and Payment Handler?

@rsolomakhin or @marcoscaceres are better placed to answer this but I would assume that is not an issue otherwise it affects quite a few use cases.

I would expect to be able to update the payment method specific data after shipping detail changes. If that is not possible today then we should explore that specifically (with this use case as one reason it is required).

[ianbjacobs]

@richardPAG, you wrote:

is there a conversation still going on about this feature? Any feedback?

I've not received further feedback than what I reported. I think this is the current location of the conversation. Thanks @adrianhopebailie for contributing!

Ian

[richardPAG]

Cheers @ianbjacobs

@adrianhopebailie Mate, really appreciate the feedback and the time it took to provide! You people are really accommodating here at Payments.

I think so, if we are talking about the same thing. If you look at my example code,
there are 3 payment methods that the merchant accepts and all have different
ways of expressing split disbursement.

That example would work with the API as it is today. No changes needed.

I am in %100 agreement with you (except for rugby, cricket, and how to pronounce vowels :-)

The problem I have is that you're dreaming when it comes to MethodData volatility. No one would be happier than I to be corrected! If this is a scratchpad between Merchant and PH then "You Bewdy!" Having read the specs numerous times I think not :-(

I.e. If Fred chose Square then why would SMC call PR API with options for the rider to
pay via PayPal?

No one is suggesting this.

If you are talking about the rider paying via PayPal and Fred still getting paid via Square
then we're in a whole new regulatory realm where someone is acting as an intermediary
and receiving the funds via PayPal first before making the payout via Square.

That's not in scope for us.

Agreed. Fantasy land out-of-scope!

I don't agree with this.

Yes but you're continually putting out fires with "Who owns the shipping address" or "Sales Tax or GST calculated at PH".

TL;DR: I support the use case and think it could be very popular but I think it's
doable today without needing to make any changes to the API.

TL;DR agree with the sentiment but it is NOT available today.

Sadly, I still don't understand what you mean by 1. and 2.? Or more importantly which you says is deprecated or old-fashioned. I eat out a lot and catch Uber but don't understand what you are saying.

[adrianhopebailie]

but it is NOT available today

Can you be more specific as to why you say that, what fails?

[richardPAG]

I hope I'm wrong but I fear not : -

the problem is MethodData is a "frozenArray" of types and because the disbursements
are explicit values that can vary up until shipping method et al have been specified it
is not suitable as a method of communicating between PWA vendor and Payment Handler

readonly attribute FrozenArray<PaymentMethodData> methodData;

Maybe I misunderstand FrozenArray type? If I'm wrong then we're good to go.

[richardPAG]

TL;DR: I support the use case and think it could be very popular but I think it's
doable today without needing to make any changes to the API.

@adrianhopebailie in order to progress this I've gone with the bookies and just assumed I was wrong about the definitin of a "frozen" array. I have posted PayPal, Square, and Stripe tagged questions to StackOverflow and Twitter. This is the one I'd love to get up!

Unfortunately that is the extent of my influence on this matter :-(

I thought it was best to get this over with before we beat the Yarpies again in the world cup (got all the sand-paper we need :-) and we fall out.

Just hope someone picks the ball up and runs with it!

Talk about low-hanging fruit.