7 ms·

Nice share. It gives me an idea... It would be cool if there was a unified payments API interface that payment providers (paypal, cashapp, stripe, ccbill, paym

Nice share. It gives me an idea... It would be cool if there was a unified payments API interface that payment providers (paypal, cashapp, stripe, ccbill, payment cloud, segpay, epoch, whatever) would agree to use. Hopefully, users would drive adoption, and feel free to swap providers. Also, platform agnostic (apple ios, android, web, etc). I dunno, just thinking out loud.

thedangler 4y ago
There is something like this omnipay its a framework that lets any payment processor (gateway ) integrate so you can switch processors. 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.
- jasfi 4y ago
  Chargebee support quite a few payment processors too. 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.
  - manojr13 4y ago
    Yes. The devil is in the details. Small businesses should better opt for a merchant on record who can manage all such complexity.
jagan120 4y ago
India implemented this : https://en.wikipedia.org/wiki/Unified_Payments_Interface https://en.wikipedia.org/wiki/Unified_Payments_Interface
koromak 4y ago
I'd guess Stripe and PayPal are quite happy with the current vendor lock-in
- Nars088 4y ago
  Yes but it is extremely risky for the business if Stripe or Paypal is its only processor. If for whatever reason your account is flagged by the processor, you wouldn't be able to accept payments
kyrra 4y ago
Building such a thing would be extremely difficult. When you start getting to the local level with banks, networks, and governments, there are all kinds of different things you have to deal with. 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).
- game_the0ry 4y ago
  My friend, do you not realize you make my case? :D
  - kyrra 4y ago
m_sahaf 4y ago
Bolt has an open source Go package that tries to do that: https://github.com/BoltApp/sleet https://github.com/BoltApp/sleet
bndw 4y ago
There is, it's called the Bitcoin Lightning Network.
thunkshift1 4y ago
It exists in India; it is built and works pretty well. Its called ‘UPI’ Unified Payments Interface
- manojr13 4y ago
  Fednow has the potential to create a similar UPI like impact on US
rodolphoarruda 4y ago
I had this idea once for a Wordpress plugin for Woocommerce websites. A plugin that would abstract all providers APIs to Woocommerce. Paid versions of the plugin would allow the merchant to work with several providers in parallel in order to reduce transaction fees (increasing the operational margin then).
dzikimarian 4y ago
https://www.w3.org/TR/payment-request/ https://www.w3.org/TR/payment-request/ 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.
- Nars088 4y ago
  What if network tokenization becomes more mainstream? If that happens browsers would't be able to vault users' card details
  - dzikimarian 4y ago
    I'm not sure if I fully understand your point. In this solution browser is not expected to vault card. It should just be intermediary between payment methods and payment gateways (of course saving card inside browser can be one of the payment methods). 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.
manojr13 4y ago
That would be a payments switch like https://hyperswitch.io/ https://hyperswitch.io/
simpsond 4y ago
That sounds like a protocol. It would be nice. Someone got downvoted for mentioning Bitcoin, but blockchains are protocols capable of transferring value.
- no_wizard 4y ago
  Honestly this was their initial promise when the community was super niche, it was two things: - 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
- albybisy 4y ago
  Stellar could be this open-network/protocol for transferring value. I don't see a lot of developers talking about it, but it's really really a good tool for this use case and i think it will be :)
scarface74 4y ago
There is for the platform. https://developer.mozilla.org/en-US/docs/Web/API/Payment_Request_API 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).
alexanderscott 4y ago
kind of like spreedly https://www.spreedly.com/ https://www.spreedly.com/ API + unified card tokenization

thedangler 4y ago

There is something like this omnipay its a framework that lets any payment processor (gateway ) integrate so you can switch processors. 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.

jasfi 4y ago
Chargebee support quite a few payment processors too. 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.
- manojr13 4y ago
  Yes. The devil is in the details. Small businesses should better opt for a merchant on record who can manage all such complexity.

jagan120 4y ago

India implemented this : https://en.wikipedia.org/wiki/Unified_Payments_Interface https://en.wikipedia.org/wiki/Unified_Payments_Interface

koromak 4y ago

I'd guess Stripe and PayPal are quite happy with the current vendor lock-in

Nars088 4y ago
Yes but it is extremely risky for the business if Stripe or Paypal is its only processor. If for whatever reason your account is flagged by the processor, you wouldn't be able to accept payments

kyrra 4y ago

Building such a thing would be extremely difficult. When you start getting to the local level with banks, networks, and governments, there are all kinds of different things you have to deal with. 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).

game_the0ry 4y ago
My friend, do you not realize you make my case? :D
- kyrra 4y ago

m_sahaf 4y ago

Bolt has an open source Go package that tries to do that: https://github.com/BoltApp/sleet https://github.com/BoltApp/sleet

bndw 4y ago

There is, it's called the Bitcoin Lightning Network.

thunkshift1 4y ago

It exists in India; it is built and works pretty well. Its called ‘UPI’ Unified Payments Interface

manojr13 4y ago
Fednow has the potential to create a similar UPI like impact on US

rodolphoarruda 4y ago

I had this idea once for a Wordpress plugin for Woocommerce websites. A plugin that would abstract all providers APIs to Woocommerce. Paid versions of the plugin would allow the merchant to work with several providers in parallel in order to reduce transaction fees (increasing the operational margin then).

dzikimarian 4y ago

https://www.w3.org/TR/payment-request/ https://www.w3.org/TR/payment-request/ 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.

Nars088 4y ago
What if network tokenization becomes more mainstream? If that happens browsers would't be able to vault users' card details
- dzikimarian 4y ago
  I'm not sure if I fully understand your point. In this solution browser is not expected to vault card. It should just be intermediary between payment methods and payment gateways (of course saving card inside browser can be one of the payment methods). 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.

manojr13 4y ago

That would be a payments switch like https://hyperswitch.io/ https://hyperswitch.io/

simpsond 4y ago

That sounds like a protocol. It would be nice. Someone got downvoted for mentioning Bitcoin, but blockchains are protocols capable of transferring value.

no_wizard 4y ago
Honestly this was their initial promise when the community was super niche, it was two things: - 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
albybisy 4y ago
Stellar could be this open-network/protocol for transferring value. I don't see a lot of developers talking about it, but it's really really a good tool for this use case and i think it will be :)

scarface74 4y ago

There is for the platform. https://developer.mozilla.org/en-US/docs/Web/API/Payment_Request_API 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).

alexanderscott 4y ago

kind of like spreedly https://www.spreedly.com/ https://www.spreedly.com/ API + unified card tokenization