Payments 101 for a Developer

[Johnie]

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

[RheingoldRiver]

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)

[manojr13]

Great resources. Thanks.

[robertpohl]

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

[manojr13]

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

But will definitely cover tm in 102

[tibbon]

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]

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

[game_the0ry]

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.

[kyrra]

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).

[jagan120]

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

[koromak]

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

[dzikimarian]

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.

[thedangler]

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.

[manojr13]

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

[scarface74]

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).

[m_sahaf]

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

[simpsond]

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

[alexanderscott]

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

API + unified card tokenization

[rodolphoarruda]

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).

[thunkshift1]

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

[bndw]

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

[Scubabear68]

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.

[manojr13]

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

[yeouch]

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?

[JoBrad]

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

[zeroxfe]

Both Stripe and PayPal are payments processors.

[rowls66]

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

[pc86]

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.

[manojr13]

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

[cat-whisperer]

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

[Johnie]

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

[davnicwil]

> 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.

[JoBrad]

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

[JLCarveth]

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

[rodolphoarruda]

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.

[manojr13]

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

[wiseowise]

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

[arvindnata123]

Can acquirers be non bank entities as?

[Nars088]

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

[Nars088]

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

[gen_greyface]

missed a disclaimer?

[rupalsaini]

Nice share