How hard would it be for all the PSPs out there to standardize on one API, maintaining of course the ability to add proprietary extension to it? There's a shitload of the most boring work on Earth to do for integrating with each... I remember using the PayPal api time ago and even that was hell... and no matter how good an API is designed, it's still hell because it's another one to integrate with... Can't we make something like w3c for payment systems?
If an existing provider's API became the standard, the other providers would rightly complain. If a standard were made from whole cloth, then, you know: http://xkcd.com/927/
As always, xkcd is right :) ...but there's a difference between "no standard" and "one standard for each implementation", subtle as it may be. Nobody will adopt a competitor's standard, so there has to be a common standard pushed from the outside.
I don't think we want that. There is a lot of innovation going on in payment API's right now, and the competition is what is driving it. That makes it easier for everyone.
I don't think that "a lot of innovation" is what's needed here. To me it seems more like a "do it once and do it RIGHT" kind of problem, and I think that getting a bunch of very smart people to work on it would produce a solution that could just work for 90% of cases for the next ~10 years, which is enough time to review the standard and so on. This is not something to "innovate and evolve", it's something that you "get it 90% right" (and have the proprietary extensions for the rest 10% of use-cases)! This "innovation" is sucking resources that could be better used at something else that's less incredibly boring... hell, I'd even love to see a government funded payment systems api that would later grow into a world standard, as bad as it may be, and be adopted by the banks and integrated directly with their systems putting all the "new wave" fancy PSPs out there out of business (then again, the bank's dinosaurs will most likely never move to "force this into being", so it's not gonna happen).
the ACH network gained widespread adoption when the gov't pushed a new banking standard down to ensure electronic disbursement of social security payments could be made. In this way ACH is a government sponsored payment infrastructure with it's own standard. The standard is actively managed by a gov't agency (the Fed/NACHA). But ACH leaves much to be desired, which is why proprietary payment networks (VISA/MC/AMEX, PayPal, inter-bank non-ACH transfers) have been developed. I'm doubtful that the gov't again pushing a standard, even one that's as widely adopted as ACH, would be able to keep up with the changing demands of the market. We tried this already and it didn't work, but maybe I'm just being cynical.
Comments
How hard would it be for all the PSPs out there to standardize on one API, maintaining of course the ability to add proprietary extension to it? There's a shitload of the most boring work on Earth to do for integrating with each... I remember using the PayPal api time ago and even that was hell... and no matter how good an API is designed, it's still hell because it's another one to integrate with... Can't we make something like w3c for payment systems?
If an existing provider's API became the standard, the other providers would rightly complain. If a standard were made from whole cloth, then, you know: http://xkcd.com/927/
As always, xkcd is right :) ...but there's a difference between "no standard" and "one standard for each implementation", subtle as it may be. Nobody will adopt a competitor's standard, so there has to be a common standard pushed from the outside.
Payswarm is a w3c affiliated universal payment standard. It hasn't taken off yet, but is a pretty compelling concept.
http://payswarm.com/ http://www.w3.org/community/webpayments/
I don't think we want that. There is a lot of innovation going on in payment API's right now, and the competition is what is driving it. That makes it easier for everyone.
I don't think that "a lot of innovation" is what's needed here. To me it seems more like a "do it once and do it RIGHT" kind of problem, and I think that getting a bunch of very smart people to work on it would produce a solution that could just work for 90% of cases for the next ~10 years, which is enough time to review the standard and so on. This is not something to "innovate and evolve", it's something that you "get it 90% right" (and have the proprietary extensions for the rest 10% of use-cases)! This "innovation" is sucking resources that could be better used at something else that's less incredibly boring... hell, I'd even love to see a government funded payment systems api that would later grow into a world standard, as bad as it may be, and be adopted by the banks and integrated directly with their systems putting all the "new wave" fancy PSPs out there out of business (then again, the bank's dinosaurs will most likely never move to "force this into being", so it's not gonna happen).
the ACH network gained widespread adoption when the gov't pushed a new banking standard down to ensure electronic disbursement of social security payments could be made. In this way ACH is a government sponsored payment infrastructure with it's own standard. The standard is actively managed by a gov't agency (the Fed/NACHA). But ACH leaves much to be desired, which is why proprietary payment networks (VISA/MC/AMEX, PayPal, inter-bank non-ACH transfers) have been developed. I'm doubtful that the gov't again pushing a standard, even one that's as widely adopted as ACH, would be able to keep up with the changing demands of the market. We tried this already and it didn't work, but maybe I'm just being cynical.