What is the value range for 'type' property in PaymentRequest?

[msporny]

A PaymentRequest currently has a type property that is typically set to "PaymentRequest".

The set of available types may be extended in the future to, for example, add things like "SubscriptionRequest" to identify payment requests that may have some recurring quality to them.

@adrianhopebailie has suggested the following:

PaymentRequest with the following extensions:

• RecurringPaymentRequest which extends Payment Request with extra rules about recurrence etc
• RefundRequest which extends Payment Request with reference to original payment
• PaymentAuthorizationRequest (not sure of the use case here)
• HoldRequest which extends the payment request by adding a data about when to release the hold (conditions, timeouts etc)

[adrianhopebailie]

@msporny : Actually I don't think PaymentRequest should be extended unless we can show that's the right way to address this use case.

These requests are not requests to be paid. They are requests to pay (in the case of a refund), prepare a payment (on hold) or establish a legal relationship which entitles the payee to process (not request) payments in future.

Also, as an example, if I want to request a subscription then I can't use the same payment methods as I would when asking for a payment. I probably can't use a true push based payment method at all (how would the payee get paid in future) and only certain pull based methods will support recurring payments.

For a recurring payment is it for an amount or an allowed range? Do you set limits per transaction or per time period?

Must a refund be matched with a previous payment somehow or is it just a credit (payment for a negative amount)?

In short, I don't think this is as simple this issue suggests.

Anything but a PaymentRequest is very payment method specific and is a request to create a complex legal relationship between the payer and payee.

We should design the request for a subscription, recurring payment etc independently and deal with all the complexity therein before we try to find a way to combine that with PaymentRequest in any way.

[msporny]

These requests are not requests to be paid. They are requests to pay (in the case of a refund), prepare a payment (on hold) or establish a legal relationship which entitles the payee to process (not request) payments in future.

Right, so does that mean that we need different APIs for them, or should the same API be able to route all these sorts of "requests for payment"? This is a question the group should come to grips with sooner than later as it affects the design of the system.

if I want to request a subscription then I can't use the same payment methods as I would when asking for a payment.

Well, not always, but sometimes. Cards are a good example here, anything from the Basic Card spec would probably work for most subscriptions these days. So, in that case, you can use the same payment methods to request a subscription as you do to make an immediate payment.

For a recurring payment is it for an amount or an allowed range?

Probably an allowed range.

Do you set limits per transaction or per time period?

Probably both. :)

Must a refund be matched with a previous payment somehow or is it just a credit (payment for a negative amount)?

I'd expect that it doesn't need to be matched (but it's nice if it is). I wouldn't expect it to be a credit for a negative amount (as we don't support negative values in our messages).

I don't think this is as simple this issue suggests.

I didn't mean to imply that this was a simple issue to resolve. That said, JSON-LD has this nice property of duck-typing, so you can set multiple types on a message and the world doesn't fall apart. Something can be both a Payment Request and a Subscription Request (if that makes sense to model it that way). This issue merely raises the question of: How is the WG going to model these different types of messages? As extensions of a basic message, or as different messages? Either approach raises more questions that we'll have to grapple with in time that most likely changes the design of the APIs (both browser and HTTP API).

Anything but a PaymentRequest is very payment method specific

I'm not convinced of this, yet.

We should design the request for a subscription, recurring payment etc independently and deal with all the complexity therein before we try to find a way to combine that with PaymentRequest in any way.

That's fine, we can go about designing this in a variety of different ways. My caution to the group is to take anything into CR before at least the design process is done.