Just had to run one of the cats to the vets
Matt Williams
ukcrypto at chiark.greenend.org.uk
Tue, 15 May 2007 11:38:45 +0100
------=_Part_205166_14006603.1179225525502
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
After many years following this list, finally a question I feel vaguely
qualified to answer :-)
For authorisation transactions, the APACS 70-2 standard document sitting on
my desk only defines response codes for authorised, decline or refer - any
other response code will normally be treated as decline.
Most likely there was some kind of error with the payment service provider's
system (probably a timeout talking to the bank). Even if the return an
error response code (ISO 8583-1 defines a lot that aren't in the APACS spec)
the terminal would probably treat it as a decline.
Matt Williams
On 15/05/07, Ian Mason <ukcrypto@sourcetagged.ian.co.uk> wrote:
>
> We've just had to run one the cats to the vets.
>
> What, I hear you asking, has this to do with ukcrypto? Well, the chip &
> pin machine at the vets refused our card. "Don't worry", said Natalie
> the receptionist,
> "it's always doing that. As long as it isn't because there really is
> a problem with
> the account we can just run it again and it'll go through." We did
> and it did.
>
> Now I'm curious and I don't want to wade through thousands of pages
> of EMV to satisfy
> my curiosity when there's likely someone better informed on EMV that
> me here. Why did we
> get "refused" when clearly the problem was something else. Is this
> just a very poor
> error message - where you get "refused" for any failure rather than a
> more helpful
> diagnostic such as "transmission error". Or is there a flaw in the
> authentication or
> authorisation process that generates a 'real' false negative?
>
>
------=_Part_205166_14006603.1179225525502
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
After many years following this list, finally a question I feel vaguely qualified to answer :-)<br><br>For authorisation transactions, the APACS 70-2 standard document sitting on my desk only defines response codes for authorised, decline or refer - any other response code will normally be treated as decline.
<br><br>Most likely there was some kind of error with the payment service provider's system (probably a timeout talking to the bank). Even if the return an error response code (ISO 8583-1 defines a lot that aren't in the APACS spec) the terminal would probably treat it as a decline.
<br><br>Matt Williams<br><br><div><span class="gmail_quote">On 15/05/07, <b class="gmail_sendername">Ian Mason</b> <<a href="mailto:ukcrypto@sourcetagged.ian.co.uk">ukcrypto@sourcetagged.ian.co.uk</a>> wrote:</span>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">We've just had to run one the cats to the vets.<br><br>What, I hear you asking, has this to do with ukcrypto? Well, the chip &
<br>pin machine at the vets refused our card. "Don't worry", said Natalie<br>the receptionist,<br>"it's always doing that. As long as it isn't because there really is<br>a problem with<br>the account we can just run it again and it'll go through." We did
<br>and it did.<br><br>Now I'm curious and I don't want to wade through thousands of pages<br>of EMV to satisfy<br>my curiosity when there's likely someone better informed on EMV that<br>me here. Why did we<br>
get "refused" when clearly the problem was something else. Is this<br>just a very poor<br>error message - where you get "refused" for any failure rather than a<br>more helpful<br>diagnostic such as "transmission error". Or is there a flaw in the
<br>authentication or<br>authorisation process that generates a 'real' false negative?<br><br></blockquote></div><br>
------=_Part_205166_14006603.1179225525502--