# Debiting, its dark matter, and slow payments 4/29/26 The ability for a merchant to *charge* their counterparty's account – to *pull* funds from them – is critical to modern commerce. This is broadly called "[debiting](https://dictionary.cambridge.org/us/dictionary/english/debiting)." If your counterparty had to *actively push* their funds to you, merchant, every time they owed you for their subscription, or in every checkout flow where they wanted to buy something from you: it would create enough work for them that at the margins – perhaps even *at* *large* – far fewer of these transactions would occur in the first place. *Take my money.* It's unsurprising that the bleeding edge in "payments-grade crypto" (for lack of a better term) is the ability for merchants to effectively "charge" customers holding crypto -- for subscriptions, autopay, etc. I think it's a longer march (no less worthwhile, though) than advertised. ![[Pasted image 20260429130501.png|A recent announcement from Tempo, the Stripe/Paradigm-incubated "enterprise-grade" blockchain: the ability to conduct subscriptions and autopay.|500]] Back to that in a bit: lets rewind back to the pre-crypto status quo. Some modalities familiar to, or at least implicating, everyone in the US are: - ACH debit: link your bank account, authorize funds to be pulled from it: and the funds are withdrawn by the merchant whom you authorized. Rental payments, subscriptions, etc. - Card charges: link your debit or credit card, there's an authorization for some amount in excess of the amount that finally clears; card-issuing bank (cardholder's) pays acquiring bank (merchant's), cardholder pays card-issuing bank async. It'll be useful to zoom in on ACH debit to call out the "dark matter" as I see it (because it's "darker" there). **ACH debit (and rails like it globally) are intrinsically reliant on *credit.*** This isn't obvious: aren't they pulling *my cash,* sitting in *my* bank account *already*? I already *have* the money, and I don't need to *borrow* it from anyone. There is no "balance" I owe afterwards. So in the case of ACH debit: what *credit* is being extended, and to whom? Let's walk through it. 1. Merchant pulls funds from their customer via ACH debit. 2. Merchant typically receives funds, and is able to spend them anywhere between same-day to 3-5 days later: depending on how much their institution worries the transfer could be disputed. 1. Their bank reliably receives those funds same-day or next-day, but they or the fintech on top will *hold* the funds -- until they're not worried about a dispute. 2. If the customer is a business, they have two business days to *dispute* this pull; if they're a consumer, they have sixty days. This happens via "ACH return." Let's give a hypothetical merchant their funds next-day: mirroring a scenario in which the merchant is trusted by their institution, and is not presumed likely to run into a dispute. The "credit" event is the moment the bank allows the merchant to *spend* or *withdraw* that money. That money has entered superposition. It's *recallable* for a number of days by the customer and their bank (insufficient funds! wrong account! frozen account! unauthorized!) -- ie. provisionally *still available* *to* the sender – but simultaneously available to the *merchant* in the meanwhile. If both parties, both with a claim to the same dollar, decide to exert that claim: the bank is out that money. In practice: 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. Therein lies the "credit" underpinning ACH debit (and the global debiting rails like it). --- The reason money is in two places at once -- which is the general shape of "credit" -- is that the sender of funds has *recourse,* in exchange for the recipient having *control*. The recipient can have provisional access to the funds as long as the sender also has provisional access. *Eventually*, and this eventuality is why payment rails like ACH are "slow," funds decisively[\*](https://www.bitsaboutmoney.com/archive/no-payments-are-final/) belong to one of the two counterparties. The very first passes at this problem in crypto typically resorted to the inelegant solution of *escrowing* funds in transit, and only releasing from escrow to end-recipient once