[bop-devel] Proposed - Barclaycard EPDQextra Plus API Direct Link Integration

[Simon Waters]

On 24/01/13 09:13, Ivan Kohler wrote:
>
> I would be happy to upload if otherwise it would not be available, but I
> would certainly certainly encourage you to go ahead get a CPAN ID and
> upload it yourself.  There is a minimum of bureaucracy involved, and you
> get a nifty gravitar and your own bug reports.
> http://pause.perl.org/pause/query?ACTION=request_id

Thanks,

error reporting will likely get some attention, Currently if it Carps it 
doesn't store the reason in the error_message. I think it should.

Amount currently has to have 2 decimal places. Some of my test cases are 
failing because they were passed as whole pounds, which the 
documentation says is allowed for Business::OnlinePayment

So will sort those items later today. Otherwise it seems to be passing 
tests I need (and Barclays allow me to perform - why are foreign 
currencies so hard for credit card processors to provision?) before we 
put it live for our own limited use.

I asked in PAUSE for the name "Business::OnlinePayment::EPDQPLUS" I hope 
that was the right thing to do.

Do/Should we have some standard tests for all modules? e.g. To ensure 
compliance with assumptions across modules like "Expiry date".

The parameter "eci" doesn't seem to fit nicely in the current scheme. 
Basically it is 7 for SSL transaction with card holder present, 9 for a 
recurring transaction. In our case we insist on a CVV2 when cardholder 
present, so we can set it to 9 when the CVC is not present safely as 
they are recurring transactions. Barclaycard allow you to set a default 
for this value if not present so it doesn't need to be mandatory. Don't 
think it is appropriate to encode logic concerning this as our logic is 
not general enough and requiring an ECI of 9 if CVV2 is missing might 
fail for those for whom this is the default.

  Simon



http://cpan.perl.org/authors/id/S/SR/SRW/EPDQPLUS.pm

Currently the raw "pm" file is there.

Changes in version 0.02 over original are:

Switch to SHA512 from SHA1 since it is probably stronger.
Remove blank parameters from hash
Make the hash optional as this eases testing hugely
Add test_transaction support
Added failure_status method as advised by Ivan
Add "_info" introspection
Added expiration handling of MM/YY as Ivan suggested.
Removed routines already in OnlinePayment.pm
Updated documentation

I'll do something prettier (More CPANesque anyway) shortly, although 
"Module::Starter" reports syntax errors in its tests when I asked cpan 
for it. Going to be one of those days I can tell.

SHA1 is the default at Barclaycard, users just have to pick SHA512 in 
the global security settings. I understand for this sort of purpose SHA1 
is considered acceptable still according to NIST but we have a choice of 
3 types of strong box for the armoured car from cardboard box to park 
bench, I see no advantage in using the two weaker ones.

Noted Barclaycard accepted sha1_base64 output but their own code does 
the equivalent of sha1_hex (or sha256_hex, or sha512_hex) in uppercase, 
so I made it do the same so the hash produced in DEBUG look exactly like 
the one's on their test page.

Main pain is the optional hash which if you get the string built wrongly 
will fail, with no way you can figure it out. Guess that is why any 
working implementation is always useful to work from.