13 ms·
Payments 101 for a Developer
- Nars088 3y agoOkay this is a very comprehensive explainer and we keep coming back to this (I'm a contributor)
- gen_greyface 3y agomissed a disclaimer?
- manojr13 3y agoWhat would that be?
- gen_greyface 3y agothat the commenter is associated with the project.
- hiatus 3y agoIndeed, they posted about this project previously: https://news.ycombinator.com/item?id=35537675 https://news.ycombinator.com/item?id=35537675
- kevviiinn 3y agoWhy does that require a disclaimer? Also, unless they edited their comment, they mention that they're a contributor
- hiatus 3y agoThey edited their comment.
- SkyPuncher 3y agoIt's etiquette (maybe even a rule?) to clearly state when you have a relationship with something you're commenting on.
- hencq 3y agoIn 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.
- Scubabear68 3y agoNot 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 3y agoAbsolutely. Just trying to tame such devils using open source and community as the tools
- robertpohl 3y agoGood, 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 3y ago[deleted]
- manojr13 3y agoThanks. Too many details make the developers run away from the 101 class ;-) But will definitely cover tm in 102
- tibbon 3y agoI 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 https://amzn.to/447BLVI
- krick 3y agoHow generic is that? Is it relevant to someone who deals mostly with stuff within EU?
- game_the0ry 3y agoNice 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 3y agoThere 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 3y agoChargebee 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 3y agoYes. The devil is in the details. Small businesses should better opt for a merchant on record who can manage all such complexity.
- jagan120 3y agoIndia implemented this : https://en.wikipedia.org/wiki/Unified_Payments_Interface https://en.wikipedia.org/wiki/Unified_Payments_Interface
- rowls66 3y agoA better description would be "Card Payments 101 for a Developer". There is more to payments than just cards.
- pc86 3y agoAn 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 3y agoAgree. 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
- rowls66 3y agoDisagree there. I think that international wires are probably the most complicated.
- wiseowise 3y agoIs there something like that, but for EMV/POS?
- Johnie 3y agoGood 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-crash-course 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 3y agoGreat resources. Thanks.
- RheingoldRiver 3y agoa 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 3y agoNice share
- manojr13 3y agoThanks for the feedback
- rodolphoarruda 3y agoI 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 3y agoIt is indeed explained through eight steps in the second half of the article
- cat-whisperer 3y agoThis is a good overview but its high level, are there any other resources to understand payment flows for individual payment methods better?
- Johnie 3y agoI've linked one here: https://news.ycombinator.com/item?id=35717604 https://news.ycombinator.com/item?id=35717604 It is VERY comprehensive.
- yeouch 3y agoI 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 3y agoBoth Stripe and PayPal are payments processors.
- JoBrad 3y agoStripe 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/payment-facilitation https://stripe.com/guides/payfacs https://stripe.com/guides/payfacs
- davnicwil 3y 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 3y agoSo if your frontend is using SSR, you can't accept card data?
- davnicwil 3y agoAs 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.
- arvindnata123 3y agoCan acquirers be non bank entities as?
- Nars088 3y agoYeah they can be. For example, Fiserv is an acquirer