Twice I've sold an old car to somebody who answered my ad. I wanted cash on collection only, because I was selling the car to someone I didn't know, couldn't reliably trace and therefore could not trust. If they'd reversed the payment afterwards, I'd have been down a car.
Both parties to this kind of transaction understand why finality is required, and don't have a problem with it. It's a second hand "sold as seen" transaction. The buyer knows where the seller likely lives. The seller doesn't know anything about the buyer. Neither party typically carry that kind of cash around, so there are two trips to the bank (with their own risks) that could be saved if there were some sort of easier digital equivalent.
If they'd have turned the corner to see the engine fall out from underneath the car, while you'd have already strolled off the scene with the money, they suddenly wouldn't be so happy with finality. I think finality in transactions is more something about "the nominal case". If I'm a transaction processor with significant volume, I would like to reach some final state without too much intervention, but I can still handle the exceedingly-rare exceptions with (expensive) humans. Where that point lies differs per application, also dependent on what kind of service I'm wanting to deliver.
> If they'd have turned the corner to see the engine fall out from underneath the car, while you'd have already strolled off the scene with the money, they suddenly wouldn't be so happy with finality.
Maybe, but since I also wouldn't be too happy if they reversed the transaction after taking the car, we both agree in advance that the sale will not be reversible. For the payment, that's done by using cash (and the possession of it), and for the car, also just possession. I give the buyer the opportunity to inspect the car before committing to the sale, and then it is "sold as seen". Unless I committed fraud, the engine falling out from underneath the car will be the buyer's problem, including in law.
It is always possible to seek redress through the courts whether the financial transaction itself was reversible or not, so that's not relevant here. Neither is the fact that to do that knowledge of identity and evidence is required; those concerns also exist regardless of transaction reversibility.
That's why you test-drive a car and/or have it inspected. If it is a clunker and the price of the inspection approaches the price of the car you can just take the risk. In any other case an hours worth of time of a competent mechanic will tell you all you need to know. After that the risk is yours if you decide to go through with the purchase. If something does turn up that wasn't disclosed the seller will usually be happy to adjust the price. And if not you are only out the inspection fee. Typically $50 to $150 so well worth it on any vehicle purchase that is in the price range where 'engine fell out' feels like it isn't on the menu of expected events.
> If they'd have turned the corner to see the engine fall out from underneath the car, while you'd have already strolled off the scene with the money, they suddenly wouldn't be so happy with finality.
Which is exactly the point of the finality of the transaction. Private party car sales in the US typically are not warranted. The risk of maintenance on a used car is non-zero, and the buyer accepts this risk when buying a vehicle with no warranty.
But in all seriousness, if you are a vendor then any purchase by a customer that is not associated with a legally accountable entity must be settled with finality, because you have no way of preventing charge-back fraud yourself.
In cryptocurrency marketplaces, the customers vet the vendors, not the other way around. This is because the vendors have a higher upfront investment in their business and reputation. The customers are not expected to maintain a reputation (for sake of their privacy) or an investment (outside of an multisig escrow) so any attempt to vet them is prone to sybil attack.
The process of vetting customers is usually assumed by some monopolistic intermediary like PayPal. These companies are able to vet customers by implementing a mass surveillance system.
If you are a merchant selling goods and services for money, and had the choice between transactions with finality and without, you will always chose transactions with finality.
If customers demand reversible transactions, you will choose reversible transactions or you will not have customers.
There are, for instance, no longer many mainstream online merchants who accept only irreversible transactions. There once was a time when online transactions were primarily paid via money order, but PayPal and credit card processing has made that obsolete.
> If customers demand reversible transactions, you will choose reversible transactions or you will not have customers.
I think most customers pay with credit cards more because of convenience (or rewards, where applicable).
There's a myriad of QR payment systems popping up around the world (e.g. WeChat, UPI, PayNow) that are getting considerable adoption — and those aren't reversible. They're popular because customers don't have to worry about carrying enough cash with them.
You can't compare in-person and e-commerce payments in that way. The risk for the merchant and the customer is completely different:
A physical merchant usually has a storefront in a public place that they can't abandon on a whim, a reputation to lose etc, whereas the customer is usually anonymous and mobile. This is why customers are generally ok with paying using a (to them) irreversible/final payment method, and merchants will insist on it.
In e-commerce, the risk lies almost exclusively with the customer: An online store's reputation is not easy to judge (and brand impersonation is its own risk), and even at reputable merchants, the time between order and delivery is much longer, goods can usually not be inspected ahead of time etc.
Not coincidentally, the various card schemes' rules reflect this circumstance by assigning default liability for online payments to the merchant (or their acquiring bank, in case of a fraudulent or bankrupt merchant), whereas for in-person payments it lies with the cardholder (or in case of fraud with their issuer, in some circumstances).
The landscape of trust online is varied. Someone is likely to have lower trust for random website you’ve never heard of (which was most stuff in the early days) than an established business or one with a physical presence.
Now that online retail is mature and trust is high, credit cards are more for convenience, but this wasn’t the case in the early days… and still isn’t the case for lesser established sellers or marketplaces.
When was this time that online payments were done with money orders? Some of the earliest online merchants that were associated with AOL and Prodigy accepted credit cards. Amazon definitely accepted credit cards from day one.
In the mid to late 90s many retailers online operated like mail-order catalogs with catalogs delivered via http. Many of them were mail-order businesses first, and so they accepted payments for online purchases the same way they did for their majority of their customers.
This was also normal for eBay payments at the time.
There were, of course, a few that did accept credit cards, but many people were weary about using those features because very little of the web used HTTPS at the time. Even Amazon accepted money orders (and personal checks!) for this reason.
Not always. If customer fraud is low and customer wariness is high, you might well find that providing customers the safety of the option to reverse the charge gets you enough more money that it nets you more overall. Even more so if "finality" of the technology means that users instead turn to the courts to dispute your charges.
There is a narrow sense in which the merchant "always prefers finality" but it isn't the relevant sense.
Buying a house does not have 'finality' in that sense. This is why you buy title insurance - many things can happen where it turns out you don't own the house like you thought.
Happened recently, ordered pizza but they delivered to wrong address. Called them they wanted to deliver pizza again but it would have been too late. So they refunded the transaction, though seemed a little reluctant.
My guess is that if I had no option to do a chargeback, it would have been harder to get a refund then.
Then the dissatisfied customer throws a fit and warns their peers that the vendor isn't trustworthy.
There is an asymmetry here because anyone can be a customer but not everyone can be a vendor- that requires a certain level of reputation and upfront investment. So it is more risky for a vendor to scam a customer than the other way around.
I don't know, I hear all the time about people buying things on amazon or something and when it arrives it's just crap and you can't get a refund. At the end of the day, getting a refund is not about the payment method, it is about your business relationship with the vendor.
Cryptocurrency transactions require high trust in the sense that they cannot be refunded, but they also require low trust in the sense that the vendor cannot possibly steal any more money than what you sign them.
If you are going to argue by anecdote at least use a believable anecdote. Amazon have one of the most customer friendly refund policies and always offer a refund or replacement- obviously because they are just pushing it on to their sellers but still, they do.
> Amazon have one of the most customer friendly refund policies and always offer a refund or replacement- obviously because they are just pushing it on to their sellers but still, they do.
With an open season of friendly / chargeback fraud, customer lies, refund tricks, etc which customers keep doing every day and so on which too many of that and Amazon will ban your account and they should.
then the cook should be left uncompensated for their work? There is no "fair" outcome in this situation, so you should at least make the system fail in a reliable way.
Normally, with credit cards and stuff, the onus is on the vendor that made the sale, technically they should verify the Id of the user match with the name on the card and stuff.
Most don't do because convenience wins for the user and increases the value.
The user knows if something is wrong (like stolen funds, accounts etc) they will get their money back, and trusts the system so spends more.
İf you don't provide this trust system, they won't spend as much as they do.
