Re: Updates to Payment Apps wiki page

<snip>


> What kind if gateways are these? Examples? (I'm asking because I'm
> genuinely curious and do not have a lot of knowledge in this area).
>
>
In my experience the majority of payment gateways use a redirect or some
web API that the merchant POSTs a request to.

Many are now offering JavaScript APIs too as a response to the likes of
Stripe but note they all still offer HTTP APIs (often called REST APIs but
let's not get into a debate about what is or isn't REST :) ).

If I search for "<gateway> api" the first page I get is usually developer
docs for an HTTP API.

   - https://developer.paypal.com/docs/api/
   - https://stripe.com/docs/api
   - https://developer.visa.com/products/visa_checkout/reference



> I'm not super fond of the argument that we should limit ourselves so that
> some implementors will not have to learn anything new. I think we should
> strive to create the best payment specification we can, and in that
> process, use the technology that fits best.
>

That is not the crux of my argument. In fact my argument is the contrary,
If we limit our scope we are forced to make design decisions that only
cater to the PSPs that do have JavaScript APIs and force the rest to
implement something they may have no experience with.

That is a difficult thing to do. Consider how long it took many of the
biggest gateways to bring out a JavaScript SDK to compliment their existing
HTTP APIs after Stripe's phenomenal success with their JavaScript API. I
doubt that's was because they were simply disinterested, developing a new
JavaScript SDK is hard!

Most importantly, I believe that from a design perspective HTTP is the best
choice because it is a protocol not a language. If we standardize on a
language specific API then we limit ourselves to implementations in that
language. This is bad for interoperability.

If we design an API that standardizes around a protocol we allow
interoperability across process and network boundaries without forcing
implementers to maintain any code in a specific language.

While I respect that JavaScript is the de-facto standard language for
client side web programming it is not the standard for the Web. Most
server-side software is written in other languages.

If we standardize on sending the request via HTTP we can offer options for
the response (including JavaScript) that cater for all of the different
possible payment app implementations.


>
> On the flip side to your argument, a lot of payment providers already have
> javascript SDKs (like PayPal, Mastercard or Visa). Have a look here
> <https://people.opera.com/tommyt/pay.php> for a proof-of-concept
> web-based payment app I hacked together in an afternoon, which consists of
> just a few lines of javascript, wrapping the Visa Checkout payment system.
> For cases like this, the javascript approach makes it very easy to retrofit
> an existing payment solution.
>

This is true but only for the bigger PSPs. In the South African market for
example, I am only aware of 2 gateways, of the 10 or more in existence,
that have a JavaScript API.

For all of them, they have an HTTP API too.


>
> -Tommy
>
> </snip>