Is tracking payment request state necessary?

[msporny]

The paymentRequest API tracks the payment request state:

http://wicg.github.io/paymentrequest/specs/paymentrequest.html#paymentrequest-interface

enum PaymentRequestState {
    "created",
    "interactive",
    "delegated",
    "accepted",
    "closed"
};

The Web Payments CG Browser API proposal does not:

http://wicg.github.io/web-payments-browser-api/#processing-a-payment-request

Should we report payment request state back to the payee and enable the payee site to react as the payer proceeds through the payment flow? Or should we avoid exposing this level of detail in an effort to reduce the cognitive overhead for the developers (simpler API) and implementation complexity for the API (easier to implement for browser manufacturers)? In short, what are the use cases for reporting the payment request state back to the payee?

[dlongley]

-1 to reporting back state information if we can avoid it. I'd rather see lower-level APIs that the payee site can compose in a way that works for their flow.

[adrianhopebailie]

This is being addressed in the proposal at #64.

[msporny]

Closing issue, as this was resolved in favor of removing state in proposal #64.