Re: [webpayments] How can the API support enrollment (future payment) use cases? (#65)

I'm a big +1 to not carrying bad design into our API due to legacy of any underlying systems.
If we want to support various uses we should call them out as valid transaction types.

Payment apps and PSPs should deal with a payment request for a "reservation" or "enrollment" or "some payment type" and translate this into the appropriate set of parameters in their messages to the scheme/network.

Reply to this email directly or view it on GitHub:

Received on Monday, 15 February 2016 10:53:48 UTC