How interesting! I wonder what happened behind the scene to require this. Companies in spaces like that usually require specific merchant banks that are willing to deal with "high risk" (or so seemed to be the search term). I wonder if this had advantages in bank selection or how it looked to the banks? Or perhaps a technical limitation?
I’ll admit it now: in the very early days of bird scooters they accepted visa and MasterCard test numbers. You could start rides and only after a week would they block your account. Of course, the only thing you needed back then to sign up was an email. If you had an android, you could just wipe the cache, enter a nonexistent email address off the top of your head, paste in a test card number and get going again. Fond memories.
I had a friend who carried around a canceled credit card to get free rides on the bus. The fare boxes accepted swipes and didn't/couldn't settle transactions until they were back in the barn. So they took any credit card that checksummed, I suppose.
They ceased this feature soon afterwards. I was appalled that they'd ever enabled it if it was so vulnerable. (I don't think public transit really cares about collecting fares as a priority.)
I think there was no realtime CC processing back then. In my last job I found artefacts like fax forms where they would write down collected credit card data (from online subscriptions) to be sent to their processor. To have at least _some_ safety they would just check [1] if the CC number is sound.
I remember Authorize.net was one of the first credit-card processor for eCommerce (Archive.org goes back to 1998: https://web.archive.org/web/19981206052326/http://authorizen... ), they were the Stripe.net of the dot-com boom - at-least insofar as FastCGI or ColdFusion could take you back then - this was before "XML" was a buzzword: systems were exchanging SGML (if you were lucky!) or EDI[1] (if you weren't so lucky)
Obviously big-players, established businesses, et cetera would have had a more direct relationship with the banks and/or card-processors, but smaller site operators ("webmasters", heh) I assume must have had to run nightly batch-jobs that sent flat-files of card-numbers to card-processors using a modem that called the processors directly - rather than over the Internet (I understand this was also how many brick-and-mortar retailers sent in CC details transcribed from those manual card-impression machines[2], though I assume most let their bank do it along with their cash-deposits?)
-----
Unrelated-but-related: Authorize.net definitely sat on their laurels: their platform, web-service, and even their marketing landing-page was basically frozen-in-time from the mid-2000s right through to around 2017, I know because that's when I was working on a side-gig to migrate a system from Authorize.net to Stripe - that was such a breath of fresh-air. Sometimes I go back through time in the repo's commit history to remind myself how bad things were back then so I appreciate that things sometimes do actually get better.
I worked for a company until 2011 that developed and licensed a shopping cart where Authorize.net was our most preferred processor. We could do others but Authorize.net had the best integration. Even in 2011 Authotize.net’s site and API just felt super old.
I worked for another company creditnet.com that started a bit before authorize.net basically wrapped ICVerify dialup verification using PGP to encrypt merchant to processor request/response.
I recall CC's being emailed via a form on the website and then input using the PDQ machine at the other end (what PCI?). For extra security they started sending it in two emails! I'd imagine some forgotten far flung corners of the internet still do janky stuff like that (or what was available/reasonable at the time at least)
I worked on a web site about 20 years ago where the form sent a PGP encrypted email. The credit card was then processed by hand. I'm guessing this isn't PCI compliant. ;)
In the 90's, we had something similar at another company. Except there, the email wasn't even encrypted. (Don't worry, the site used SSL.)
My former employer was a lot more YOLO than that. When I joined (in the mid 2000s) there was no https on the website, passwords stored in plain text, no backup strategy, etc. But they printed money with their system.
Hitting an invalid credit card just results in NO SALE, which the bank won’t care much about. What they don’t like are cards that go through and then get contested.
When your product is “infinitely cheap to reproduce” losing some to fraud that doesn’t cost you is just part of doing business.
Like the other post said, I assume they were manually sending the information to their merchant bank so there was a significant delay between when your account was created and when they discovered it wasn't real.
Additionally, at this time credit cards didn't have the 3 digit security code they have today so generating a 'valid' number was trivial.
