How do the payer and payee agree on the payment obligation as part of the flow?

[adrianhopebailie]

There was some discussion on this topic at the face to face and an interesting point was made by @mattsaxon and @vkuntz about the need for a user to confirm exactly what they are authorizing.

This could be inferred by the payment app which could make sure appropriate UI is rendered for the user to assist them but there needs to be some control from the payee in defining "what they are requesting".

It was suggested that the payee be able to provide a string that should always be displayed to the user and the payment app or user agent should ensure the user acknowledges this string and confirmthat they accept it.

This will be a requirement for some jurisdictions but may not be for others so it should be optional.

Examples:

• "Pay $50 to XYZ Store for invoice ABC123"
• "Reserve $300 for payment to ABC Car Rental"
• "Create a new recurring payment to Bob's DIY Magazine for $25 per month"

It was also suggested that the payee be able to provide a link to some T&Cs and request that the user click a check-box to acknowledge that they have read these.

My proposal is that we:

A. Include the request to acknowledge T&Cs in the payment options as this is something the user agent can handle and doesn't need to be done by the payment app.

The payment options might look like this:

{
  "requestShipping": true
  "requestTermsConfirmation" : true // displays a checkbox that the user must tick
  "termsURL" : "https://xyzstore.com/terms"
}

B. Include an obligation in the payment details that can be used by the payment app.

The payment details might look like this:

{
  "items": [
    {
      "id": "total",
      "label": "Total due",
      "amount": { "currencyCode": "USD", "value" : "60.00" }, // US$60.00
    }
  ],
  "obligation": "Payment for order 123 from XYZ Stores."
}

The payment app may then have some way to sign and time-stamp this with a user specific key to prove that the user accepted the proposed obligation.

@mattsaxon , @vkuntz : Is this sensible?

[mattsaxon]

It feel wrong to split these as I would suggest that it would be ideal if the signed details included the Ts&Cs that were signed up to.

That said Vincent is much more knowledgeable on the details of payment obligations that me.

Lastly, I would support a PR on the basis of the above without changes in order to get wider opinions and view this information in context with the other ongoing debate such as the payment journey hints.

[adrianhopebailie]

My motivation for the split is that I consider "payment options" as data that is only consumed by the user agent which could easily include this in it's own "chrome" but I agree that perhaps these need to be done together and passed to the payment app.

That way we allow payment apps to ignore these if the payment method allows that. I'm conscious that our API only enables features that are required (either technically or legally) but doesn't impose anything. The payment apps which will need to explicitly support a payment method should be the ones that ensure they do all the right things to be compliant with that method.

[halindrome]

I thought our position as a group was that Ts&Cs were to be handled by the merchant prior to calling payment request. In other words, the merchant has already verified that the customer understands rules about orders, obligations, shipping efforts, rules for returns, etc. Did I miss something where this philosophy changed?

[mattsaxon]

@halindrome I do recall the suggestion from your that this might make a good interim position and that was seconded by Nick, However I don't think that warrants consensus. I do however think that the High priority on this issue is misrepresentative, I think it should be at best medium.

[sideshowbarker]

I do however think that the High priority on this issue is misrepresentative, I think it should be at best medium.

Are there agreed-upon guidelines anywhere on what the priority indicators here actually mean? Right now from looking through a number of issues, it seems like the priority indicators are generally set by the issue submitter/OP. That strikes me as doing it the wrong way. I would suggest we consider instead having the workflow be that the priority indicators are set only by the chairs and/or editors, and the criteria the chairs/editors are to use for deciding on the priority should be documented (say, in the repo wiki).

[mattsaxon]

#105 is the closest we have.

I believe I've put most of the priority labels on as part of this, however since this issue, other have been chipping in. I don't believe people raising the issues in general have the rights to assign a priority as I needed to request access to do this activity.

[adrianhopebailie]

@sideshowbarker priorities are still as set by @mattsaxon when they were initially created. The chairs will review these during the course of this week.

[corwinAmbre]

Hello,
For labels at payment step, local laws are also to be taken into account as labels or T&Cs can be different from one country to another. For instance, in Germany the label on the "Buy" button is not just "Kaufen" but a full sentence meaning something like "I agree to pay using these payment information" and users have to accept 2 T&Cs instead of one (with 2 checkboxes).

[triblondon]

I posted #111 (comment) which is also relevant to this discussion, and as I've had personal experience trying to help someone escape a continuous payment authority, obligations do need to be clear. The following are clear, and demonstrate that obligations for recurring payments are not all the same:

• Create a new standing order for £30 per month to the Financial Times (The Financial Times cannot change the amount or schedule of these payments, and you can cancel the arrangement at any time. Payments already made may not be recoverable in the case of a dispute)
• Create a new direct debit to Amazon Web Services (Amazon Web Services will be authorised to debit your account for any amount at any time. You are guaranteed a refund of any disputed payments under the direct debit guarantee)
• Create a new recurring payment for £75 per week to XYZ Loans (XYZ loans will be authorised to debit your account for any amount at any time. You may not be able to recover money in the case of a dispute)

I appreciate that these obligations are hugely jurisdiction dependent (these examples are valid in the UK), and obligations embedded in the payment method do not affect the obligation to make the payment legally - eg if I dispute a direct debit, I am guaranteed to get a refund, but I might still end up in trouble if I legally owe the merchant the money and refuse to pay them via another means.

[adrianhopebailie]

I think the question here is, should the wording be defined by the website (merchant) or the payment app?

One could argue that the payment app, having the knowledge of the terms and the payment method that is being used is well equipped to prompt the user appropriately in authorizing the transaction.

However, I can't imagine this being done very well across multiple languages, or including the level of detail as @triblondon has above if it is generated by some logic in the app.

My suggestion is that we include some mechanism in the payment request for the merchant to pass this to the payment app. This may be a simple standard field which contains some text that all payment apps can display to the user.

Payment apps/methods can depend on this being provided and use it if they wish. Example, a payment method may require that this is digitally signed/timestamped and returned in the response.

[triblondon]

I'd lean the other way, for exactly the reason you outline about what payment apps know about the payment methods they administer. As a user I do not want a merchant I don't know well to explain the nature of the obligation to me.

An example scenario is where an apparently one off payment becomes a subscription on the sly. The ringtone industry was infamous for this - buy some ringtone of the moment for $5, but maybe you don't read the small print about how you're signing up to get a new hot ringtone pushed to your phone weekly for $5 a time.

I certainly don't mean to raise concerns to the level of removing recurring payments from scope though! Recurring payments are vital to a huge number of online merchants.

[adrianba]

@halindrome wrote: "I thought our position as a group was that Ts&Cs were to be handled by the merchant prior to calling payment request."

I agree with this position and recommend closing this issue.

[adrianhopebailie]

This issue is not about Ts&Cs.

There is a need to prompt the user when they are at the moment of authorizing the payment with a message that states clearly what they are authorizing and what they are getting in return.

In ISO20022 parlance this is the "obligation" that backs the payment. In many jurisdictions the way this is presented and agreed by the user is defined in law and we need to ensure we accommodate those local requirements.

We can punt this by making it the job of the payment app to figure out what to prompt the user but that prompt is likely to be lacking context without some input from the payee. i.e. "Authorize a recurring $5 payment to XYZ" isn't as good as "Authorize a recurring $5 payment to XYZ for weekly delivery of ABC".

It sounds like the consensus is to punt this pending further feedback so I will drop the priority down to low and mark it as a PostponedFeature.

[marcoscaceres]

I think we should close this. Leave it to the site. This is not something we want to handle in the browser UI.

[ianbjacobs]

@adrianhopebailie, can we close this issue?

[adrianhopebailie]

I think this is being dealt with in the secure payment confirmation experiment. Happy to close