Storing credit card expiry dates

[Eileen]

We are working with eWay which offers tokenised billing. If you are doing token billing you can query eWay to get details about the token - including the credit card expiry date. This is useful because it allows a follow up to be done before the tokens expire. It makes sense to store this, report on it & do follow ups based on it. PCI requirements state on the one hand that you are not to store credit card expiry dates - but on the other hand eWay freely provide reports on this back to us. So, where so we stand on storing this information provided back to us? Can we store it in CiviCRM?

Per EWay :

"Certainly, if you are using our Token Payment API can make the call QueryCustomer. This call will show you all of the token customers information such as their masked credit card number and full credit card expiry date. "

[Eileen]

OK I spoke with eWay and was directed to this
https://www.pcisecuritystandards.org/pdfs/pci_fs_data_storage.pdf

Which states

These data elements must be protected if stored in conjunction with the PAN. This protection should be
per PCI DSS requirements for general protection of the cardholder data environment. Additionally, other
legislation (e.g., related to consumer personal data protection, privacy, identity theft, or data security)
may require specific protection of this data, or proper disclosure of a company’s practices if consumer-
related personal data is being collected during the course of business. PCI DSS, however, does not
apply if PANs are not stored, processed, or transmitted

ie. - if not storing credit cards PCI does not apply to the expiration date - this appears to be borne out here

https://www.pcisecuritystandards.org/documents/PCI_DSS_v3.pdf

The primary account number is the defining factor for cardholder data. If card holder name,service code, and / or expiration date are stored, processed or transmitted with the PAN, or are otherwise present in the cardholder data environment, they must be protected in accordance with applicable PCI DSS requirements

PCI DSS requirements apply to organizations and environments where account data (cardholder data and/or sensitive authentication data) is stored, processed or transmitted. Some PCI DSS requirements may also be applicable to organizations that have outsourced their payment operations or management of their CDE
1. Additionally, organizations that outsource their CDE or payment operations to third parties are responsible for ensuring th
at the account data is protected by the third party per the applicable PCI DSS requirements

My understanding is that in the context of token payments the CDE - or Cardholder Data Environment is the eWay environment (ie. on their server)

[Eileen]

Following on from this - my preferred option as to how to store this information would be to add a follow-up-date field to the civicrm_contribution_recur table. I would simply expose it as a field which could be edited & searched and people could populate it as they see fit - or a payment processor extension (eWay) could utilise it. I like this because I think it makes sense to be able to record when you want to do a follow up

My second choice is probably to schedule an activity for the follow up in an extension - this should be relatively easy to search & report on - with the main problem being to ensure it stays in sync with the parent action (this would rely on correct hooks being intercepted so that any alterations to the recurring contribution such as it being cancelled were picked up). Looking at existing activity types I couldn't see a type for when recurring contributions are initiated - only updates.

Perhaps more significantly the activity types that exist do not link to the recurring contribution entities. Activity Types connect with entities such as contributions based on component_id which is too brittle for linking to an entity type within the contribution component. This might make make approach this hard work - potentially requiring a custom field to store the linkage which is not something I'm exciting about doing in an extension - I guess I could still use 'source_record_id' even if the activity type doesn't know about it Not sure about any pitfalls there

[Dave Greenberg]

It seems worthwhile to provide a mechanism for sites to report on and remind recurring contributors that they need to update their card info. If the purpose of the date field is to store the actual expiry date, then it seems best to just call it that. On a related note, Jamie McClelland is stepping up to create a Recurring Contribution report for 4.6 - so it would be great if these two changes are coordinated.

https://issues.civicrm.org/jira/browse/CRM-15453

[Eileen]

ie. just add expiry_date to the contribution_recur table & add to advanced search, backend forms & reports?

I had thought about follow-up because I seemed people might like to schedule follow ups according to their own criteria and because I didn't know if different payment types would want something more generic - but I don't have a strong opinion on it.

[Dave Greenberg]

Follow-up date seems like a different property.
RE: adding to advanced search, would want that to only be exposed in the form if 'Contribution is Recurring' is YES.
RE: forms, I think it's exposed in 'Update Recurring ...' form and obviously in form which creates the recurring in back office. Otherwise shouldn't any place we show that be read-only ??

[Eileen]

In the advanced search there is already a recurring sub-tab of contribution with the recurring date fields - so adding it there should be fairly obvious / trivial.

& I think we are in agreement on the forms.

I'm trying to think who else to ping to try to solicit input before tackling

[Dave Greenberg]

A chat w/ Jamie might be good since I think their orgs do a lot w/ recurring contributions. Also Max at EFF and possibly Alan Dixon and /or Karin Gerritsen (and maybe they can query their iAts contact).

[adixon]

Yes, I've been storing credit card expiry dates, as well as the last four digits, in my custom tables for the iats extension, and it does make sense to build this into core in some way.

My reason for also including the last four digits was to cover a case where someone phones up an organization and wonders why their credit card was charged - by having the last four digits, it makes it easy to do a search and find the corresponding transaction.

And yes, iATS agreed with Eileen that storing these bits of information is not changing the PCI requirements (but that's really a big separate discussion, especially considering the upcoming changes to the pci rules ...).

On the other hand, not all payment instruments have an expiry date, and not all of them would necessarily express themselves in the same way (i.e. year month). I suppose debit cards do have an expiry date, but as far as I know there's no expiry for an ACH/EFT recurring transaction.

So, rather than adding more fields to the contribution recur table that are only useful in some contexts, I'd prefer to start building from a new model that makes things less credit card centric.

That would be the model where we have a subclass of the payment object for each payment instrument, and build all the payment processors as either subclasses of those payment-instrument-specific classes, or for weird things like paypal or other non-standard payment processes, build them as subclasses of the generic payment object. Then all the credit card specific stuff (and paypal stuff ...) is in the right place and not in random pieces of logic sprinkled through the code and templates ...

Once we've got a structure like that in place, it makes much more sense to start building the kinds of advanced administration stuff you're talking about.

In the meantime, on a slightly different tangent, I've also got some advanced requirements for management of recurring contributions for a couple of medium/large clients and am thinking about an extension which might make sense to roll into core for 4.6, I'll post separately on that when I've got something to show for it. Management of recurring contributions and recurring contribution donors is pretty important for medium-large organizations, and after seeing what these clients need, I can see that CiviCRM's current capabilities are pretty limited.

[jamie]

Hi all - thanks for moving this forward Eileen. We discussed at PTP - getting the expiration date would be nice - but in our experience, our users already get notices of expiration from the payment processor, so it's not super critical. Also, I don't have strong opinions about how to implement it - although I think Alan is right - the field doesn't make sense for wire transfers. I would be fine with either the subclass approach, or to go back to the more generic "follow up date" which would be relevant for any recurring contribution.

I am glad to see Alan's additions to https://issues.civicrm.org/jira/browse/CRM-15453 - particularly the ability to search just recurring contributions (regardless of whether or not there are associated contributions). I think we should add this to core - it seems like important functionality for anyone doing recurring contributions.

[Eileen]

Yes, my thinking about expiry date vs follow up date is that expiry date is credit card specific whereas for say a manual processor it might be something you configure according to organisational rules. But perhaps an optional expiry date is the best.

In general re the payment classes my problem is not so much the need for sub-classing as for clearly defined uses for the main functions - as they are not that clearly defined there is sort of a case for just creating new ones (and I've created a couple of api that do the generic stuff ). As you know I would prefer to stop writing new payment extensions & write Omnipay plugins instead & have all the wierd & wonderful stuff handled within the Omnipay wrapper

[Eileen]

I've created an extension to handle storage of expiry date & related apis
https://civicrm.org/extensions/payment-tokens