02: Course Motivation and Overview

The purpose of this course is to teach you JavaScript by teaching you how to make professional websites that accept money from customers. This seems like a simple task, but weirdly not many programmers actually learn how to do this. I never learned how to do it in school or at any job I worked. I had to teach myself how to do something as "simple" as accepting credit cards online. For some bizarre reason, nobody really teaches how to accept money from people online, despite the importance of payments online.

The answer you get is usually, "Just use Stripe." Even with advanced payment processors like Stripe, Adyen, Alipay, and Paypal you still have a lot of complexity in your application. What kind of payments do you need? Subscription? One-time credit card? Is this a marketplace? How do you handle refunds? How do you confirm payment? No, seriously. Have you actually tried to confirm a payment? What happens if you miss a callback? What about credit card fraud? Did you know most of these payment companies do almost nothing to stop fraud? Did you know if you get hit with a charge back that you will have to pay $15-$30 to resolve it, and you might lose the original payment too?

Everyone thinks "just use Stripe" is simple, but there's many scenarios that sabotage that simplicity. Take "pay what you want" models as an example. Let's say you want to offer up your music to people and let them choose how much to pay. They can give you zero dollars, one dollar, or one-hundred dollars. Seems easy enough right? Oh, silly person, you haven't ran into carding.

Carding is where a hacker will buy a ton of stolen credit card numbers, usually gathered from a previous data hack. This person is called a "carder" and "carding" is where they take all of the cards and try to determine if any are still viable, and remove any credit cards that have been canceled. To do this they need to conduct a large scale series of test payments in some anonymous way. They hand out the batch of cards to a bunch of accomplices, and then those accomplices hit any online retailer that offers something for $1...like your music website with it's $1 "pay what you like" model.

They hit your site, try a ton of cards with charges for $1 each, and keep any that pass. Your seemingly friendly gesture is now being exploited to filter out canceled credit cards, and the worst part is, you have to pay for it, not Stripe. The real owner of the card will report this $1 charge as fraudulent, Stripe will then charge you $15 to handle it, and no, you can't just give the money back. Too late. You're now out $16, and if you get too many of these charges Stripe will cancel your account. Oh, did I mention that "too many" is arbitrary and based entirely on if Stripe likes you or not?

"But, Zed, doesn't Stripe do some kind of advanced fraud detection...." HAHAHAHAHAHAH. No. Maybe they do some now, but they make too much money on these carders and they know it. They leave it to you to stop the carders, and if you're a small shop you can't possibly defend yourself.

What's even more stupid about this is 95% of carding could be stopped if Stripe simply blocked charges where the computer making the charge is not located in the card owners country. When I stopped using Stripe all of my fraudulent charges fit the pattern of Zip code in the US, but from a computer in Europe, Africa, or Asia. All they'd have to do is stop any charge to a US card from those countries and they'd block most carding fraud. Narrow it down to the same US state and they'd do even better. Block Tor and I think that about covers it for most carding.

This is what I mean when I say that processing a credit card is not as easy as everyone thinks it is. The actual capturing of the card's money isn't the problem. It's all of the random tangential issues that happen before and after which make it an interesting problem, and a very practical basis for learning to code.