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.
[1]: https://en.wikipedia.org/wiki/Electronic_data_interchange [2]: https://en.wikipedia.org/wiki/Credit_card_imprinter
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.)
Additionally, at this time credit cards didn't have the 3 digit security code they have today so generating a 'valid' number was trivial.
When your product is “infinitely cheap to reproduce” losing some to fraud that doesn’t cost you is just part of doing business.
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.)
He was like the cool older brother we never had. Hope he's alright now. Probably a major factor behind me choosing this career.