[dundee] Chip and Pin payments - Consumer Rights when there's an error...

[Rick Moynihan]

On 9 June 2010 12:27, Andrew Clayton <andrew at digital-domain.net> wrote:
> On Wed, 9 Jun 2010 11:59:30 +0100, Rick Moynihan wrote:
>
>> 5 minutes later the manager comes over and checks for the transaction
>> on their computer system (the till was still locked up)...  There's no
>> sign of the amount.  Again I say that the receipt constitutes proof of
>> purchase...  He tells me, it would have shown up on the computer
>> system, and says they'll have to run the items through again on
>> another till.
>
> I guess larger places have all the POS's linked to a central computer
> where the transactions are queued up and then sent down visanet in
> batches. In this case the chip and pin bit just authorizes the
> transaction (Do you have X amount in your account?).
>
> It seems that what they where worried about was that the actual
> transaction hadn't made it from the POS to their computer. Although
> as you show later it looks like it did.

This potential design did occur to me at the time... and if it were
designed this way, would support the managers belief in the systems
design...  i.e. under such a system I can see that Tesco would either
be short OR the intermediate system can retry a transaction, without
presence of a PIN authorisation!  This contradicted my prior
understanding of chip and pin, i.e. that the PIN acceptance part of
the transaction (at a wire level)...  Introducing an intermediary and
the ability to retry would seem to be more than a little scary.

So given the likely case that my mini-statement shows I've been
charged twice, it would seem that the Tesco transaction log isn't
actually part of the transaction itself... i.e. their record of the
transaction is merely a side effect of a successful transaction and
not part of the transaction itself.  If I were a chip and pin engineer
this would be the preferable design, lower complexity, arguably more
secure, and a healthy decoupling between the till, the stores computer
and the bank... though I would want the stores and operatives to know
that the most definitive indicator of a successful payment, was the
reader telling the user that the payment was accepted, followed by the
till receipt printing the totals and the stores log.

Obviously in any distributed system it is impossible to be 100% sure
of the status of a transaction... (See the 2 generals problem for an
explanation why).  I just wish they'd make their staff more aware of
the fact that these systems can never be even close to infallible.

>> Assuming I have been charged twice (it very much looks like it), as a
>> software engineer I also find it interesting that the system was
>> designed to errr on the side of the store rather than the consumer in
>> the case of error.
>
> You find it surprising!. I don't.

On the contrary, I find it interesting not surprising...  If I was
surprised, I wouldn't have spent 15 minutes disputing the managers
wisdom that "because it aint on our computer it means it ain't gone
through".  I really just wanted to get home and make my tea, without
getting the checkout girl into too much shit.

Next time I might be more ruthless.

R.