I started off with a program I wrote called "billthedoubtfuls.cgi". When a card fails an attempted billing, and fails a couple of retries, it becomes what I call "doubtful". NAlso when a card is used for the first time and fail to be billed. Most of these are caused by excessive caution on the part of the bank - some American banks seem to think that any billing from any foreign country it likely to be fraud, and for a reason I don't understand, they could UK as foreign. Which, of course we're not, it's them that are foreign. Anyway, "billthedoubtfuls.cgi" is a mechanism for billing the very few cards that are submitted for billing, which are already in the doubtful category. Actually, the word I use is a lot stronger than "doubtful". Never mind.
I set up a file containing suitable fictional data, using the card number 4111 1111 1111 1111 which is the card number that is universally used for testing. And then I created a new version of billthedoubtfuls to try the billing. My working documentation was "ePDQ technical MPI reintegration guide" (ePDQTRG), which was written by BMS to help people like me who are trying to migrate from the old system to the new one. It explains that the old ePDQ MPI (I have no idea what that stands for) is going to be replaced by DirectLink.
It says that "the integration is less complex". I don't think so.
So, page 5 of ePDQTRG is entitled "What do I currently send to ePDG MPI. And it give a sample. But the sample omits the "CLRCMRC_XML" that you have to put in the font (I can't remember why, or how I discovered that) and it omits the "<?xml version="1.0" encoding="UTF-8"?>" that follows it. That's stuff that I call "throat-clearing", before the meat of the data is sent. And it's sent to port 11500
So when I turned to page 7, and there was no "throat-clearing", I thought, maybe they've forgotten it here, too. Also, on page 5 they give as their example transaction type "auth", which means "Authorise and make a sale". On page 7, they translate that to "auth", which (I think) doesn't mean the same thing in the new system, what I actually want is "SAL" meaning Sale. And page 10 of ePDQTRG it definitely says that the old AUth translates to the new SAL.
So then, where do I send this data, and using what port? It tells me to send it to https://payments.epdq.co.uk/ncol/prod/ and it doesn't say which port. And that turns out to be *SO* wrong. It turns out that they should have said :
But even that is wrong.
The next documentation that I got hold of was "Integration Guide for the Server-to-Server Solution v 4.3.3 (IGSSS). Part 3.1.1 gives the correct URL. Actually it gives two.
Production environment: https://payments.epdq.co.uk/ncol/prod/orderdirect.asp
Test environment: https://mdepayments.epdq.co.uk/ncol/test/orderdirect.asp
I started off using the Production environment. After all, I'm using a test credit card, and I expect it to be refused. And I wasted a lot of time on this before I finally realised that, actually, BMS haven't enabled the Production environment for me, and won't until I've got everything working using the Test environment. And test and production, are on different servers, I guess, so I have different userids and passwords for each. So I stopped trying to get the production working, and just worked on the test
As you can see, thus far I've made very little progress. Mostly, I've just been distracted by contradictory documentation, and wrong information. And, of course, when I called BMS for tech support, I can only talk to front line tech support (who, of course, know very little), and they can ask the real tech people to call me back, which happens within 24 hours.
A 24 hour turnaround for questions when I'm trying to write software? I'm groping in the dark.
So I made a list of questions. For example, the IGSSS says that CVC (the three digits on the back of your card) is "mandatory", but PCIDSS rules say you're not allowed to store the CVC, so I don't. So I can't give it.