[HN Gopher] Payments 101 for a Developer
___________________________________________________________________
Payments 101 for a Developer
Author : manojr13
Score : 202 points
Date : 2023-04-26 14:26 UTC (8 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| arvindnata123 wrote:
| Can acquirers be non bank entities as?
| Nars088 wrote:
| Yeah they can be. For example, Fiserv is an acquirer
| yeouch wrote:
| 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 wrote:
| Both Stripe and PayPal are payments processors.
| davnicwil wrote:
| > 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 wrote:
| So if your frontend is using SSR, you can't accept card data?
| davnicwil wrote:
| 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.
| Nars088 wrote:
| In that case I think it is just slightly more convenient to
| render a PCI compliant entity's frontend as an iframe
| inside your application and have it send the details
| directly to the processor's server, perhaps saves one
| additional hop
| davnicwil wrote:
| Could be, I guess the downside of this is that you don't
| get full control of the UI which is a problem for some
| products. Depends on the tradeoffs I guess.
|
| In general I am a fan of just using things like Stripe
| Checkout though - it's not just about compliance but also
| just the complexity of getting the frontend part right
| with the myriad different payment flows, errors, and
| other subtle details that exist.
|
| But my original comment was more just clearing up
| confusion that you can absolutely do the frontend UI
| customly if you want to - there's no issue with this and
| PCI compliance, that only kicks in once the data goes to
| your server.
| Nars088 wrote:
| Yes that makes sense.
|
| Have you considered using Stripe Elements? It has loads
| of customization options that you can configure using an
| appearance API
| cat-whisperer wrote:
| This is a good overview but its high level, are there any other
| resources to understand payment flows for individual payment
| methods better?
| Johnie wrote:
| I've linked one here:
| https://news.ycombinator.com/item?id=35717604 It is VERY
| comprehensive.
| tibbon wrote:
| 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 wrote:
| How generic is that? Is it relevant to someone who deals mostly
| with stuff within EU?
| Scubabear68 wrote:
| 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 wrote:
| Absolutely. Just trying to tame such devils using open source
| and community as the tools
| game_the0ry wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Yes. The devil is in the details. Small businesses should
| better opt for a merchant on record who can manage all such
| complexity.
| thunkshift1 wrote:
| It exists in India; it is built and works pretty well. Its
| called 'UPI' Unified Payments Interface
| manojr13 wrote:
| Fednow has the potential to create a similar UPI like impact
| on US
| dzikimarian wrote:
| 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 wrote:
| What if network tokenization becomes more mainstream? If that
| happens browsers would't be able to vault users' card details
| dzikimarian wrote:
| 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 wrote:
| That would be a payments switch like https://hyperswitch.io/
| kyrra wrote:
| 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).
| koromak wrote:
| I'd guess Stripe and PayPal are quite happy with the current
| vendor lock-in
| Nars088 wrote:
| 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
| simpsond wrote:
| 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 wrote:
| 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
| bndw wrote:
| There is, it's called the Bitcoin Lightning Network.
| jagan120 wrote:
| India implemented this :
| https://en.wikipedia.org/wiki/Unified_Payments_Interface
| rodolphoarruda wrote:
| 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).
| m_sahaf wrote:
| Bolt has an open source Go package that tries to do that:
| https://github.com/BoltApp/sleet
| robertpohl wrote:
| 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
| [deleted]
| manojr13 wrote:
| Thanks. Too many details make the developers run away from the
| 101 class ;-)
|
| But will definitely cover tm in 102
| rupalsaini wrote:
| Nice share
| manojr13 wrote:
| Thanks for the feedback
| rowls66 wrote:
| A better description would be "Card Payments 101 for a
| Developer". There is more to payments than just cards.
| manojr13 wrote:
| 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
| pc86 wrote:
| 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.
| wiseowise wrote:
| Is there something like that, but for EMV/POS?
| Johnie wrote:
| 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
| manojr13 wrote:
| Great resources. Thanks.
| rodolphoarruda wrote:
| 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 wrote:
| It is indeed explained through eight steps in the second half
| of the article
| Nars088 wrote:
| Okay this is a very comprehensive explainer and we keep coming
| back to this (I'm a contributor)
| gen_greyface wrote:
| missed a disclaimer?
| manojr13 wrote:
| What would that be?
| gen_greyface wrote:
| that the commenter is associated with the project.
| kevviiinn wrote:
| Why does that require a disclaimer? Also, unless they
| edited their comment, they mention that they're a
| contributor
| SkyPuncher wrote:
| It's etiquette (maybe even a rule?) to clearly state when
| you have a relationship with something you're commenting
| on.
| hiatus wrote:
| They edited their comment.
| hencq wrote:
| In that case that would be a disclosure. A disclaimer
| warns the reader that they might not know what they're
| talking about, which is the opposite of what's intended
| here.
| hiatus wrote:
| Indeed, they posted about this project previously:
| https://news.ycombinator.com/item?id=35537675
___________________________________________________________________
(page generated 2023-04-26 23:02 UTC)