Standard for declaring Card-presentness

[eileenmcnaughton]

EWay recurring has a weird set up when you can store a token to represent the credit-card of a customer. When you re-use it you are expected to do things differently depending on whether the customer is re-using it or whether you are doing it in their absence (MOTO, or recurring payment don't require the CVN to be re-entered but if the customer is re-using their card they are supposed to re-enter it).

This is causing some difficulty for me on the recurring side - it seems I can set 'transactionType' to 'MOTO' or 'Recurring' and (with some other changes I will need to make) that will work. However, that doesn't seem to be a generic approach - ie. AFAIK there is no standard for setting transactionType that is generic across gateways. Obviously I'm looking for something that I can put into my calling code that doesn't require it to know the vagaries of each gateway.

I feel like there should possibly be a standard function like

$request->setIsCardPresent(FALSE);

or similar.

I note that this probably doesn't warrant being added to the abstract class but at least if there is an agreed approach somewhere I can point to it when I try to get it added to the gateways I use

[judgej]

Would it be better to standardise on multiple values rather than a boolean? The card may be present if scanned into a machine (which some APIs support, but not all), but all other operations are "card not present". I'm not sure if having the CVV available to be entered means that the card is present.

The purchaser may have the card in their hand, and can enter details into an e-commerce application. They may be able to read the details to someone on the phone, so someone else types it in, or writes it onto an order form put in the post. They application may also have a continuous authentication set up, where no further details are needed.

I think what your setIsCardPresent() is really alluding to, is whether the card owner is present. The card owner can enter the CVV, or tell the telephone operator the CVV, and for e-commerce transactions they can enter 3D-Secure details.

These different operations normally (or often?) need to be sent to different merchant accounts, as they can be billed differently. Sage Pay has three account types:

• "E", E-commerce: card owner present online; 3D-Secure supported; saved tokens may be used.
• "M", MOTO: card owner MAY be present; NO 3D-Secure; saved tokens may be used.
• "C", Continuous authorisation; card owner not present; repeats a previous approved transaction.

Those are just three account types. How do they compare to other gateways?

[eileenmcnaughton]

Those 3 types map pretty exactly to eWay - who have MOTO, RECURRING & I think PROCESS PAYMENT.

I would shy away from calling the variable transactionType as that is used in various gateways already - although I totally can only think of transactionType as I type this

[judgej]

Agree transactionType is pretty much taken up for other purposes across many gateways. Sage Pay calls it accountType, because each maps onto a different merchant account. But it's more than that. It also triggers some UI and functional differences, since the phone operators can't use 3D Secure, and don't want the branded form templates that the end customer may get. Also the recurring payment, depending on how it is implemented, may not have a CVV present.

[eileenmcnaughton]

Right - so there are possible 2 variants on recurring? For eway the code would do something very different if the cvv is not present - ie. call a 'different gateway' - the Direct gateway as opposed to the Transparent Redirect (same credentials can be used for either).

I feel OK with your definitions. We could just go with something like cardTransactionType?

Where / how would we document?

[judgej]

Authorize.Net introduces another option for their "business model": retail. That would be for use with card scanners, perhaps hand-held card machines. In that case it would be "card present" and the user would be there to enter a PIN if required for larger purchases, but no 3D-Secure would be involved.

[eileenmcnaughton]

I submitted a proposed readme change & how this could be used in eWay - see links above

[judgej]

We can check if a card magnetic stripe has been scanned, as the track1 or track1 is present. Are there contactless scanners that can provide data instead? If so, what data is provided and do any gateways e-commerce support it yet?

I'm trying to work out what problem this solves, and just what the scope of the problem is.

[eileenmcnaughton]

so the issue is that eway enforces different rules about whether cvv is required depending on whether it is E-Commerce, Moto or Continous (it's the last I care about). You need to let eWay know which it is. The other alternative is for the plugin to make an assumption based on whether you provide the cvv or not

[judgej]

Would be good to get this closed off. Do we have a list of gateways that we know would make use of this setting, just to get an idea of how widespread it would be?

I've always thought that Omnipay needs recommendations for elements that are used often, but are not yet in the interface or abstracts. This feels like a recommendation at the moment, which may lead to something more format (an interface method, constants for allowed values, etc.)