4 ms·
Yes this looks like a classic case of payment schemes not working anything like how people think they work (or even working in a sane way). With regards to the
by avianlyric 7y ago
Yes this looks like a classic case of payment schemes not working anything like how people think they work (or even working in a sane way).
With regards to the credit card payment, my guess would be that it went over a dual message system. Which means one message reserves the money, and a second one moves it.
This is important because the first message will generally cause the payment to appear on your statement, and reduce your “available balance”. But doesn’t impact your actual balance. The money’s still yours so you earn interest on it, but you can’t touch it.
When the second message turns up the money moves and the transaction completes (sometimes called “posting” or “clearing” or “presenting”).
However if the second message never turns up (or a reversal is sent instead) then the money doesn’t move, it’s just un-reserved.
How banks represent this un-reversal is usually very confusing. Either the transaction simply disappears or a back dated transaction appears. This is because from the banks perspective the transaction never happened (it didn’t present, so no money moved and thus no transaction).
ACH is also a very strange payment scheme. I believe that debit ACH messages simply pull money from a bank account. The bank can’t stop this money movement (they always to have pay the bill or get disconnected from the ACH network). However in the case of fraud, your bank can send a message and claw the money back within a certain time span.
All of this sounds ridiculous and is a result of history. But replacing it would require hundreds or thousands of banks to agree a new standard, and there’s a good XKCD about new standards.
- deleted 7y ago[deleted]
- Animats 7y agoThis is really a user interface problem. Payment systems have distributed state machines, but the state isn't exposed to the customer and the parties may not be in sync. Banking is a "consistent eventually" system, with delays in days. The customer should be able to query "what happened with this transaction" from their account and get back a graphic of what's going on. That information is useful to fraudsters, though; some states are more vulnerable than others.
- CaptainZapp 7y agoBanking is a "consistent eventually" system, with delays in days. But why does it work within the same day (or partially virtually instantenous) with SEPA payments 1) between banks in different European countries? Why isn't there such a thing as IBAN 2) outside of Europe, which really helps to make bank transfers seamless and unambiguous? It sometimes seems that regulation and standardization is not such a bad thing. 1) https://en.wikipedia.org/wiki/Single_Euro_Payments_Area 2) https://en.wikipedia.org/wiki/International_Bank_Account_Number
- kyrra 7y agoFor ACH: you are correct, banks always accept them. But after they are told the ACH happens and determine the target account has some issue (closed / invalid / insufficient funds), then the bank will send an ACH reversal. This reversal behaves almost exactly like the original ACH (the bank that they are issuing the reversal against cannot do anything to stop it until after it has posted).
- marcosdumay 7y ago> But replacing it would require hundreds or thousands of banks to agree a new standard The Brazilian banks got their hand forced into changing their system recently, but this one feature stayed exactly the same way. Hell, if you take enough details out, it is exactly the same as a two passes commit we use in distributed databases, where there is a single team (often a single person) defining the behavior. Don't expect that one complexity to go away any time soon.
- avianlyric 7y agoIt’s frustrating because the two pass commit only really exists as a result of slow and expensive communication channels in the past. Many payment schemes were built with idea that messages would be sent via post (on big tape reels) or expensive internet connections that can’t be run 24/7. However none of these constraints really exist anymore. Which means that you can move money using a single message and synchronous communications, with a little protection to deal with the two generals problem.
- mixmastamyk 7y agoWhat happens when the com lines are down during a storm? Will this single message still work?
- egwor 7y agohow many messages a second can be handled synchronously? what happens if the message arrives twice? what happens if the data centre is blown up/goes up in flames? how did the other data centre guarantee to be in a consistent state? how did the backup system automatically take over? These systems have to be up and running all the time and there can't be an option for mistakes!
- avianlyric 7y agoWhen I say message I’m think of the equivalent of a TCP packet. So you have a bunch of error checking and ACKs flying about. But only one message to actually move money. Single message systems already exist, most US card transactions move over a single message system. > there can’t be an option for mistakes! This is where you’re wrong. Mistakes happen all the time when moving money, a big part of any banks operations is cleaning up those mistakes.
- pas 7y agoBanks are subject to banking laws and various oversight authority/agency policies. Around here the banking authority started development on new ACH features (4 hour transfer, and they are developing "instant" transfer, and hopefully 24/7 transfer too), and the banks have to get on board in 1-2 years. (There's a deadline. Sometimes it gets extended because too many banks fuck up, but they get fined. It works up, progress happens.) So, it's very, very, very far from impossible. If there's political will, it can happen in about 1-2 years.
- lotsofpulp 7y ago> With regards to the credit card payment, my guess would be that it went over a dual message system. Which means one message reserves the money, and a second one moves it. Yes, it’s called an authorization hold or approval hold. The customer’s bank returns back with an authorization code or approval code reserving a certain amount of money. Then the merchant goes back with it to retrieve the amount actually wanted. This is for situations like filling fuel, or hotel stays, or car rental where the final cost is not known at the beginning of the transaction, so an estimated amount is placed on hold, and then whatever is used is actually taken.
- kalleboo 7y agoIt's also used routinely for regular e-commerce. A hold is put when you place an order, but the charge isn't completed until they ship out the item.