My Shopping - But Its Not My Card Thats Been Charged?

CrazyRed

JustKeepSwimming wrote: »

This gets stranger & stranger.....

Had my c/c statement & the transaction appears on it, having taken 5 weeks to get processed through the system. So at least some other poor soul hasn't been charged for my shopping.

I queried it again with my c/c company - who tell me that they've never heard of this happening & can offer no explanation why the last 4 digits are wrong. They say the time delay between buying my shopping & appearing on my c/c is unusual, & having been shopping at this national chain for years (in different branches) it certainly hasn't taken this long before.

I wish someone could explain it all to me but I don't think I'll ever find out how it all went wrong :rotfl:

I can only speak for the (national) retailer I used to work for and help manage their (in house) CC system.

With credit card systems, what happens is that there are actually TWO transactions. One to "authorise" the transaction and then to "settle" the transaction. Anything "authorised" will hold the funds against the customer's cc account for 3-5 working days, waiting for the "settlement" transaction to be sent through from the retailer's system.

These are batch processes that run very late at night and the Banks have a pretty narrow "settlement window" in which they expect to receive each merchant's "settlement" transactions. If the settlement transactions are not received in that window, the Bank will reject the settlement file completely and insist on it being resubmitted. The problem is that these files (which are in a 'standard' payment file format) have dates and times, and a sequence number in the 'header' transaction, plus a count of the number of transactions versus date in the 'footer' of the file. These two dates and sequence numbers need modifying (normally manually, and it's a pretty exacting process) before resubmission (the following evening - remember what I said about 'settlement windows' above) and, if anything is wrong, the Bank will reject it again, meaning more amendment and resubmission is required.

It is also possible that the software that converts the "transaction" file into a "Pay" file stopped working for some reason during the process and thus the "pay" file was incomplete - this, too, is rejected by the Bank.

What I suspect happened is what happened to me one time. The settlement file got rejected because the software had failed during the conversion process, producing 3 or 4 fragmented files and my colleague just resubmitted the one "rejected" file (as per procedures) and then called me out after the second rejection. Unfortunately, what he didn't realise was that he'd actually resubmitted the WRONG file - he'd resubmitted the previous day's transactions that, fortunately, had already been marked as "settled" (it's one character on the settlement line that is changed automatically by the software when it's been submitted to the Bank) and had also then archived off the current (unsubmitted) files using an automated process. Part of the current file, we discovered from talking to the Bank, HAD been submitted and settled successfully, so it then meant there was a lot of work to be done to modify headers, footers and individual lines to ensure that a customer's card was not debited twice (an even bigger nightmare than not submitting at all!). To cut a long story short, it was "easy" to find the file that contained the £400k we were missing, but the "final" £10k was very tricky to find (the file was very small, compared to the 'normal' PAY files) and took a lot of searching through the credit card servers, then, when it was finally found, there was a lot of manual manipulation that had to take place to get it in a format that the Bank's computers were happy with. This took me nearly two weeks in all to do.

I've tried to give a high-level overview of the process above, before anyone jumps all over me. The actual steps to be followed are quite specialised and normally required an EFT consultant to deal with - someone that understands the specific server/software setup of the retailer, and the specific setup of the "Pay" files that the Bank systems require. These guys (I know from experience!) are neither cheap, nor immediately available - the task is beyond most IT specialists, even third-line support guys.

My guess is that the settlement software failed and fragmented the "Pay" file, meaning that a specialist had to be called in to make the necessary modifications and resubmit the files for settlement. Under this scenario, I can understand a several-week delay.

To reassure other questions - the terminals themselves are "dumb". Yes, they do have software on them BUT that is only to instruct the PINpad on how to operate and where to send the authorisation/settlement data. They have no in-built memory that could hold a previous card-holder's number. Each transaction has a unique identification number for the authorisation and settlement transactions and these two numbers MUST match for the Bank to debit the customer's cc/dc account and credit the retailer's account. This unique identifier is issue by the authorisation server when it receives an authorisation request and is sent to the computer attached to the PINpad.

HTH