response 30 of 48:

Jul 3 20:47 UTC 2000

Tardy response: I too telnet-through, frequently.  IN fact, on this last trip
I took I was using Grex to telnet through to UM every day.  

response 32 of 48:

Sep 27 04:01 UTC 2000

Well, disabling telnet-through on a trial basis MIGHT let us test
the hypothesis that the invalid charges are motivated by that access.
Of course, the subsequent disappearance of invalid charges wouldn't tell
us much; only the continuation of the charges would disprove the hypothesis.

response 34 of 48:

Sep 27 06:03 UTC 2000

Can someone please concisely explain the mechanics of how grex gets charged
for some action that does not result in a valid transaction?  Or direct me
to where this has already been explained?

response 36 of 48:

Sep 27 16:14 UTC 2000

I'll see if I can't attempt #34.  

There are two people who charge us for credit card services:  Charge Solutions
and CardService.  (The similarity of these names confuses the hell out of me,
too.)  
  CardService is the bank with whom we have a merchant account.  They
perform the actual authentication and charge the credit cards.  That is, they
somehow get the credit card number, expiration, name, address, etc., and
decide whether to accept or decline the transaction.  
  Charge Solutions provides the web portion.  They own the secure server 
where you enter your credit card number, exp, name, address, etc.
  CardService charges us as follows.  (This is from memory, so I may
be forgetting something minor.)  For every authorization, they charge
us $0.35, whether it results in a charge or not.  If the authorization
succeeds, they charge the credit card the specified amount.  They
deposit approximately 97% of that amount directly in our bank account,
and keep the rest.  At the end of the month, they remove the
accumulated $0.35 fees from our bank account directly.  
  Charge Solutions charges us $0.50 (currently) every time they send a 
card number to CardService for authorization.  The total amount is
removed directly from our bank account at the end of the month.  

Examples (slightly simplified):

A. On September 15, janc goes to the web page and purchases a 1-year 
   membership for $60.  He enters a real credit card number, with 
   correct name, address, etc., and presses the final "Purchase" button,
   which is on a web page hosted by Charge Solutions.  Immediately,
   their software takes that card number etc., and sends it to
   CardService for authorization.  CardService says yes, we'll 
   accept it, but does not charge the card yet.  Charge Solutions 
   then sends me an email informing me that a successful authorization
   has been done.  I get the email, go to another web page on the
   Charge Solutions server, where I can view the details of the 
   transaction (such as the card number) that they didn't tell me
   over email.  I write the details down for my records, and tell
   Charge Solutions to go ahead and do the transaction.  Charge
   Solutions then tells CardService to go ahead and do the
   transaction.  At this time, (still on September 15 (at least in
   theory)) CardService charges the credit card $60, deposits $58.20
   in our bank account, and keeps $1.80.  
     Nothing more happens until the end of the month, at which time 
   Charge Solutions charges $0.50 to our bank account for the
   authorization, and CardService charges $0.35 to our bank account.
   Final result:  
     Us:              +57.35,  
     CardService:     +2.15, 
     Charge Solutions +0.50
   This is the way it's supposed to work, and everybody's happy.

B.  On September 15, J. Random Cracker goes to the web page and 
   attempts to purchase a one month membership for $6.  He enters
   a credit card number generated by a program he downloaded
   somewhere, a name that resembles "hahdhadf sakfdjj", similar 
   address information, an email address that he stole from 
   some innocent bystander or just made up, such as (this is common)
   fuck@fuck.com, and clicks the final purchase button.  Immediately, 
   Charge Solutions takes that card number, etc., and sends it to 
   CardService for authorization.  CardService declines it.  Charge
   Solutions tells Mr. Cracker that the card has been declined.  
   Meanwhile, I get an email informing me that an authorization was
   declined, get pissed off, and save it out of habit, mainly.  
     Nothing more happens until the end of the month, at which time
   Charge Solutions charges $0.50 to our bank account for the (failed)
   authorization, and CardService charges $0.35 to our bank account.
   Final result:
     Us:               -0.85
     CardService:      +0.35
     Charge Solutions: +0.50
   This is what is happening a lot. 

C.  Exactly the same as example B, except that by sheer luck, the
   generated card number gets accepted.  Charge Solutions tells 
   Mr. Cracker that the authorization was successful.  I get an 
   email informing me that "hahdhadf sakfdjj", fuck@fuck.com, has 
   successfully authorized me to charge $6.00 to this card number.  
   Obviously, I do nothing of the kind, not being utterly stupid.  
   I save the email as before.
    The bottom line is the same:  we lose 85 cents, CardService gets 
   35 cents, and Charge Solutions gets 50 cents.  But in this 
   scenario, J. Random Cracker now knows a valid credit card number
   and expiration date that he can take elsewhere.  
 
This is somewhat simplified (Funny things happen on the CardService
side especially, with regard to batches of transactions, and the 3% is
an approximation, that varies with certain factors.), but it's 
basically what's going on.  

Well, that was hardly concise, but hopefully it was helpful.  

response 38 of 48:

Sep 27 20:01 UTC 2000

Thanks very much for #36!  In a certain way, Charge Solutions has a "scam"
going, in that their mindless handling of every transaction attempt without
oversight allows the mechanism to be abused, at grex's expense.  I'm not sure
off hand what could be used to limit the crackers attempts (say, to one per
day) - IP address, e-mail address, SSN, etc.  But this automated nicety grex
tried to establish has now already proven more costly than beneficial. 
Without a human involved in the process - and who on grex is going to
volunteer for the job - I don't see any way for grex to prevent abuse and
expense.  I would be glad to be shown that I'm wrong about this, but I don't
have a rosy outlook at the prospects.

response 40 of 48:

Sep 28 12:17 UTC 2000

This is turning out to be an expensive experiment.  I might
be a lone voice here but I'd suggest our organization isn't
the best candidate for online transactions.  As expensive as
this problem is it could have been a whole lot worse.
We are putting ourselves at risk for not a whole lot of gain,
if any.

response 42 of 48:

Sep 29 00:12 UTC 2000

I think that if we can find a cost-effective way to do credit card
transactions online which allows for the treasurer to approve before charges
are incurred, then that's the way to go.

response 44 of 48:

Sep 29 04:15 UTC 2000

You do not need a credit card to create a PayPal account.

It does not look like this probem has anything to do with Telnet through.

response 46 of 48:

Sep 30 01:34 UTC 2000

The problem with paypal (which is why I dropped my advocacy of it before) is
that they don't accept international credit cards, which was what the credit
card system was set up to do in the first place.

response 48 of 48:

Oct 1 03:00 UTC 2000

If not, we might want to look at credit card systems that don't assume that
all transactions are happenign through a web browser.  We could then have a
web interface that could send the card numbers to a human, who could run them
through the manual system just as somebody taking orders for stuff over the
phone would, thus filtering out unwanted transactions.

I still think, though that we can't be the only ones who have encountered this
problem.  There must be some online credit card processing companies that have
come up with a way around it.