1 of 1 people found this helpful
We use campus cash cards as a secondary payment type, but with 30k users it's not possible to add the info manually. Besides a batch load, is there anyway to allow users, for example through MyPrintCenter to add cards to their accounts?
That sounds useful too. Thank John.
And while we are asking, how about additional emails via MyPrintCenter as well!
Gerald, could you use either of the custom fields for these? Have a login script written to first check for matches in the Card ID field, then Custom 1, then Custom 2?
You'd be able to batch load them by fields, too.
As far as I can tell, at this point, the card number field is for one card ID number. It seems from my experience with the Card ID number, it is a one to one, unique association with the Login ID (username). For example, if jdoe has a card ID of 11223344, and you enter a card ID of 11223344 for user jsmith, Pharos will not allow card 11223344 to be attached to both users. User jsmith will have a card ID of 11223344 and jdoe's card ID will then be blank. Atleast during batch userload uploads, that is what happens.
Having multiple card numbers might be a useful feature in future releases of Pharos.
There might be sort of a work-around to have multiple card numbers. It seems in the Pharos database, the card number field in the user table is a 255 character field. You should be able to enter anything up to 255 characters in the card number field. The two places that I can think of that uses card numbers is login and billing. Login might be a bit more difficult to handle with two card numbers. I think some of the behaviors already in Pharos to handle card number login is pretty much set. There is a script function that takes a card number and searches the database for the Login ID. If you have multiple card numbers in the card number field, I think the search function will get really confused.
However, if you are using the card ID field to do billing, maybe the billing script can parse the card ID field and figure out the different cards. Of course you will have to come up with a convention to enter the card ID and stick with it. For example, you could enter in the card ID field, "12345,67890", which could be interpreted as the user has card number "12345" and card number "67890." Or you could enter something like "ABC:12345,XYZ:67890". which could be interpreted as the ABC card has number "12345" and the XYZ card has number "67890." Then your billing script would have to get the card ID field and do the work of parsing the string to figure out what card numbers goes with which billing account. Then the script would have to execute the transaction to each billing unit with the respective account/card number.
Again, since the card ID field is just a 255 character string, I don't see why the userload utility cannot update it as long as you come up with the complete card ID string to upload, eg. "ABC:12345,XYZ:67890." You cannot just say, "add card number 67890 to whatever is in the present card ID field."
I have not completely tested this theory, but for the most part I think it is plausible for it to work. I don't know if Pharos condones or thinks this is kosher, but I thought I would throw it out there...
Santa Clara University
The other piece of this would revolve around whether or not you are using the Pharos DB for banking. Third party banking software would have to be able to interpret the user as having two different accounts associated with two different numbers. I know that the version of CBORD we use at CU can associate multiple tenders with the same account, i.e. two different balances, but I'm not sure if it can handle multiple card numbers, associated with different balances, with the same user.
"You can charge some of the accounts all of the time, and all of the accounts some of the time................................."
The card number is still a one-to-one with a user. One card belongs to one user. But users can have multiple cards. Kind a like Starbucks gift cards.
These are interesting approaches to resolve this issue. We are using Card number for logging into our Copiers identifying the user via the card number. In other cases, we are using username and password. I like the idea of using the Custom fields if they could be used. I suppose that iMFP would have to be programmed look at the custom field during login.
Maybe Pharos Support can chime in on what is possible. What scripts can be modified to look for multiple cards.
Gerald, we set up our system to use a login script to differentiate between three different types of ID number in the Card ID field.
The script parses the track 2 data for a 9-digit number beginning with a 7, a 7-digit number, or a 9-digit number beginning with a 9. We have yet to move to a card-based campus ID system that is unified, but at the time we implemented Pharos in summer of 2011 we supposedly were headed that way (we still haven't been issued staff photo ID cards in any coherent way). The first number is our staff ID; these always start with 7, because UCSC is the 7th UC campus, I think. And they're always 9 digits long. The second number is our student ID number, which is associated with the photo ID all students get when they start here. They *currently* can swipe and enter their seondary PIN, but we don't advertise because we don't want to have to explain to faculty and staff why *they* can't swipe, etc. Political games, as it were. The final number is for our functional accounts, which we distribute for course cards, lab cards, and departmental general cards (for guests to the department, etc.). These are numbered by us and held in our database.
If you had a login script that parsed on touch or swipe, you might be able to have it look at card ID to start (IIRC it does a find for the number pulled from track 2). The find could be configured to look in card ID, then in custom 1, then in custom 2, with exits if the number is found. As far as I can tell in my reports all data is keyed to the login ID, so it would associate properly for billing. All the login script is doing is looking for a number to be found, to have that part of the login sequence validated...
The iMFP programming is held in the login script, rather than on each iMFP, by the way.
Thanks for the information about the iMFP programming and login script.
The Card ID field currently only allows 1 and only 1 value to be stored within it; however, Pharos can be configured to allow individuals to use more than one payment source.
We use the Pharos Station software at almost all of our release stations (the exceptions being MFD's). We have the Pharos Station configured to split out the login and payment into two steps. By separating out the login event from the payment source event there's a bit more flexibility in how a print job is paid for. We utilize Blackboard Transact as our backend payment system and have our environment setup so that patrons can use either their university ID card (which has a single unique ID number encoded for each user), or any other valid payment card such as their friends university ID, a generic print/copy card, etc.
From an automated provisioning standpoint we only provision the Card ID field with their personal university card encoded value; however, there's a big 'gotcha' about that. Regardless how you provision your users within Pharos if you require your patron to login first (e.g. AD username/password) and then swipe their card as a payment source then the Card ID field will always be updated with the value of the card that was swiped, even if the card belongs to someone else (actually from what I recall talking with Pharos Support the Card ID field is almost always updated for each transaction). For situations where the card swipe is used as both a SSO, and payment source (e.g. MFD's with a card swipe) then this will cause issues as more than one Pharos identity could have the same card ID value, even though the database referential integrity checks tries very hard to avoid that.
The solution that we came up with, working with the folks at Pharos, was to store the patrons ID number (not the card encoded value) into "Custom Field 1", and the card encoded value into "Custom Field 2". Since Pharos doesn't automatically update these fields in its normal processes its possible to use these as control fields in writing provisioning, login, and billing scripts to account for patron identification. If you're not using the card as a SSO data source than you can skip this configuration logic.
The billing script essentially just checks against the Bb Transact system to verify the card is valid, and has funds available. It doesn't care who it belongs to, and doesn't even need to be associated with the patron in any way (e.g. generic campus print cards).
Hope this helps with some ideas,
Thanks for your reply Chris. There are more options than I was aware previously.
A few things to keep in mind. First, the suggestions of using custom1 and/or custom2 for additional card IDs is what I usually suggest. Just be careful because these fields are not forced to be unique, so it could be possible for two different users to end up with the same card ID, which would obviously lead to issues. This is why the default card ID field IS forced to be unique. So, using the multiple fields for multiple card IDs is doable, but there will be things to consider. First, auto card registration from the iMFPs will ONLY work using the default card ID field. So, if you want to use multiple fields for cards, you will need a script for authentication, and auto card registration may not work as expected. On the other end, you may need a billing script as well. Although multiple cards may be used for authentication, it is likely that the billing system only knows ONE of these cards as being the valid one. So, this valid card number needs to be the one that ends up in the default card ID field, or a billing script would be needed. I have done many variations on this theme so it is possible to do, but as most things, the devil is in the details. I am happy to give additional suggestions and/or advice if someone wants to explain a specific example of how the different card IDs would be used for both logon and billing.