Re:Payment Request API
by ahopebailie on Monday March 02, 2020 @12:56PM
(#22466859)
My expectation is that the PSPs will help to hide the complexity from merchants that don't have the resources to use the (admittedly complex) API directly.
e.g. Stripe already have support for PR API in their SDK
Re:Payment Request API
by NoInputSignal on Monday March 02, 2020 @12:17PM
(#22466397)
I think you are on the right track, but I would say that any payment that requires banks or card providers (or both) to act as agents of the exchange will ultimately have these qualities. It doesn't matter if you wrap it in a pretty bow and call it a clever name.
I think this is where crypto currency shines, as it doesn't require a deep stack of agents to facilitate a payments. It requires two parties (maybe a third for escrow), and money can move with less friction.
Is there a synchronous abstraction for payments? So basically the user would submit a JSON object with the payment information and get a single atomic approve/deny response that is final?
If so, then I'd like to see a wrapper for this that encapsulates all of the async minutia into a sync protocol.
If not, then I think that reveals the underlying complexity of payment handling which is due to its asynchronous nature. There are so many reasons for payments to be rejected, returned or fail outright that perhaps nobody gets it all right. In the end, somebody has to moderate it and make it a manual process at some level.
So that's the part that that I'd like to see someone solve, regardless of the interface. Maybe Stripe or Square already have? Sorry if I'm using the wrong terminology here, I haven't done much merchant stuff, but have a nose for the fundamentals that make these types of things complex.