queryCard function?

[fryiee]

I note that the Rapid API has a very useful queryTokenCustomer method for getting information from a create token (masked CC number, name etc). Was wondering if there are any Omnipay / this package functions I could hook into to add a RapidDirectQueryCardRequest? At the moment, I'm adding the eway rapid API as a separate dependency just for this method.

[incarnate]

Good pick up, there isn't a query card in the Omnipay gateway interface (available token methods are listed here).

This would be a common method between many gateways so certainly a good addtion in the omnipay-common package. I'd suggest opening an issue or PR there - in the meantime I guess queryCard method could be added to RapidGateway directly.

[fryiee]

@incarnate good idea. I'll add an issue on the common and start drafting up a PR for that package and the implementation for eWay specifically.

[delatbabel]

It's a very rare function -- almost no gateways other than eWay support any kind of query function against stored card tokens. So any solution will be eWay specific.

[incarnate]

I wouldn't say that was true, a few minutes of googling returns APIs for fetching customer details for most gateways: Authorize.net, Stripe, Pin as just a few examples.

[delatbabel]

Fetch customer details is not uncommon. Fetch card details is uncommon.

[fryiee]

Wouldn't this sort of query be present in all gateways that provide token payments?

[incarnate]

Just to clarify, the eWAY API being discussed is to query a customer. Like most (all?) other gateways, eWAY does not return the full card number.

We might have some confusion since Omnipay only has a CreditCard object which happens to hold card and customer data. So to stick with the current convention (createCard, updateCard, etc.), queryCard is the suggested additional method.

[eileenmcnaughton]

This is my pr for support for the query function for a.net https://github.com/thephpleague/omnipay-authorizenet/pull/79 (just noticed it has a red x from CI :-()

[delatbabel]

If someone wanted to create a PR for this I would consider merging. However as I stated earlier it's by far the case that the majority of gateways don't support this type of functionality for PCI compliance purposes. If it's a requirement of your application that it stores masked card numbers then you should mask the card number appropriately yourself and then store that before calling createCard() -- use the masked card number that you create yourself as part of the identity to store the token.

That way you have the card number masked the same way regardless of how each gateway implements fetchCardDetails() or whatever. I can see a potential issue here where if an application stored tokens against multiple card gateways, then retrieved the masked card number using fetchCard(), and each gateway masked different parts of the card number, then too much information would be provided by checking each different gateway's masked card number.

I'm not trying to tell people how to write code, but using a gateway specific fetchCardDetails() function is not something that I would ever do for simple security reasons such as the above.

[eileenmcnaughton]

Just a quick note that if you are using transparent redirect you are not collecting the card on your site (or if using the js script). I'm pretty sure the last 4 digits (the PAN) is the main thing that is exposed during masking - although some seem to also expose the details to determine the bank. I don't think masking would ever expose anything else.

[fryiee]

Hi @delatbabel - investigating it seems that almost all of the gateways I looked at support returning the last 4 digits. The issue with relying on personally storing the masked card is it implies that I'll always be using a direct connection (ie taking in card details, requiring PCI compliance). Returning the last four digits would be supportable on both PCI and shared connections as it's coming from the gateway, not from my application.

[fryiee]

At most, all gateways will only return the first 6 and last four as stated in the PCI-DSS at 3.3: “Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed).”

[fryiee]

Is the concern that cross-referencing the masked cards would tell you what gateway the token was for? Or am I misunderstanding your security question?

[incarnate]

As noted earlier, eWAY (and no other gateway) returns unmasked card details, This issue is asking about adding functionality to fetch a customer (which in eWAY's case includes the masked card).

There seems to be some confusion because the issue is named queryCard.

[eileenmcnaughton]

Sorry - in your last comment you use masked & unmasked - you mean it actually returns the full unmasked card number as of the most recent eWay?

I just checked a site that has been using QueryCustomer & it retrieves a format like 41111XXXXXXX1111 which is masked - although it's more than just a PAN. It is similar to what is returned by Mercanet (& I believe SagePay) in the ServerNotification after you make a payment using transparent redirect.

[fryiee]

I believe he's saying that eWay is the same as all other gateways in that they ONLY returned masked card numbers, which supports the notion of queryCard function. The only difference (and I wager they're actually all the same) is in the number of masked versus unmasked digits they return. They should all be at maximum returning the max PCI-DSS allowed digits as above (first 6 - last 4).

[judgej]

@eileenmcnaughton I may be misinterpreting some of what you are saying, but a PAN is the full credit card number, not just the last four digits.

[delatbabel]

OK I think we can put this to bed now. Yes, there is no gateway specific fetchCard() function for eWay. If you want to submit a PR for it then please go ahead. As I said this is not something that I would use, nor am I going to code it for you.

[judgej]

Can I add one more thing that may be of use (then I'll shut up). Since eway have migrated to the realx platform to host their payment gateway, is there anything in the realx Omnipay driver that could directly provide the functionality that is being asked for?

https://github.com/digitickets/omnipay-realex

These white-label gateways that are proliferating in recent years are behind many of the branded gateways we see, and it is always worth looking "behind the curtain", so to speak, to see if there are more generic ways to access some newer gateways.

[incarnate]

Curious suggestion, but eWAY is entirely separate from Realex, they just have been bought out by the same company (Global Payments). The confusion may be because in the UK eWAY have closed down and migrated customers to Realex.

The issue here is that there is no way to query a customer/card in Omnipay, but perhaps that is an issue best raised in the main repo if a generic method is desirable.

[fryiee]

@incarnate I'll open an issue / PR there.

[fryiee]

@judgej eWay Australia is definitely not realex.

[judgej]

Okay - thanks for the clarification.