Good write up, but it's rather rudimentary.<p>For people interested in FinTech/Payments, here's a great compendium and resources for the field: <a href="https://fintechgtm.substack.com/p/us-fintech-and-payments-crash-course" rel="nofollow">https://fintechgtm.substack.com/p/us-fintech-and-payments-cr...</a><p>I would also recommend the three books highlighted:<p>* Field Guide to Global Payments<p>* Anatomy of a Swipe<p>* Payment Systems in the US
Good, but missing some basic concepts:<p>- 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<p>....and alot more
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.<p><a href="https://amzn.to/447BLVI" rel="nofollow">https://amzn.to/447BLVI</a>
Nice share. It gives me an idea...<p>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.
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.
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?
> a Non-PCI compliant merchant's website cannot directly accept the card data from the user (on the frontend user interface)<p>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.<p>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.
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.