RC W2D3 - Payments and chargebacks

For non-technical talks, I presented on payments and chargebacks. In the spirit of the talk being non-technical, I left out the parts on the software stack and ML models (perhaps for a different post). The write-up below is roughly what I talked about.

When we think about a transaction, we think about a buyer making a payment in exchange for goods or services from the seller. To start off, let’s think about the payment in cash [1].

The cash model keeps things simple. However it does the require the buyer having cash on hand, and more importantly, the buyer may not yet have enough cash. This is where credit cards come in, making things convenient by solving the portability and credit issues.

With credit cards, we’re now looking at more parties to the transaction. There is the credit card issuer, often referred to as the issuing bank. The funds now need to go to the merchant’s bank, also known as the acquiring bank. Finally we need an intermediary to go between the two banks, and in the spirit of keeping things simple, we’ll think of it as a single party called the payments processor [2].

More parties means more fees. Let’s say 3% is taken out of the payment, so the seller gets 97 cents on every dollar. Most of that (roughtly two-thirds) goes to the issuing bank.

The convenience also comes at the cost of potential fraud. A fraudster with stolen credit card details may cash out by pretending to be a legitimate seller and 'cashes out' by processing stolen card details as a legitimate sale i.e. seller fraud. The fraudster may also pretend to be a legitimate buyer and purchase goods/services from a legitimate seller i.e. buyer fraud. Another possibility is by compromising the seller’s account and redirecting the funds to the fraudster’s bank account i.e. account takeover.

The payments processor may also be on the hook for a well-intentioned but poorly-run business by the seller. Imagine the seller selling concert tickets but unable to organize the concert. The buyers may reverse the transaction but the seller may be out of funds. Here the payments processor ‘fronts’ the payments to the seller, essentially taking on the credit risk.

The reversal request by the buyer is referred to as a chargeback. In fact often it's less of a reversal, but more of a 'mini court-case' called a dispute to decide which party should be on the hook. The issuing bank asks the buyer for more details, then the acquiring bank asks the seller for more details, and finally the determination be made (who decides often depends on the type of dispute).

For a finer breakdown of the different parties and the respective transaction fees, the Bloomberg article here has an excellent graphic. Modern Treasury has a great resource here. I enjoy reading Patrick McKenzie’s Bits about Money newsletter, and more recently listened to the Driven by Insight podcast interview with Alex Rampell. For chargebacks, Square has a Chargebacks 101 here.


[1] You can swap out the payment and/or the goods/services for the promise of payment/delivery, but there has to be a two-way exchange.

[2] This abstracts away the merchant services provider, payments gateway, etc