Should the Web Payments API cater for the invoicing part of the full web purchase flow ?

[vkuntz]

Through web payments, the current usage does not provide a consistent approach for the provisioning of the invoice: together with the goods, by a confirmation email, embedded in order confirmation on the website. Should there be a consistent and harmonised approach, which would define specific requirements on the API. Additional considerations: from a legal point of view, the provision of an invoice might have different implications. How can a standard API support this.

[ianbjacobs]

Hi Vincent,

I'm not sure to understand the scenario you have in mind. Would you mind describing the flow you have in mind in a bit more detail? Thank you,

Ian

[adrianhopebailie]

I understand this requirement as a motivator to have a separate message and API specifications for the payment request.

So, while the payment request is not (in legal terms) an invoice, it is a piece of data that could be embedded in an email, sent via an API call or passed via any number of mechanisms to a debtor who can then attempt to make the payment.

I can imagine a QR code that is a URL pointing to the payment request (in the form of a JSON document) being printed on a receipt for example...

This will only work if the format is standardized and we explicitly choose to accommodate this use case and consider how the data schema needs to be designed to do so. (Example: If the payment request is embedded in an email it must provide a URL to which the debtor submits a response)

[msporny]

The way the Web Payments CG spec had handled this in the past is to provide an "invoice" data field that can point to a web page containing the invoice, or include the invoice directly in the data (where the format of that invoice is yet to be determined).

This approach enables you to link to an image of an invoice, an HTML page containing the invoice (with appropriate protection, if necessary), and a complete machine-readable invoice. There are varying degrees of legal enforceability for each of these options.

[ianbjacobs]

See the related question on the thread of issue #35: https://github.com/WICG/paymentrequest/issues/35#issuecomment-169778619

"what is the priority that the message data be designed to be reusable (meaningful, grounded, etc.) outside of the context of some API defined by the group?"

Ian

[vkuntz]

I like the approach as provided by Manu to have a link to the invoice, but it means that the web payments API must support this function. My question was on the harmonisation of the invoice processing. We need to ensure that invoices are always provided to the customer in the same way. Today, there are multiple approaches for the invoice delivery: stored in your web account after delivery, delivered by email, link to download the invoice, even delivered in paper copy with the goods. There are also some legal requirements: in many countries, the merchant must archive a copy of the invoice for several years (up to 10 years depending on the countries).

[adrianhopebailie]

Am I correct that what is being proposed is relevant to the data schema of the payment request only? i.e. The proposal is to have SOME mechanism to link a payment request to an invoice but not to define any invoice delivery mechanism.

Assuming this is a standard data element that we define in the payment request, do we go so far as to define what that data must look like, and if we say its a URL what that URL should point to?

I am inclined to say that standardizing anything more than a named data element in the request that could be of any type (URL, unique id), is going beyond our scope, although I'd like to hear other opinions on this.

[rsolomakhin]

For my sake as a non-native English speaker, let's define a couple of terms. It sounds like @vkuntz is talking about something like a receipt.

"A written or printed statement acknowledging that something has been paid for."

This is something that the merchant provides to the user after the transaction has been complete. I can imagine this happening through the complete() method:

var receipt = {"items": [...], "amount": "35.00", "currencyCode": "USD"};
payment.complete(true, receipt);

In contrast, an invoice is much closer to the definition of a payment request.

"A list of goods sent or services provided, with a statement of the sum due for these; a bill."

The browser has this information and may even store it. For example, this is similar to "Downloads" page in Chrome.

@vkuntz, which one did you have in mind?

[msporny]

Just as a reminder - invoices (before the payment request) and receipts (after the payment acknowledgement) are a really complex field - GS1 and NACS have a lot to say about receipts. FOCAFET/Quicken/etc. have a lot to say about invoices. There are standards for these things, so the likelyhood that we'll be able to define either in WebIDL is highly unlikely, placing the browser as a conduit for the real data (but not really touching it... just like many of the other payment messages passed through the browser).

If we're going to talk about invoices and receipts - we need a very good extensibility story there.

[ianbjacobs]

@adrianhopebailie,

I think we should establish:

• Is there a minimal merchant use case that we must address to get adoption of the API?
• If so, what's the minimal information required to achieve it?

For example, if merchants say to us something like "We can't use the API unless there's a way to associate an offer with a receipt" then we should listen carefully to that. While it is not in our scope to create standards for digital receipts, the merchant may need information to link two "events"; I think this is what you are saying and it sounds reasonable, but we need to ground it in merchant needs IMO.

Ian

[adrianhopebailie]

+1 on grounding with concrete requirements.

The payment request and response exchanged through the API are part of a larger commerce flow. We should have a minimal mechanism to allow the payer and payee to link these messages to that wider flow, either through some transaction reference or linked data.

The next question is, should this be standardized in the base request data model or is this something that should be left to each payment method to define in their custom data models?

[mattsaxon]

@vkuntz

In terms of a concrete proposal, are you asking that the Browser API allows for;

1. The display of the obligation in the Browser UI
2. The production of a cryptographically signed invoice and that includes the obligation by the API
3. The automated delivery of this invoice to the payer as part of the process – do you think the payment application should be responsible for this or perhaps the payment mediator, or is it acceptable to just pass this back from the API to the merchant and make the merchant responsible for providing it? Would that not make it more likely for lost invoices?

Does all of this apply for transactions that are just an “Authorisation”? When is the obligation and invoice needed as part of such a process and what happens if the authorisation time’s out?

[adrianhopebailie]

@vkuntz Are we addressing this appropriately in https://github.com/w3c/browser-payment-api/issues/113

[ianbjacobs]

Closing, but see SPC.