Card present support for AIM & CIM

[anush]

Adds support for card present transactions for the AIM & CIM gateways. Card present transactions typically offer better rates and lower declines.

A card present transaction means that the physical card is present and the magnetic track data is available to you. For the card present logic to kick in, just set the tracks property into the credit card object.

[judgej]

👍

[judgej]

There are still a few merge conflicts to resolve.

[judgej]

Hi @anushr I know this is very old, but I am working on merging it in. I've fixed the conflicts, but - if you are still here and know the answer to this - have a question.

The AIM authorisation will assert that a CreditCard has a CC number and an expiry date before it checks whether tracks have been supplied. The way I understand the way the tracks work, is that the tracks completely replace the need for a CC number of expiry dates to be sent to the gateway. So a CreditCard object with just tracks but no CC number will fail.

It happens that the test suite always provides a "valid" credit card object, which includes valid CC number and expiry date, so the tests may not have caught this as a problem.

But I may be misunderstanding this entirely?

The line in question is here:

https://github.com/academe/omnipay-authorizenet/blob/pr36/src/Message/AIMAuthorizeRequest.php#L43

I think that check needs to be moved to the else condition, so it is only asserted if there are no tracks supplied. What do you think?

Thank you for your effort here - it is all good stuff :-)

[judgej]

Found this:

A stripe on the back of a bankcard that contains magnetically encoded cardholder account information. The name of the cardholder is stored on Track I and the account number and expiration date are stored on Track II. Also referred to as MAG STRIPE.

So I guess the card number is not required if the tracks are supplied. Or maybe more accurately, if track 2 is supplied. From what I have seen, either track 1 or track 2 can be given in the transaction, but not both. The Authorize.Net documentation states that the card number and expiry are in both track 1 AND track 2. It also states:

If you use the track1/track2 element, do not send the creditCard element.

So that probably settles it: the Omnipay CreditCard object should only be validated if the card is NOT present. I'll fix that with a test to match.

[judgej]

I've extended this PR #36 through PR #89 with the aim to getting it merged. I'll leave it a few days to see if there any comments or observations, while working on a few of the other PRs.

[anush]

#89 looks good @judgej -- thanks!

I'm closing this one in favor of #89

[judgej]

When I merge #89 github would automatically show #36 as merged anyway. It's clever like that :-)