3 ms·

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

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?

wukerplank 3y ago
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. [1] https://en.wikipedia.org/wiki/Luhn_algorithm https://en.wikipedia.org/wiki/Luhn_algorithm
- DaiPlusPlus 3y ago
  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://authorizenet.com/ 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. [1]: https://en.wikipedia.org/wiki/Electronic_data_interchange https://en.wikipedia.org/wiki/Electronic_data_interchange [2]: https://en.wikipedia.org/wiki/Credit_card_imprinter https://en.wikipedia.org/wiki/Credit_card_imprinter
  - donatj 3y ago
    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.
  - papageek 3y ago
    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.
- _joel 3y ago
  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)
- icedchai 3y ago
  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.)
  - wukerplank 3y ago
    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.
  - papageek 3y ago
    Seattle? Serenet? Do I know you? :)
    - icedchai 3y ago
      Nope, east coast, north of Boston. I'm sure that sorta thing happened all over the place on the early Internet.
pram 3y ago
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.
bombcar 3y ago
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.
throwaway14356 3y ago
maybe they just sell the payment info?
popcalc 3y ago
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.
- NoZebra120vClip 3y ago
  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.)
  - felixg3 3y ago
    In 2013, I did that to get a free luggage trolley at Chicago O’hare. Just swiped an old credit card for the dollar and it immediately unlocked.
- tempoponet 3y ago
  This reads like a passage straight out of "Snow Crash".

wukerplank 3y ago

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. [1] https://en.wikipedia.org/wiki/Luhn_algorithm https://en.wikipedia.org/wiki/Luhn_algorithm

DaiPlusPlus 3y ago
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://authorizenet.com/ 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. [1]: https://en.wikipedia.org/wiki/Electronic_data_interchange https://en.wikipedia.org/wiki/Electronic_data_interchange [2]: https://en.wikipedia.org/wiki/Credit_card_imprinter https://en.wikipedia.org/wiki/Credit_card_imprinter
- donatj 3y ago
  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.
- papageek 3y ago
  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.
_joel 3y ago
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)
icedchai 3y ago
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.)
- wukerplank 3y ago
  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.
- papageek 3y ago
  Seattle? Serenet? Do I know you? :)
  - icedchai 3y ago
    Nope, east coast, north of Boston. I'm sure that sorta thing happened all over the place on the early Internet.

pram 3y ago

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.

bombcar 3y ago

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.

throwaway14356 3y ago

maybe they just sell the payment info?

popcalc 3y ago

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.

NoZebra120vClip 3y ago
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.)
- felixg3 3y ago
  In 2013, I did that to get a free luggage trolley at Chicago O’hare. Just swiped an old credit card for the dollar and it immediately unlocked.
tempoponet 3y ago
This reads like a passage straight out of "Snow Crash".