Re: Self-service checkouts 'have not cut supermarket queues'

In article <253a5e7f-083d-475f-a37f-00e95fe975b8
@g6g2000yql.googlegroups.com>, ste_rose0@xxxxxxxxxxx says...
On 25 Aug, 14:44, Peter <pete.ivesAll_stR...@xxxxxxxxxxxxxxxx> wrote:
In article <795d77e1-9a43-401b-b7e3-7da977832118
@g6g2000yql.googlegroups.com>, ste_ro...@xxxxxxxxxxx says...





On 24 Aug, 17:48, Peter <pete.ivesAll_stR...@xxxxxxxxxxxxxxxx> wrote:

Amex cards have 15 digit long numbers in blocks of 4, 6 and 5.

So, if Maestro and Amex (and probably others) have more than the usual
4-4-4-4, there is obviously a need for websites to accept a goodly range
of numbers. Of course, you are also usually asked to indicate which type
of card you want to pay with, so the computer should know what number
format to expect (with or without the spaces), and be able to reject
anything wrong. Provided the spaces are ignored, there shouldn't be a
problem.

I certainly remember the original Barclaycard with its 4-3-3-3 format.
This actually gave me a problem in the USA (just the once), when
suddenly it was refused in a museum shop. The lady at the checkout said
that the strange format was probably the cause, as she thought that all
American cards had 4-4-4-4 as standard. [Maybe Amex did too, at the
time.] Soon afterwards, Barclaycard replaced their cards with 4-4-4-4.

It's ironic that the more we discuss this subject, the more the case
for standardisation and parsing code libraries is made. Already, it
has become clear that no one person here possesses enough knowledge on
their own to successfully parse and perform a cursory validation on
some of the most commonly inputted customer data.

True, but the information is out there and shouldn't take that much
research to discover.

To say this, you cannot possibly have any experience in this area
Peter.

On the contrary, I wrote an ecommerce website for a local cleaning
supplies store from scratch last year, so I had to find the very
information you are referring to via the internet. The website had to
process all CC details and then forward that information to Sagepay who
would then process the card information supplied by the site,
communicate with the cardholder's bank and then respond with an ok or
rejection.

So I had to write the php code that had to validate each card type and
inform the user if they had entered their details incorrectly according
to the type of card they were wanting to pay with or continue on to the
next stage in the process. It wasn't the most elegant of sites, and if I
had the time again I would probably change a few bits, but it served
it's purpose and the payment processing still works today.

So, like I stated previously, the information is out there.

Ok, so exactly how much time *did* it take to research and write the
code, and what types of data did you validate, and how complex was the
validation?

Did it, for example, perform the level of verification achieved by
this postcode regex:

(GIR 0AA)|(((A[BL]|B[ABDHLNRSTX]?|C[ABFHMORTVW]|D[ADEGHLNTY]|E[HNX]?|
F[KY]|G[LUY]?|H[ADGPRSUX]|I[GMPV]|JE|K[ATWY]|L[ADELNSU]?|M[EKL]?|
N[EGNPRW]?|O[LX]|P[AEHLOR]|R[GHM]|S[AEGKLMNOPRSTY]?|T[ADFNQRSW]|UB|
W[ADFNRSV]|YO|ZE)[1-9]?[0-9]|((E|N|NW|SE|SW|W)1|EC[1-4]|WC[12])[A-
HJKMNPR-Y]|(SW|W)([2-9]|[1-9][0-9])|EC[1-9][0-9]) [0-9][ABD-HJLNP-UW-Z]
{2})

That's from Wikipedia and took me a few moments to find through a
search on Google, but the only reason I knew it existed because I'd
already researched the issue in the past (and on that occasion, it
effectively took an hour just to stumble across it serendipitously).
Obviously, that does not include the time taken to actually write or
test this code as part of a program.


Yeah, probably I was over generous with the statement about it not
taking that much research to discover. However, I don't recall spending
hours hunting for it either. During the time I was also trying to figure
out the payment processing gateway that SagePay were providing and I
recall I spent more time trying to understand the workings of that
payment gateway, ie the specific data that was going to need to be
passed back and forth in relation to successful transactions as well as
unsuccessful transactions and how to deal with every eventuality related
to those, whereas the details about postcode formats and credit card
formats I just happened upon during that time.

SagePay are also generous, in that they provide pre-written scripts
which helped in some areas, but didn't in others and I still felt the
need to write my own during this time.

--
Pete Ives
Remove All_stRESS before sending me an email
.

Relevant Pages

  • Re: Self-service checkouts have not cut supermarket queues
    ... of card you want to pay with, so the computer should know what number ... their own to successfully parse and perform a cursory validation on ... some of the most commonly inputted customer data. ... I wrote an ecommerce website for a local cleaning ...
    (uk.legal)
  • Re: fuji s7000 1gb xd problems
    ... work fine with my camera. ... I did format the card in the computer after ... Also according to Fuji's website, ...
    (rec.photo.digital)
  • Re: New keyboard problem with new ROM
    ... > I update my calc from a 128 MB card just fine. ... FAT16 with 2KB clusters, there's a slight ... If I format it FAT32 with 512B ... for typical calculator uses I'd recommend the cheapest SD ...
    (comp.sys.hp48)
  • Photos
    ... Once you have one opened then go to Format> Format ... provide a link to the website so we could help you with any issues. ... Read the instructions. ... page you will import will be 2250 pixels long. ...
    (microsoft.public.publisher.webdesign)
  • Re: MCE 2005 w/ Rollup 2 AND HDTV
    ... The signal that is broadcast is compressed and encoded in MPEG2 format. ... The cable companies use the same ATSC resolution formats when they are ... HDTV tuner card. ...
    (microsoft.public.windows.mediacenter)