Re: [webpayments] How should the message schemas for the payment request and response be defined? (#27)

@ianbjacobs wrote:
> Do we have use cases where the data needs to live outside of the APIs we develop?

Yes, absolutely, here are a few from our use cases document (in the order that they appear):

https://www.w3.org/TR/web-payments-use-cases/#uc-pos-kiosk
https://www.w3.org/TR/web-payments-use-cases/#uc-email
https://www.w3.org/TR/web-payments-use-cases/#uc-machine-readability
https://www.w3.org/TR/web-payments-use-cases/#uc-vehicle

How will a kiosk present a machine-readable offer of sale? Certainly not only via a browser - in-store beacons, Bluetooth, NFC, are all possibilities here that require the "payment message / offer" to also exist outside of the browser environment. What extensible data model are we going to use to express offers? We can't go through and enumerate all of the bits that can be extended because by doing so, we're implicitly making the decision on which bits can't be extended.

https://www.w3.org/TR/web-payments-use-cases/#uc-subscription

How are the details of a subscription defined so that a software agent can remind you when a subscription is expiring? Certainly, a browsers isn't the only application that is going to do that subscription processing, is it? Don't we want to have a life agent that manages these subscriptions for us, reminding us when they're going to expire and auto-renewing them if we want to continue with the service? This data lives outside of the browser.

https://www.w3.org/TR/web-payments-use-cases/#uc-credentials

The Credentials CG work (along with 40+ organizations) are already well down the path of using JSON-LD because those messages /do/ live outside of the browser API and it's the only developer-friendly scalable mechanism. If our prediction is correct, and there will be significant interplay between the credentials and payments APIs in the future (loyalty card, coupons, proof of identity, etc.) then it would be good to align the data model and format of those messages with the payments messages. Both types of messages live outside of the browser API.

https://www.w3.org/TR/web-payments-use-cases/#uc-invoices

Invoices may be delivered/stored via the Payment API but processed via external software and systems like Quickbooks or Mint. We can't define what those invoices look like in the Web Payments WG, we have no idea what form they might take, but it's clear that there are certain corporate payment methods that would want to have invoices attached to payments, and where there payment messages would be archived outside of the browser for processing (via corporate accounting systems).

https://www.w3.org/TR/web-payments-use-cases/#uc-ubiquitous

We can't predict the way payment apps are expressed and some payment apps may include information in them that user agents may use in different ways. For example, some may take advantage of a secure element w/ a cryptogram/token embedded in the issued payment app description. This data may not live purely in the Browser API and may need to delegate some of the cryptogram data to a secure element or application (operating outside of the browser).

https://www.w3.org/TR/web-payments-use-cases/#uc-manual-selection

Websites could provide the payment instruments they accept as machine-readable data on a page before a purchase is started (they'll certainly do that for ecommerce offers). This would enable customers to narrow searches by the payment apps they want to use to make the purchase. This information would exist outside of the browser API.

https://www.w3.org/TR/web-payments-use-cases/#uc-kyc

KYC requirements vary from region to region, we can't specify every possibility in the WG and specifying this data should probably be undertaken by the regulators. A KYC credential may need to be attached to some payment messages and may be required to flow through the system, from the Browser API all the way to clearing and settlement (outside of the browser).

https://www.w3.org/TR/web-payments-use-cases/#uc-proofs

Proof of payments and proof of transaction would be included in the payment messages and would be sent to the merchant or PSP for processing. That is, most proofs would need to be transmitted outside of the Browser API to be processed by the merchant or PSP.

https://www.w3.org/TR/web-payments-use-cases/#uc-electronic-receipts

Some electronic receipts may be managed by the browser API but would eventually end up in a storage system deemed appropriate by the customer. navigator.payment.storeReceipt() would require the payment/receipt message to travel outside of the Browser API.

I hope this makes it clear that a number of the payment messages we are delivering will be affected by the use cases above and that those use cases clearly demonstrate that these payment messages will travel outside of the Browser API.

---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webpayments/issues/27#issuecomment-178737874