USB card swiper support

[jcm55]

I've implemented this by overriding CRM/Core/BillingBlock.tpl and inserting a "CC swipe data" field just before the card number field.  That field has an onkeypress attribute set which calls some javascript at the end of the template to parse the CC track data and insert the values into the appropriate fields on the form.  This part works very well.  Just position your cursor in the "swipe data" field, swipe the card in the USB reader, and voila!  CC fields all filled out with data.

The javascript also takes some other actions like:

- set the participant role to "Attendee"
- set participant status to "Attended"
- set the source field to "Walk-up ticket sale"
- insert the cardholder name into the contact field

I've been testing this custom template with this URL path:

civicrm/participant/add?reset=1&action=add&context=standalone&mode=live&eid=[eventID]

Appending the "eid" param loads the form with a specific event already selected.

With the custom template and the mode and eid params appended to the URL, I am getting pretty close to a decent live POS screen for credit card payments.

My customized BillingBlock.tpl is attached.  The javascript that actually parses the CC track data is from here:
http://www.acmetech.com/blog/magnetic-track-data-parsers/

[Donald Lobo]

very cool indeed

thanx for sharing

lobo

[kmarkley]

This is really awesome.  I can't wait to try it out.

How/where do I need to install the javascript?

[jcm55]

Sorry if I wasn't clear -- you don't need to download the code from the acmetech.com link.  It's already included in the modified BillingBlock.tpl I attached to the original post. 

The link is just for full disclosure about where the included swipeParser code originated from.

-j

[kmarkley]

Just to double check, this needs a keyboard-emulator-type reader and not a HID-type reader, correct?

[kmarkley]

Hm.  Also just noticed that the swipe field appears on public-facing registration pages for any logged-in user.  I think this is a small problem.

Instead of checking for the session userID, is there a variable to check whether the block is being displayed on a front-end vs back-end form?

[jcm55]

Yes, this is designed to work with a keyboard emulator card swiper.

Just did a little poking, and I think {if $accessContribution} might be a better check for including the swipe field or not.

[kmarkley]

This is so great.  Thank you again.

I did some poking of my own. {if $accessContribution} works for event registration, but the variable isn't available in regular contribution pages.  Seems like {if ! $urlIsPublic} is the most obvious/direct way to make the field (and javascript) available on admin pages and not public-facing pages.

I've attached an updated version with this change and the addition of a little help text for users.

If this feature were globally enabled/disabled, might it qualify for inclusion into core?  I find it incredibly useful and image others would as well.

[kmarkley]

I've been having some more fun with this. 

Here's a new version with some small improvements:

- Parses middle name if there is one
- Converts names to Proper Case

And a couple other minor changes:

- Changes the source field to 'Walk-up transaction (swiped)' so it makes more sense in a contribution/membership form
- Disables inserting the cardholder name in the contact field. Until we can make it check for matching contacts, it does more harm than good.  Looks like the form is ready to submit, but it throws an error every time.  I just commented it out, so its easy to restore.

[kmarkley]

But wait, there's more.

Taking the example of the new shopping-cart feature, I have created a global preference setting to enable/disable the swipe field at:

civicrm/admin/setting/preferences/contribution?reset=1

which is stored in the DB and respected in contribution, participant, and membership forms.


I can't quite figure out how to make the new pref page appear on the admin dashboard or in the menus (except by adding it via UI).


(FWIW, I imagine that if we make progress on the other POS stuff, we'll definitely want to add a ticket exchange preference to the event prefs.  Likewise, once we can do live CC transactions on the same form as cash/check transactions, we may want a contribution pref for which is the default.)


Think this is good/complete enough to submit to JIRA?

[Donald Lobo]

Kmarkley / Jim:

Too bad that either / both of u'll cannot make it to the sprints before OR after CiviCon. Would love to get some more of the stuff that Jim has done into the core system. Please do try and see if u'll can make it to 3-5 days of the post sprint

Kmarkley: Yes, you should file an issue and attach the patch. Ideally we should figure out how to get something like that as an extension. Cant think of how to easily do it, but definitely food for thought.

lobo

[kmarkley]

Patch filed here: http://issues.civicrm.org/jira/browse/CRM-9904

I get a kick out of figuring stuff like this out, but I don't really know what I'm doing.  In this case I used the shopping cart feature as an example of setting and retrieving a global preference and examined the variables in the smarty {debug} output to trace how (and where) to make the preference available in the template.

My point is that if some already wrote an extension that created a preference and passed it to a template, then I might be able to crib that work for this purpose, but there is zero chance I could do so from scratch.

So, I'm not available for the sprints, but even if I were, I would be basically no use to anyone.