CiviCRM Community Forums (archive)

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. "

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

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.

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

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.

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