Payments 101 for a Developer

https://github.com/juspay/hyperswitch/wiki/Payments-101-for-a-Developer

by manojr13 • 3 years ago

284 72 3 years ago

github.com

Nars0886• 3 years ago

Okay this is a very comprehensive explainer and we keep coming back to this (I'm a contributor)

gen_greyface2• 3 years ago

missed a disclaimer?

manojr1310• 3 years ago

What would that be?

Scubabear68• 3 years ago

Not bad, but this is very high level. In Payments, the devil is in the details. Things like tokenization, security authorization, fraud detection, various kinds of payments rails, recurring payments, cross border payments, etc often matter.

manojr1310• 3 years ago

Absolutely. Just trying to tame such devils using open source and community as the tools

robertpohl• 3 years ago

Good, but missing some basic concepts:

- void, a refund on authorization - account verification, used to store a card, without authorization - card on file, a stored card - BIN, bank identification number - POS, a payment in store, physical terminal - card not present, payment from distance (ecom, moto) - moto, mail order, telephone order

....and alot more

manojr1310• 3 years ago

Thanks. Too many details make the developers run away from the 101 class ;-)

But will definitely cover tm in 102

tibbon• 3 years ago

I dig this as a quick intro. I've worked directly with payments at several orgs now, and yet didn't really grok payments until I read Payments Systems in the U.S. - Third Edition: A Guide for the Payments Professional. Afterward, I was actually able to understand how the pieces fit together. It is concise, and highly recommended to anyone working with payment systems.

https://amzn.to/447BLVI

krick• 3 years ago

How generic is that? Is it relevant to someone who deals mostly with stuff within EU?

game_the0ry2• 3 years ago

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• 3 years 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• 3 years 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.

jagan120• 3 years ago

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

koromak• 3 years ago

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

Nars0886• 3 years 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

kyrra2• 3 years 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_the0ry2• 3 years ago

My friend, do you not realize you make my case? :D

m_sahaf• 3 years ago

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

bndw• 3 years ago

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

thunkshift1• 3 years ago

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

manojr1310• 3 years ago

Fednow has the potential to create a similar UPI like impact on US

rodolphoarruda2• 3 years 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).

dzikimarian2• 3 years ago

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.

Nars0886• 3 years ago

What if network tokenization becomes more mainstream? If that happens browsers would't be able to vault users' card details

manojr1310• 3 years ago

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

simpsond• 3 years 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• 3 years 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• 3 years 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• 3 years ago

There is for the platform.

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• 3 years ago

kind of like spreedly https://www.spreedly.com/

API + unified card tokenization

rowls662• 3 years ago

A better description would be "Card Payments 101 for a Developer". There is more to payments than just cards.

pc86• 3 years ago

An even better one might be "Card Payments 101" as I don't think anything here is specific to software or developers, even at a high level.

manojr1310• 3 years ago

Agree. But covered cards because it is the most complex form of payment with a lot of intermediaries. So understanding the longest path, will help to prepare as developer for payments industry

rowls662• 3 years ago

Disagree there. I think that international wires are probably the most complicated.

wiseowise• 3 years ago

Is there something like that, but for EMV/POS?

Johnie2• 3 years ago

Good write up, but it's rather rudimentary.

For people interested in FinTech/Payments, here's a great compendium and resources for the field: https://fintechgtm.substack.com/p/us-fintech-and-payments-cr...

I would also recommend the three books highlighted:

* Field Guide to Global Payments

* Anatomy of a Swipe

* Payment Systems in the US

manojr1310• 3 years ago

Great resources. Thanks.

RheingoldRiver• 3 years ago

a topic I had no idea I was casually interested in & wanted to read books about despite the fact that I have no plans to work in this sector, my favorite (not sarcastic at all)

rupalsaini• 3 years ago

Nice share

manojr1310• 3 years ago

Thanks for the feedback

rodolphoarruda2• 3 years ago

I would prefer to see a process based approach to a terminology approach. Since payments are transactions, it would be better understood if explained in the form of steps.

manojr1310• 3 years ago

It is indeed explained through eight steps in the second half of the article

cat-whisperer• 3 years ago

This is a good overview but its high level, are there any other resources to understand payment flows for individual payment methods better?

Johnie2• 3 years ago

I've linked one here: https://news.ycombinator.com/item?id=35717604 It is VERY comprehensive.

yeouch• 3 years ago

I was under the assumption that Stripe, PayPal, Square, etc are not payment processors but either payment facilitators or payment gateways (depending on the platform) in that they don't actual process the payments but rather provide a convenient PCI-compliant way of moving the transactions to the actual payment processor (Something like NCR, GlobalPay, Elvaon, etc). In Stripe's case in particular I thought they were a payment facilitator and as a payment facilitator they board you as a sub-merchant which makes the process of getting an MID easier. Is that right or does Stripe actually process payments?

zeroxfe• 3 years ago

Both Stripe and PayPal are payments processors.

JoBrad5• 3 years ago

Stripe is a Payment Facilitator, and they pioneered the modern PayFac model. That’s one of the reasons that the word Stripe appears on your credit card statement when you pay someone that is using Stripe. Additionally it means they front the risk of accepting payments on your behalf. They are also a payment processor. Those aren’t exclusive operating models, at least in the US.

https://stripe.com/payment-facilitation https://stripe.com/guides/payfacs

davnicwil5• 3 years ago

a Non-PCI compliant merchant's website cannot directly accept the card data from the user (on the frontend user interface)

This needs rewording, I am not sure if they're trying to make a subtler point but on the surface this is not correct - you can of course accept card data from the user in your frontend and then send it to e.g. a Stripe-like PCI compliant service directly without it ever touching your servers.

The point is it must not touch your servers. This might be the subtlety in the wording here - the differentiation of frontend and backend and user interface. As long as 'the frontend' runs only in the user's browser, it is completely fine.

JLCarveth• 3 years ago

So if your frontend is using SSR, you can't accept card data?

davnicwil5• 3 years ago

As long as the frontend sends the card details only directly back to the PCI compliant service's servers, you are fine. This can still be done if your frontend is server rendered -- the data isn't there yet when you server render the form.

What I believe you can't do is have your own frontend send the data in the form to your own backend, then forward on to the other service from there. Once the plaintext card details touch your servers you have to be PCI compliant, even if you aren't storing them.

If you absolutely can't do the former on your frontend, eg because you don't want to use JS or something similar, then you can use services like Stripe checkout where they host the frontend on a URL you redirect to from your app, etc.

JoBrad5• 3 years ago

The key words are “directly accept”. If you use a properly implemented hosted payment page, your systems don’t touch the card data.

davnicwil5• 3 years ago

There is a distinction between the frontend user interface running locally in the user's browser and the backend code running on your server.

It's possible to 'accept' user input of card details in a frontend that you build and host, so long as you do not submit that data to a server you control -- you instead submit it directly from your frontend to a third party service that is PCI compliant.

arvindnata123• 3 years ago

Can acquirers be non bank entities as?

Nars0886• 3 years ago

Yeah they can be. For example, Fiserv is an acquirer

Payments 101 for a Developer

Related Stories