Decouple payments from session

https://github.com/interledger/webmonetization.org/issues/45 introduces the idea of web monetization payments that are decoupled from a particular session on a website. The website is pointed to a resource at the receiver (via the provider id) where the website can verify that a payment has been received. However, the payment(s) could have happened at any point in time, not necessarily during the current session.

This brings into question the necessity of the current monetizationstart and monetizationprogress events. Why does a website need to know when in-session payments have started and at what increments and amounts they are happening if (a) there’s more than enough already paid to the website to unlock content and (b) the in-session paid amounts can be used to fund unlocking content in future sessions? They could help inform payment verification retry logic if there wasn’t a sufficient existing paid amount. However, the events themselves aren’t guaranteed to represent actual payments, so a website could just retry at a frequency of its own choosing.

If we were to determine the events aren’t needed, web monetization could be reduced to the following:

1. The website creates a PaymentRequest when the page loads with the monetization method and payment pointer. The amount could be zero since it doesn’t matter.
2. The single PaymentRequest event is handled by a registered monetization payment handler, which both determines how much to pay and triggers payments (potentially throughout the entire session).
3. The payment handler returns a PaymentResponse (either immediately or after starting payment, perhaps depending on if there’s a previously paid amount), which includes the monetization/provider ID (and JWT authorizing the user to be able to spend against the provider’s paid amount).
4. The website can spend against the paid amount for the ID at the receiver to unlock content throughout the session. If payment verification fails, the website could optionally create a new PaymentRequest with the amount it is attempting to charge. (The subsequent PaymentResponse would be as useful for retrying as monetizationprogress is today.)

If we were to replace websites' monetization meta/link tag with the PaymentRequest, then I think web monetization could be fully supported by the PaymentRequest and PaymentHandler APIs without needing any additional functionality within browsers.

Start with issue #45 and compare its decoupled-payment idea with the current monetizationstart and monetizationprogress events. Evaluate whether the proposed PaymentRequest/PaymentHandler flow and provider ID/JWT verification cover session and future-session unlocking; done means a documented decision on whether the events and monetization tag are still needed.