# Pull payments, credit, & schlep blindness 4/29/26 Direct Debit – through which your landlord pulls your rent, Amex pulls your statement payment, Fidelity funds your brokerage account, all from your bank account – relies on *credit* (ie. a "loan"). This isn't obvious on its face. Unlike eg. a credit card, I already *have* the money in the account being pulled *from*, and I don't need to *borrow* money from anyone. What "loan"?  **A scenario:** 1. Merchant charges – *pulls* funds from – their customer via ACH debit. 2. Their *bank* consistently *receives* those funds same-day or next-day, but will *hold* the funds -- until they're no longer worried about a potential dispute. That might be as soon as same-day or next-day; or eg. 3-5 business days later. 3. If the customer is a business, they have two business days to *dispute* this pull; if they're a consumer, they have sixty days. In certain cases, with sufficient documentation and reason, even longer. This happens via "ACH return." When the bank releases that "hold" and lets the merchant spend that money: the money has entered superposition. It's spendable by the merchant. But it's also *recallable* for a number of days by the sender (insufficient funds! wrong account! frozen account! unauthorized!). Squint at this and you see that there are two open claims to the same dollar. If both parties, both with a claim to the same dollar, decide to redeem that claim: the merchant's bank – the "acquirer" – is out of that money. They were extending credit to the merchant when they made that money spendable. If this happened -- if the merchant spent the funds, and the customer recalled them -- The bank would then "overdraw" the merchant's account – send it into the negative – which is the materialization of a balance the merchant now *owes* the bank. Cards are another mechanism subject to similar constraints. I started with an ACH debit example since cards are reflexively presumed to be credit-bearing. People also often steer this discussion in a way that superficially pits bank-to-bank transfers *against* credit cards; but I think they have in common their general reliance on credit *somewhere*. I'd make the case that "pull payments," (eg. ACH Direct Debit), the credit that *necessarily* backs them, and the utility that this credit represents; all are *dramatically* overlooked by most people who think the slow uptake of innovations like stablecoins or eg. RTP / FedNow is solely about inertia or miseducation. It's easy to characterize the (credit-heavy) status quo that crypto & realtime rails aspire to replace as rent-seeking. Or, as symptomatic of a pre-technological era. The case being made is less frequently "the thing these middlemen do could be done for cheaper," and more often "must we bother with the things that they do?" I think this is a form of [schlep blindness](https://www.paulgraham.com/schlep.html). > The most dangerous thing about our dislike of schleps is that much of it is unconscious. Your unconscious won't even let you see ideas that involve painful schleps. That's schlep blindness. PG's main example in this evergreen post – which is really an ode to Stripe – points to payments, ironically. > Probably no one who applied to Y Combinator to work on a recipe site began by asking "should we fix payments, or build a recipe site?" and chose the recipe site. Though the idea of fixing payments was right there in plain sight, they never saw it, because their unconscious mind shrank from the complications involved. You'd have to make deals with banks. How do you do that? Plus you're moving money, so you're going to have to deal with fraud, and people trying to break into your servers. Plus there are probably all sorts of regulations to comply with. It's a lot more intimidating to start a startup like this than a recipe site. Stripe (and Square, Ramp, stablecoins, etc) – having speedrun all kinds of schleps – have given payments novelty and prestige. Still, *even* payments people – even at companies like these, even I! – often overlook the *schleps* that underpin what "payments" *actually are.* ![[Pasted image 20260501170219.png|The early days of Stripe.]] --- If you had to *actively push* funds to a merchant every time you owed them for a subscription, or in every checkout flow where you wanted to buy something from them: it would be enough work for you that at the margins – perhaps even *at* *large* – fewer of these transactions would occur in the first place. *This is my account. Take my money.* This is the case for pull payments you make in retrospect, but it's also a bit galaxy-brained relative to the *actual* origin of this mechanism; which I think is more intuitive and follows from more common-sense improvements on money: *more*, *cheaper*, *faster*. It's instructive to walk all the way back to paper checks and work forward into "debiting". ## Paper checks are pull payments (and pull payments are credit) %% It's unsurprising that the bleeding edge in "payments-grade crypto" is the ability for merchants to "charge" – pull from – customers holding crypto; for subscriptions, autopay, etc. It’s a much harder problem than anyone lets on, though, and I think it remains unsolved in both crypto and consumer real-time payments. ![[Pasted image 20260429130501.png|Tempo, the Stripe/Paradigm-incubated blockchain for payments, recently announced the ability to "charge" for subscriptions and autopay, onchain.|600]] The first passes at this problem in crypto – still behind on "unsecured credit" – resorted to the solution of *escrowing* funds in transit, and only releasing from escrow to end-recipient once everyone was ready for finality (ie. the sender was beyond their window of recourse). This is the worst of both worlds: - Slower than ACH, in practice: funds sitting in escrow are not spendable by end-recipient, so it's closer to as if the funds haven't landed yet. - Any improvement to the "recourse" the sender has is at the cost of the funds availability for the end-recipient. %%