So a project would use omnipay and then select what processors they want their clients to be able to use. Clients bring their own API keys or OAuth.

I believe it's in PHP and Ruby.

Unfortunately none of them worked for me, because PayPal (the only one usable in my country) has been unusable. One of the big reasons is because the only bank that supports them in my country can't create a usable online profile.

But even with PayPal itself, they think I haven't confirmed my email address when I have. Although I stopped getting those emails, so perhaps the situation resolved itself.

I'm going with Lemon Squeezy now.

The lesson I have learnt in this ordeal is that you need to confirm, as much as possible, that the payment provider is usable for you. Are you approved? Are payouts accepted in your country? Tick every single box you can before you write a single line of code for a specific payment provider.

You have all the different forms of payment that exist (credit card, banks, prepaid, ewallets, and even cash (reference number flows where the user takes a QR code into a store or kiosk, scans it, then pays in cash)). Then the details within those flows vary greatly by country/region. Credit cards have 3DS flows, plus CIT/MIT information. Banks want to do all kinds of 2FA, regularly they want the user to be redirected to their website to complete it. And on mobile, you could redirect to a bank or ewallet's app to confirm the payment. Then beyond that, you have various risk signals that different countries want to fight fraud. Some are lax, some are extremely invasive.

Once a payment has been initiated, knowing that it is Completed/Accepted can be really complicated. Credit cards, once you have an auth, a capture is all but guaranteed, but you still have chargebacks to deal with. ACH has a fuzzy window about when it can be reversed. Various other forms of payment have anti-fraud mechanisms that allow payments to be reversed with various windows about when that can happen.

You will always have various governments come in and force new rules that don't play nicely with whatever uniform API you create. For example, the Royal Bank of India forcing all storage of credit card numbers to happen within their country's boundries (data localization). This all of a sudden may force a flow that was using credit cards just fine to now require you to use tokens in their place.

It feels like the payments space should be easier than it is, but various regulations and security/privacy measures that change by region regularly will mess with such an API.

Edit: to add some more fun examples: it's also good to understand that some payment systems in the world are still very manual. There are people with spreadsheets that generate reports. So as a processor, you can get a response from a bank where 2 numbers are transposed in a report. Or you get reports where you aren't given a transaction_id, just a date and amount and you have to figure it out (see the UK's BACS DDICA reports).

I think you could build such an API, but there will be so many gotchyas with each special form of payment, it will be really difficult to use well. Knowing which fields to populate for a given form of payments starts getting more complicated, and dealing with the odd side-effects of each also start to multiply.

I think the processors out there (Adyen, Stripe, Worldpay, dLocal and others) do as well as they can given the ecosystem.

On paper it looks kinda nice. I've seen some discussion about implementing it from the payment method perspective.

Problem is that Google would be massively privileged, as browser orchestrates the process and payment methods aren't necessarily looking for the fair compromise either.

Also depends what do you mean by more mainstream. Google Pay and Apple Pay both support tokenization. So do many other payment methods - I would say that it's mainstream. Next step would be refusing plain cards at all.

Google Pay is everything that Google needs for Chrome to have full solution.

- Normalized money transfers independent of the regular financial system

- Reducing currency interchange fees

Bitcoin was suppose to be this electronic ledger store for valuation to facilitate these things, as I recall.

Really got away from itself

https://developer.mozilla.org/en-US/docs/Web/API/Payment_Req...

It works on Safari/iOS/MacOS and Chrome/Android (but weirdly enough, Firefox doesn’t support it).

API + unified card tokenization