Credit Card Swipe to Customer Select

[royh]

Hey, all. First time poster here, but longtime adorer of SambaPOS and the community.

I’ve been searching for a way to expand upon what was asked about here.

For my use case, I’d like to be able to select a customer by swiping their credit card from the Ticket Order screen.

After reading the topic I linked to above, I do realize that most of the capability is already there. When I swipe the credit card, it is entered into the number pad and performs a search. The problem is there are special characters in the credit card that are “breaking” the search. The offending character seems to be the caret ^ based on my testing. Here is the format of the string from the credit card swipe.

%B1234567812345678^DOE/JOHN^19012010000000080000000?;1234567812345678=19012010000008000000?

The way I discovered this was by adding a custom field to the Customers entity and adding the credit card swipe info there. I then went to the Customers Search screen and swiped the card, but the Customer entity would never show up until I removed both carets from the search field. Once they were removed, any characters before or after the carets would find the right customer entity by matching the custom field I created.

Ideally, I would not want to store any customer credit card data as I would prefer to avoid any potential liabilities involved with that. I would prefer to find a solution that takes that full credit card swipe string and parses it by looking for the carets and only using the data between them (LAST NAME/FIRST NAME) for the search. As a workaround, I’m just going to have our staff go to select customer screen and swipe the card then manually remove all of the strings before and after the carets as even that will help us by preventing us from having to type in the name.

My purpose for this is to speed up adding a customer’s name to our tickets when we are taking their orders. We run a pretty busy craft beer taproom and this would be a great help. We’re using Surfaces to take customers orders at their table and typing on those screens slows us down quite a bit. Especially because our bar is dark so it’s hard to read the names from the cards.

We are not using the magnetic readers to take final payment. We’re only using them to facilitate the assignment of customer names to the tickets. We currently use Square to take payments, but we will be switching to PayPal soon as Square does not work with Surfaces.

Thank you all.

[QMcKay]

Probably easiest to process it with JScript …

#Script

##CCS Processor [ccs] (Script)##

Script Name:	CCS Processor
Script Handler:	ccs

Script:

function processNumpad(c)
{
  var cParts = c.split('^');

  var customerName = cParts[1];

  var cNames = customerName.split('/');
  var cNameLast = cNames[0];
  var cNameFirst = cNames[1];
  //return cNameFirst + " " + cNameLast;

  return customerName;
}

---

#Actions

##CCS Store Value [Update Program Setting] (Action)##

Action Name:	CCS Store Value
Action Type:	Update Program Setting

###Parameters:###

Setting Name:	[:settingName]
Setting Value:	[:settingValue]
Update Type:	Update
Is Local:	[:isLocal]

---

##CCS Select Entity from CC Scan [Change Ticket Entity] (Action)##

Action Name:	CCS Select Entity from CC Scan
Action Type:	Change Ticket Entity

###Parameters:###

Can Create Ticket:	True
Can Create Entity:	False
Entity Type Name:	Customers
Entity Name:	[:entityName]
Entity Search Value:	[:entitySearch]
Update Null Entity:	False
Entity Screen Name:
Entity Screen Search Value:

---

#Rule

##CCS Numpad [Numberpad Value Entered] (Rule)##

Rule Name:	CCS Numpad
Event Name:	Numberpad Value Entered
Rule Tags:

Custom Constraint List (1):

Execute Rule if:

Matches All

Numberpad Value

Contains

^

##Actions (2):##

CCS Store Value

Constraint: (none)

settingName:	CCS_CustomerName
settingValue:	{CALL:ccs.processNumpad('[:NumberpadValue]')}
isLocal:	True

CCS Select Entity from CC Scan

Constraint: (none)

entityName:	{SETTING:CCS_CustomerName}
entitySearch:

##Mappings##

Mappings

Terminal	User Role	Department	Ticket Type
*	*	*	*

---

[royh]

Wow. That looks awesome! I can’t wait to set that up. Thank you very much for providing such a detailed response.

I can’t wait to start learning much more about this wonderful software. I’ve been looking for a great system such as SambaPOS for years. I held out hope and used what I could (spreadsheets and paper tickets) until I found something as powerful, flexible, and well supported as this. I hope to one day be proficient enough so as to make contributions to this wonderful effort.

Thank you again.
Cheers from Chicagoland!

[JTRTech]

Another thing to consider would be most tracks.
Some readers have option to only read certain tracks.
If I remember right there are 3.
I’m pretty sure that sting is multiple tracks as is allot of info for a single track.
Maybe only reading a single track might both deduct the string to record etc.

[royh]

The card reader we’re using and bought is a 3 track reader. I haven’t found any options for the device yet where I can limit it to read a specific track. I did see there are other readers out there that only read one track. We bought the 3 track readers just to make sure we could get the information we were looking for.

[JTRTech]

If it has the option it would be in the utility program if it comes with one or one is available.

[royh]

The mag readers I bought didn’t come with any other drivers nor proprietary software to set which track to read.

[royh]

Thanks again for your timely guidance.

I followed your instructions and implemented your procedures accordingly. Though I wasn’t able to immediately see that the Customer entities were added to the tickets until I added a menu item, or closed and reopened the tickets, as long as a customer was already stored with the same name format as was parsed from the credit card swipe, it worked!

Initially when I posted my question to the forums, I only had a limited amount of cards (my own) to test the formatting of the names read from the credit card tracks. Once more people came into the taproom, I was able to check the formatting of names from their cards as I was testing out your solution and I found out that the name formats were more varied than my initial tests revealed.

My cards were “LAST NAME/FIRST NAME”, but other cards I encountered were “FIRST NAME[space]MIDDLE INITIAL[space]LAST NAME/” and yet other cards were “[multiple spaces]FIRST NAME[space]MIDDLE INITIAL[space]LAST NAME/[multiple spaces]”.

With that said, at this early stage of testing format variations, I believe the most practical function to be used should not worry about the position of first name, middle initial, last name as their positions are shown to be non-standardized. What is consistent, so far, is that the name is delimitered with carets (^) and that there has always been a forward slash (/) between the carets. As such, and based on my limited javascript programming experience, I have tweaked the function you have graciously provided accordingly in order to handle the variations I have encountered so far.

function processNumpad(c)
{
  var cParts = c.split('^');

  var customerName = cParts[1];

  //replacing fwd slash with a space to separate name parts;
  customerName = customerName.replace('/',' ');

  //trimming the leading trailing whitespace as trim alone did not work;
  customerName = customerName.replace(/^\s+|\s+$/g,'');

  return customerName;
}

Now I may need to start another thread, but I’ll ask the question in this thread as it is relative to the overall solution I’m looking to implement. In advance of me noodling around to try to figure it out on my own tomorrow morning when I wake, can you or anyone kindly provide assistance, or point me toward a guide, that will help me implement a solution to create a customer entity with the parsed name from the credit card swipe, and then select that newly created entity, if an existing customer entity isn’t found upon searching? I tried selecting “True” from the “Can Create Entity” option from the “CCS Select Entity from CC Scan” action, but it did not work.

Thanks again for your help! I hope that my inquiry and more importantly your assistance will aid others looking to implement an efficient solution for mapping of customer names to “tabs” via credit card swipe in high volume, bar applications.

Cheers!

[QMcKay]

@royh

I wasn’t able to immediately see that the Customer entities were added to the tickets until I added a menu item, or closed and reopened the tickets

Put a “Refresh Ticket” Action in the Rule right after selecting/changing the Entity. This is actually a Display Ticket Action with the Ticket Id set to 0.

@royh

I tried selecting “True” from the “Can Create Entity” option

If you change the parameters of an Action, those changes do not propagate to the Rule automatically, so the Rule is not aware of those changes. After changing the Action Parameters, you need to remove the Action from the Rule, Save the Rule, Add the Action back into the Rule again, and Save the Rule.

[royh]

Thanks again, Q!

I removed, saved, added then saved the action to/from the rule, but I still wasn’t able to get the new Customer entity to create without also blanking out the Update Null Entity setting for the CCS Select Entity from CC Scan Action.

After digging around to try to figure out why it wouldn’t create, I found this screenshot from your reply to a different question which gave me the idea to try that out.

Thanks again!

I’ll keep updating this thread with tweaks to the parsing script should I encounter different CC name formats. For now, this will be a great help to us! Can’t thank you enough, Q!

For others thinking about using this type of setup. Keep in mind that customers often use different cards and thus may have different name formats therein resulting in one real customer having multiple customer entities. It’s really not that important as the positives of this type of setup outweigh the negatives of not unifying all the customer data appropriately, at least for us.

Once we start a loyalty program, however, we’ll have to try to figure it out. We may simply assign them their own magnetic cards that we can swipe or QR codes that we can read from their phone to get their customer assigned properly. Just some quick ideas.

Cheers!

[QMcKay]

You probably could have set Update Null Entity to True as well. I believe that is the “default” for that parameter if you leave it blank, it assumes “True”.

[royh]

That’s what I figured. I just wanted to line it up the way you had it in your screenshot.

[QMcKay]

See that’s the thing with the flexibility of the system…

Your initial question was how to select a Customer with a swipe card. So these parameters were not applicable, so I set them to False:

Can Create Entity
Update Null Entity

Then you decide you want to create Customers as well. In that case, we change the Action to set both of those to True.

Because of these things, it is also why I tend to use variables for every parameter in an Action, no matter if we care about particular parameters or not… like this:

If you do that ^ then you don’t need to remove the Action from the Rule every time you change a hard-coded parameter. It makes the Action more generic and flexible for use in any Rule …

[royh]

That’s awesome! Mind blown.

As I had mentioned in my original post, I’ve been looking for years for something as versatile as this. I’ve tried so many other systems and none of them came anywhere close to this. I’ve been singing the praises of this system ever since I found it months ago and especially ever since we implemented it a few weeks ago.

This is only the beginning for me. I’ve yet to have the time to really dig into the guts, but I will very soon. As such, we’re layering in the power and functionality, bit by bit, as time allows.

I can’t wait to learn more and hope to contribute along the way as my knowledge grows.

Thanks again.

Cheers!

[royh]

Good early morning here from Chicagoland.

Things have been great as our ability to handle high volume orders have been greatly improved in the days that we’ve been using the setup provided by @QMcKay.

I wanted to provide an update and document a tweak to the aforementioned setup. Also, I’ve been encountering a separate issue that I could not put my finger on until just now. But first the tweak.

I noticed that some names have been “breaking” the automation. Since most offending cards have been those of my friends, they graciously allowed me to document their card formats for later testing. One of my friends’ cards that didn’t swipe had his name formatted with an apostrophe (O’Toole). The simple tweak to deal with that is to simply change the apostrophes to quotes in the settingValue field for the CSS Numpad Rule’s CSS Store Value Action as shown in the following screenshot.

The Other Issue…
Before O’Toole came in, I had a friend named Alexander whose cards would not work. When O’Toole came in later with his wife, maiden name Maddox, her card didn’t work either. And then, today I had a customer named Baxter come in whose card also did not work.

While troubleshooting this issue after work tonight, I realized the one common thing in all of their cards was that their names all contained the letter x. I thought, “No way would that be the issue”, but lo and behold, if I replaced the x with any other character, then the automation worked! So, of course, I’m thinking, this has to be a bug!

However, in continuing to troubleshoot this presumptive numpad x issue, I started realizing that anytime I type in lowercase letters and then type in x, the whole string clears from the numpad. Yet, if I type in numbers and then x, or capital letters and then x, the string remains. I started to get the feeling that this is actually working as intended, as I continued to troubleshoot.

While troubleshooting I noticed that typing at the ticket screen seems to filter products so that one can find them quickly to add them to an order. If that is an intended feature, and the x key is also intended to clear the numpad presumably, then is not being able to use the x key to search for products some kind of a feature “tradeoff”? Could a more appropriate key or a custom button be used instead so that the x key could still be used to filter products from the ticket screen? Or can using the x key to clear the numpad be disabled?

As a workaround for the automation I’m trying to accomplish, I’m guessing I can tweak the Rule and workflow to have the staff press the select customer screen and then swipe the card. However, I’m still a little concerned, and therefore wondering what anyone’s thoughts are, regarding not being able to type in the letter x at the ticket screen to find products. Can someone enlighten me as to why I wouldn’t want to disable the x key from clearing the numpad? I feel like I must be missing something obvious or more global if this is not a bug.

Thanks again in advance.

[markjw]

@royh

if I replaced the x with any other character, then the automation worked

Apologies for jumping in as I haven’t read through the entire thread, but I believe x in the [:NumberpadValue] is reserved for quantity, i.e. 2x and that could be the reason you are having problems with x.

[royh]

Aha! Thank you @markjw. I figured this had to be a “working as intended” behavior.

A multiplier is definitely a necessary mathematical function to have in a POS. In a physical numpad, that mathematical functionality has always been performed by the actual multiplier key, the asterisk. I’m guessing there is a reason why the natural, intuitive asterisk key was not used.

Is there a way to change the multiplier key to the more natural and standard asterisk key in the settings somehow? If there were, or if that feature were to be implemented, would changing it to the asterisk key break other functionality, such as wildcard reg expressions? Pardon me for my inexperience, but it just seems natural to have it there where that electronic calcification numpad (10 key) standard has already been in use for decades.

Thanks in advance!

[QMcKay]

@markjw

I believe x in the [:NumberpadValue] is reserved for quantity, i.e. 2x and that could be the reason you are having problems with x.

@markjw is correct unfortunately, and I don’t think we can change this.

@emre will need to look into changing this behavior so that x is not considered to be a “special” character in the Numpad.

[royh]

Understood.

I’m sure @emre’s plate is already pretty full. And I’m sure there’s a very good reason why this application could not adopt the already standardized numpad asterisk key as the multiplier function.

I’ll take a stab at tweaking the automated setup above to go to the customer screen first before swiping and parsing the name from the credit card in the meantime.

Thanks again everyone!
Cheers from Chicagoland!

[royh]

I figured it out!

But, not without help from an old post from @QMcKay yet again! In that post @QMcKay takes a stab at, and more importantly walks us through, an attempt to solve a similar problem albeit by way of the Numberpad, which I’m trying to avoid due to the way the Numberpad treats the x key as mentioned above.

Here are my tweaks to @QMcKay’s solution so that the desired functionality can be achieved.

The Automated Command Setup

The Rule Setup
Top of Screen

Bottom of Screen

In action

Thanks again for being so diligent in your responses @QMcKay! You came to my rescue again.

We purchased our license for V5 earlier today, before I attempted to figure this all out. I’m so happy and proud to support this wonderful creation. I can’t wait until I have enough time to get further and further into the guts of this kickbutt ware.

You guys are the best!
If you guys are ever in Chicagoland, hit me up so I can show you my store and more importantly, buy you some brews!
Cheers