In article <email@example.com>,
Marcus Didius Falco <firstname.lastname@example.org> wrote:
> email@example.com (Robert Bonomi) wrote about Re:
> Cardholders Kept in Dark After Breach -- Washington Post on
> Fri, 24 Jun 2005 11:02:59 -0000
>> In article <firstname.lastname@example.org>, Marcus Didius Falco
>> <email@example.com> wrote:
> Where there are dozens or hundreds of transactions as on really busy
> cards, it becomes difficult.
My real-world experience over several years indicates otherwise.
> Particularly since the name and date of the payer on the statement
> may differ from that on the receipt.
There is a 'transaction date', and a 'posting date'. The posting date
can wander fairly widely, although it is always _after_ the date of
the actual transaction. The recorded transaction date is also
guaranteed to be 'on or after' the date the purchaser has recorded.
Except in cases of 'delayed' shipments, it is almost invariably (at
least in my experience) within 2-3 days of that date.
In nearly 3 years, I had a grand total of 4 'suspect' transactions
that required a 'non-trivial' amount of work to sort out. By that, I
mean more than a minute or so. "Average" time was a few seconds per
2 were cleared up with a total of about 15 minutes work each -- a
check with the card user to see if they recognized the seller (just
failed to turn in a record of the transaction -- unrecognized name ),
phone call to the seller, asking for info on the transaction -- which
_was_ consistent with a company purchase; and' included the name of
_their_ division that the purchase was made through. Confirmed as
correct, by the card user for a phone order they'd placed.
#3 was the company President's son using daddy's card to sign up for
ISP service. That one consumed a fair part of an afternoon -- most of
it in getting to the 'right people' at the (somewhat disorganized)
ISP, who actually had access to the answers, and the authority to 'do
#4 was a bad charge, all around. The merchant couldn't find anything
that matched it, when I called them. Forwarded that to AMEX, for them
to deal with, while disputing the charge. Turned out to be a
transcription error -- applied to wrong card number; yeah, the
check-digit is supposed to catch things like that, but in this case it
> And, in the case of international transactions, the amount will
> differ, too.
>> I used to do it every month, for several corporate cards that had
>> several _hundred_ charges/month. Life was _really_ fun when the
>> Company President's son (away at college) used daddy's card to sign up
>> for Internet access (and the fact that the initial posting was 'late',
>> and was for _4_ months services). That one _jumped_ off the statement
>> at me -- the company had it's own dial-up pool, and everybody used
>> _that_ for home access.
> Well, if you have a full time job, and can spend a day or two at it,
> then you might succeed. Except that you have to spot that a charge for
> $5 to $10 from "Strange Parking" isn't the same as the receipt you may
> have for a similar amount from "Storage Parking".
Reconciling circa 1000 transactions on 3 active cards generally took
me less than an afternoon.
Mistaking that 'Strange Parking' charge tends not to be a problem,
when the charge from 'Storage Parking' is _also_ on the statement.
The fact that there are more _items_ on the statement, than there are
items in the user- maintained record, *is* a little hard to miss.
>> If you choose not to do so, and 'uncritically' accept their
>> accounting, that _is_ your choice.
> If they want to send my a diskette of my charges. (No, I won't trust
> it to the internet for reasons that have been explored very thoroughly
> in this Digest in the past.)
Strange. I never needed anything more than the 'detail' data that came
with the mailed statement.
>> Note: if you are in the UK, as your email address seems to indicate,
>> it is _unlikely_ that any of your cards were exposed via the
>> CardSystems 'problem'. Unless you're doing siginficant credit-card
>> buying in the U.S., that is. CardSystems clears almost exclusively
>> for U.S.-based merchants.
> They would have processed charges in the US for foreign cards,
Make that "may have", for _some_ foreign card purchases in the U.S.,
and you'll be correct.
> and charges on US-based cards for holders dwelling abroad.
The _merchant_ the purchase was made from would have to be using
CardSystems as *their* charge processor. CardSystems is by no means
the only player in that field. They are a fairly large one, but there
are *lots* of other firms (as in "hundreds") in the same business in
the U.S. They are nothing more that a 'middleman' (one of _many_
possible such agents) between the merchant and the various CC
companies. The merchant 'talks' to the middle-man's computers, who
'talks' to the CC company's computers, which "talk" to the issuing
institution computers (in some cases, like AMEX, this _is_ the CC
company; in the case of 'bank' cards, it is not), which accept/decline
Any characteristics of the customer are wholly irrelevant to the
matter of who the particular merchant uses as the 'middleman'.
For purchases made through merchants who use a different company to
process their transactions, there is no possible exposure from the
CardSystems security failure -- the data never went near CardSystems'