Re: [w3c/payment-handler] Open Window Algorithm and tracking through 1ps (#351)

The following example of a VRP (Variable Recurring Payment) for a Saturn-based phone-subscription request, highlights another limitation of the current approach to payment handlers.  VRP is also a part of future Open Banking APIs.
```json
{
  "amount": "360.00",
  "currency": "EUR",
  "nonDirectPayment": {
    "type": "RECURRING",
    "interval": "MONTHLY",
    "fixed": false,
    "expires": "2022-04-13T00:00:00Z"
  },
  "referenceId": "754329",
  "timeStamp": "2020-04-12T06:04:12Z",
  "expires": "2020-04-12T06:35:00Z"
}
```
To cope with this scenario, Saturn only uses `PaymentRequest` as a bridging mechanism.

Of course you can deal with VRP outside of `PaymentRequest` but then you lose the ability creating a [more] complete User authorization object and associated UI.  The € 360 is the upfront fee, not the total so the finalized authorization may also be subjected to a User credit score evaluation.

This specification talks about "fake" payments so I'm in "good company" 😇
https://github.com/adrianhopebailie/modal-window/blob/master/explainer.md#payment-handler-api


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/payment-handler/issues/351#issuecomment-613832700