Now such gift cards aren’t perfect — you have to pay a bit extra, but for the purpose of signing up for a trial period with any company that automatically turns your trial into a subscription and which is known to make it difficult to cancel the trial it might be a good idea.
However, before even signing up for a trial with a prepaid gift card one needs to be sure that one is not entering into an agreement that legally binds you to a subscription.
I recently bought a prepaid gift card that I intend to use for a 7-day trial with a company that is known to make it difficult to cancel. But I will only sign up for the trial if the automatic subscription is not legally binding.
This gets to the heart of the matter: it shouldn’t be possible to sign up for a legally binding automatic subscription for a pure service. Customers should have the liberty to leave at any time without incurring a fee.
If I can sign up in under a minute I ought to be able to leave in under a minute.
There was a period between the old expiration and the new issue and not common, but it did happen from time to time.
I'm sure you've seen the idea that an upgrade to IP could have just added another octet or two and changed nothing else. It would have worked pretty well to prevent us running out of addresses, with 40 or 48 bits.
Well, 16 digit credit card numbers are a hair under 50 bits. And full-size 19 digit credit card numbers are a hair under 60 bits. That's plenty. You can give out a million of them to every person. If we couldn't reuse, they would eventually run out. Because we can, they won't run out.
Then factor in that CC numbers have an ~2year expiry date and a 3 digit CCV number, so old numbers can easily be reused.
Further the name of the holder could be added as a key to the number, further increasing reuse.
We won't run out of CC numbers anytime soon.
Based on wikipedia [1], the first 6 digits are used to identify the issuer (although from looking at this listing [2], it appears to be standard practise to assign some institutions blocks of IINs, and given that an institution could control multiple IINs, it is probably relatively safe to consider these to be part of the unique card ID. When we start to run out, we will probably see a market for these emerge in the same way we see a market for IPv4 subnets today.
The only area of fragmentation where I see potential trouble for secondary markets is the first digit, which is restricted by industry (banking only has 4,5,6); but if it ever becomes an issue, I am sure they will re-purpose the address space of other industries for banking
This leaves only the checksum digit itself of deeply problametic for maximum utilization; and that is literally a single digit.
[0] I wish this were a joke. https://webstore.ansi.org/Standards/ISO/ISOIEC78122017
[1] https://en.wikipedia.org/wiki/ISO/IEC_7812
[2] The official listing is not publicly available https://www.bindb.com/bin-list.html
It would of course require a massive amount of work across the board, so it's very unlikely to happen.
It's true that the number of organisations that interact with the message formats for sending card transactions is significantly smaller than other things, but we're talking about every single bank, every single PSP, every single embedded card device, and probably many more organisations beyond that, currently in operation today. Given the glacial pace of most banks' IT operations I would not expect them to do be able to achieve this within a time frame of several years or perhaps even a decade.
Sure these are not the same challenges as IPv4 and such, but it is in no way a trivial change to tweak a message format that has been in use since before most HN users were born :)
And it really should be enough. With 10^18 numbers you can allocate 1000 numbers per day to each of 10 billion people, and go 10 years between reusing numbers, and still have only a few percent of numbers reserved at any point in time.
Also CVVs won't match even if you reuse the number
I contacted the bank, and they said if the charge was not fraudulent (1), there's nothing I or they can do. Apparently the merchants can back-date transactions like that to a time when you interacted with them and the card was valid; I'm not exactly sure how they can charge an empty debit card though, but apparently they can do that too (because they pre-validated that I had a certain amount at the time of rental?).
(1) It wasn't; the contract said that they can do that, and I actually could use a ticket reference number that they quoted to verify on the police site that there was indeed a parking ticket issued to the car on the day that I dropped it. To this day I'm not sure if it was me who committed a parking violation, or the next person who rented the car, after me. It is mildly plausible that it was me - that morning I parked in a legal parking space, but slightly outside the allowed "lines" (another car was taking a third of the only remaining slot, and I parked a bit outside of it).
One of them ("Authorization") is about verifying that the payment has been authorised by a cardholder, and is there to protect the issuer against fraud by their own cardholder and perhaps if you squint, to indirectly protect you from thieves. This has been the focus of technological innovation, up to and including EMV ("Chip and PIN"). It's also completely optional, most cardholders have no idea that's the case.
The other mechanism ("Settlement") is about taking money from the cardholder's account and putting it in the merchant's account. This is done entirely on the honour system, always has been, probably always will be, none of the technological improvements touch it significantly. It's mandatory in the sense that without it the merchant can't get their money.
Avis doesn't need Authorization to get your money, they only need Settlement. And like I said, it's on the honour system. Any merchant in the system can just tell the card network "Hi, card number X gave us $418.26" and they'll get $418.26 of X's money in their account. No need for any other steps.
Now, if you dispute the transaction the issuer _might_ say, well, wait, how do we know they agreed to pay $418.26? And then Authorization matters, the Authorization can prove somebody swiped a card, or typed in a PIN, or whatever. Without Authorization the issuer might choose not to pay. But there's no guarantee as you found, unless a government regulation forces their hand why should they care - it isn't their money?
This reliance on the honour system means that e.g. even though EMV has anti-replay features that mean Authorizations can't be re-used about once a year or so in the UK you'll have a news story where some big merchant like a supermarket or fast food chain will double charge all card customers for a day. What happens is the Settlement data just gets accidentally run twice, maybe it's a physical magnetic tape, or a backup copy of a file, or some new server boots up and re-runs yesterday's Kafka stream. Settlement has no replay resistance so even though all these transactions are duplicates that goes undetected until customers start phoning up angrily and their bank realises what happened.
To a first approximation nobody checks Authorization. If you wanted to be an asshole you could try it out, ask your bank to reverse a random fraction of all your transactions. When you get a bill, pick some at random, phone the bank. Insist those are bogus and you've never heard of them. In most cases the vendor has no usable Authorization records and will just write it off, they were entirely reliant on getting paid on the honour system. Obviously if you're unlucky you'll pick someone who can prove you owed them money and is angry about it, so you may not want to try this after all.
You might think this situation is crazy but it's more common than you realise. There have been a lot of grave problems with SSL/TLS over the years. But there aren't many examples of actual consequences in practical terms. Mostly it seems as though there actually aren't bad guys trying to break your secure communications, so even if it would be possible they didn't try. Huh.
How about the case I mentioned? If I told the bank "I did not authorise Avis, would Avis have been able to somehow "prove" that I authorised the transaction (I obviously didn't; the card was expired when they charged it; but I did have a signed contract with them, is that enough to directly take money from my account? Feels like it shouldn't be enough, not without a court getting involved).
Whether the bank has to take your side will depend on law where you are more than any technical facts. That signed contract is going to be a factor, and you giving Avis the card (even though months before and without expecting to pay this) would probably matter too, I'd be surprised if the issuer or the law was OK with something like "We found this card number on an unrelated payment from years ago so we charged it".
I mostly think this should be "fixed" to be stricter, but let me briefly take the merchant's side. Suppose I check out from a hotel one morning. $120 for one night sir, thanks for staying with us. Two hours later cleaners find the room is trashed. I've ripped up the carpet, a chair is in pieces, the wall TV has been attacked with a knife. Why the hell shouldn't they be able to try putting it on my card? Should my bank really refuse if I have the money, and force them to take me to court to try to get their money just because I didn't authorise the charge? Realistically it's not in anyone's interest to insist on that except bad actors.
Yes, absolutely. Are you seriously arguing that anyone should be able to claim money from your bank account without either prior authorization by the account holder or independent arbitration? Bypassing the courts in cases like this serves no one's interests except bad actors.
I called and complained and the customer service told me that once I had authorized the merchant to charge me, they would accept any future charges even if the card number was closed.
Just curious, have you actually used BofA's service? Maybe the implementation is different now...
If it works, it would be a great way to limit those automatic renewal situations.
Been using it for years. Great service.