THE EMAGINEPOS GUIDE TO PAX / EMV / BROADPOS

Author Davis Ford

Last Updated 9/22/2016

THE EMAGINEPOS GUIDE TO PAX / EMV / BROADPOS

What Is BroadPOS? Some things you can do with BroadPOS What Processors Are Currently Supported? How To Login To BroadPOS

Support Checklist Step -1: Things Specific To Processors Tokenization (attach credit card): Batch Out Step 0: Get One Or VAR Sheets for the Merchant Step 1: Create a New Merchant (if necessary) Step 2: Add the Serial Numbers of the New Terminal(s) Step 3: Create A New Template TSYS Parameters TSYS Tab => Merchant Parameters TSYS Tab => Feature First Data Omaha Parameters First Data Omaha Tab => Host Features, Host URLs First Data Rapid Connect Parameters FirstData RapidConnect Tab => Host Features FirstData RapidConnect Tab => Host URLs Heartland Portico Parameters Hsptc Tab => Host Features Hsptc Tab => Merchant Parameters Hsptc Tab => Host URLs Hsptc Tab => Dial Parameters

Misc Tab => Communication Tab => General Communication Tab => LAN Communication Tab => Communication between ECR/POS and PAX terminal Communication => POS System Feature (Ethernet Only) Step 4: Deploy The Template Step 5: Install the Browser Extension for Emagine Payments Step 6: Setup Payment Terminals in the Backoffice Step 7: Create New Payment Type for EMV (if necessary) Step 8: The Terminal

Frequently Asked Questions / Troubleshooting PAX Frequently Asked Questions List CONNECT ERROR when I try to execute a transaction SWIPE ONLY error when I try to Void or Adjust NOTES on First Data Omaha How can I do a manual credit card transaction? Can I Still do a Pre-Authorization? Can I Attach A Credit Card To An Order? TSYS Tokenization Support Heartland Tokenization Support First Data Tokenization Support If I Take A Payment On Station #1 with PAX Terminal #abc, Can I Void / Adjust on Station #2 that has PAX Terminal #xyz How Can I Batch Out? How Can I Check The Batch Status of These Terminals? The Merchant Has An Outbound Firewall - What Rules Do We Need To Whitelist? What about Daylight Savings Time changes? BroadPOS Error: The configuration of source template is not available BroadPOS Error: The source application has not been assigned to the reseller

Debugging The Chrome Extension

Updating the Extension / Update Settings

Useful Contacts / Links PAX Support Heartland Support TSYS Support First Data Omaha Support First Data Rapid Connect Support

DataWire Support Our Internal PAX Rollout Database Interlink Credit Card Processing Card Connect

What Is BroadPOS?

BroadPOS is PAX’s web-based configurator that can be used to manage terminals. One common misconception is that it participates in some way with an actual transaction. This is not true. Once a terminal has been setup and configured, it talks directly to the host processor to execute a transaction. PAX / BroadPOS has no knowledge all of the actual transactions that are carried out.

Some things you can do with BroadPOS

● Deploy/setup a New Terminal ● Update the App on a Terminal ● Update the Parameters on a Terminal ● Reprovision a terminal for a different site / location / app / processor

The PAX terminals have both an App and a set of Parameters that configure it. The App is specific to both the model and the processor type. For example, there’s a specific App for the S300 using Heartland and a different App for the S300 and the TSYS.

You need to email PAX @ [email protected] if you need an App but it is not showing up in the ​ ​ dropdown list. They can add it for you, or it may not be available. For example at the of ​ ​ writing, they do not have an EMV App for the PX5 or PX7 with TSYS or FirstData

What Processors Are Currently Supported?

At the time of writing they support one of: ● TSYS ● First Data (Omaha) ● First Data Rapid Connect (Nashville) ● Heartland

Other processors may be added in the future (e.g. EPX), and note that not all devices have apps for all processors.

How To Login To BroadPOS

Login to BroadPOS at https://secure.broadpos.com - you should have your own account. If you ​ ​ ​ ​ don’t ask, and one can be created for you.

Once you login, you’ll have this sidebar:

It is fairly self-explanatory.

● My Merchants is used to manage our merchants. ​ ● My Terminals manages terminals (obviously). ​ ● My Templates are used to roll out similar / same app + parameters to more than one ​ terminal without having to re-type everything. ● User Management allows you to add more users to BroadPOS. ​

Support Checklist

Here’s a checklist of what to do when you get a new PAX terminal and it needs to be setup.

Step -1: Things Specific To Processors

Tokenization (attach credit card): ● Does not work with First Data Omaha ● Works with TSYS ● Works with Heartland ● Supposedly works with First Data Rapid Connect (but unverified)

You must explicitly request tokenization to be turned on at the processor to enable it. Query your VAR sheet provider. If they want “attach credit card”, YOU NEED TO ASK THE ​ PROCESSOR TO TURN IT ON.

Batch Out Heartland only: if you’re setting up Auto End Of Day with Heartland and configuring an auto ​ batch time on the PAX terminal YOU MUST CONTACT HEARTLAND AND TELL THEM TO ​ BATCH AT THE SAME TIME. If you don’t, transactions will continue to flow in, but never settle. ​ PAX Devices Before you sell a solution with specific PAX devices, sure PAX has an app for that specific processor. For example, the PX5, PX7 currently only work with Heartland. Do your homework ​ ​ ​ ​ -- ask me first. I can out the latest, or email [email protected] to ask them directly. ​ ​ Step 0: Get One Or More VAR Sheets for the Merchant

Depending on you’re talking to and what processor is to be used, they may send a VAR sheet per terminal, or they may just send one sheet with a list of different terminal IDs. But you won’t be able to setup the terminals, create the template and deploy until you have these params.

See the Useful Contacts / section for who to contact if you don’t have a VAR sheet. ​ ​

I do have sheets for testing Heartland’s development servers -- if you just want to set up a terminal to test the hardware. I also have a test batch of cards.

Step 1: Create a New Merchant (if necessary)

Determine if we need to create a new merchant or not (take a look and see if the merchant already exists). NOTE: the Emagine POS Dev merchant I created to test and do development ​ ​ under. Please don’t delete it.

IMPORTANT: For some silly, God-awful reason, PAX has decided to make the merchant name ​ a global value in their system. This means if there’s already a merchant in there named “Joe’s Pizza”, even if was added by someone else and we can’t see it, and you try to add the same name, it will complain that the name is already taken. ¯\_(ツ)_/¯ ​

To work around this silliness, I am adding the Merchant name and then tacking on the word EMAGINE. See, for example how we have Legends EMAGINE as the Merchant name for ​ ​ ​ Legends (Alliance Hospitality is their official business name.)

The information above is mainly for our records -- it will not affect processing, but it is best to keep this information current so we can filter by it when we search for templates or terminals.

If we have 500 merchants in here, the names should match or be close to the same names as the organization we have in the POS for our sanity.

You can ignore the BUSINESS INFORMATION and other drop down sections here. ​ ​ Step 2: Add the Serial Numbers of the New Terminal(s)

Serial numbers can be found on the sticker on the back of the device, and also on the outside of the packaging box. You must add them to allow them to be managed.

Select My Terminals and choose Add Terminal (SN) in the right corner: ​ ​

Fill out the form on the next page. The important thing is the serial number. Assign it to the correct merchant that you just created. The Location field is optional and just informational. The Manufacturer Name and Model Name should auto-populate after you enter the serial number.

Now the terminal has been added but it isn’t provisioned. The next screen shows this:

We can skip this for now and do it later. We’ll have to build a template first. In order to build a template, you need the VAR sheet.

Step 3: Create A New Template

Templates are useful to save you the hassle of having to re-fill out some fairly painful web forms over and over. This is error prone stuff; it is super easy to make a mistake copying abstract numbers into all these crazy fields, especially if the location is going to deploy more than one physical terminal -- typically all you need to do is change the V Number (more on that later) from the param sheet and update the Terminal ID -- the rest of the parameters stay the same.

So, you create the template once, and then when you go to actually deploy it to a specific serial #, you have a chance to make any last minute changes to the parameters and you change a couple fields and push it out.

I haven’t yet settled on a good naming standard for templates. If you have a good idea for it let me know. When you create one, they show you the merchant and device as separate fields, so maybe it isn’t necessary to put this information into the template (see below for example).

Ideally, we need a decent naming standard for templates. Any ideas? I’m thinking the best plan ​ for naming these is just the PROCESSOR-MODEL (e.g. TSYS-S300). And then we use the filter form to narrow down to a specific processor or merchant.

Click the Add Template button to add a template ​ ​

Select the correct Merchant Name for the template, give it a proper name, and then select the ​ ​ correct model number. The description is optional.

Now you have to select an application for the template.

● Heartland Portico-HC-Restaurant is for Heartland ● TSYS-TC-Restaurant is the one you want for TSYS ● Omaha-TC-Restaurant is the one you want for First Data

These apps may have different names if you’re deploying to a different model number. Select ​ the correct application and continue. NOTE: this may not be the complete list of apps, they ​ ​ change and add new ones for new processors all the time.

Now you have to configure the parameters. You must have the VAR sheet for this. ​ ​

This screen is going to look different depending on the App and Processor and Model choices, but here’s what it looks like for TSYS on the S300 when it is blank.

Here’s a quick summary of the sections you need to change, and those that you should be able to leave blank or set to defaults (specific instructions are below, but use this as a guide to know where you need to make changes). Areas in red need adjustment, and those in green can be ​ ​ ​ ​ left alone.

TAB Section Action

TSYS (or other processor) Merchant Parameters Where the VAR sheet params go.

TSYS (or other processor) Host Feature Must set auto-batch time here

TSYS (or other processor) Host URLs and Host Phones LEAVE DEFAULTS

EMV ALL SECTIONS LEAVE DEFAULTS

Industry Industry Features LEAVE DEFAULTS

EDC ALL SECTIONS LEAVE DEFAULTS

Receipt ALL SECTIONS LEAVE DEFAULTS (we our own custom receipts with our own printers)

Tip General LEAVE DEFAULTS

Misc ALL SECTIONS Must Adjust Settings

Communication General Must Adjust Settings

Communication LAN LEAVE DEFAULTS

Communication Dial Up LEAVE DEFAULTS

Communication Communication between Must Adjust Settings ECR/POS and PAX terminal

Communication POS System Feature Must Adjust Settings (Ethernet Only)

Card Type ALL SECTIONS LEAVE DEFAULTS

BroadPOS ALL SECTIONS LEAVE DEFAULTS

TSYS Parameters The following sub-sections will only show up if you’re using TSYS.

IMPORTANT PLEASE READ (TSYS ONLY) In the screenshots below under Merchant Parameters it has the field Terminal ID Number ​ (TSYS ONLY). This number is supercritical to get right. For TSYS, this number is an 8-digit field, but ​ ​ ​ ​ we have had ISOs (e.g. Intl Bancard) provide us with VAR sheets that have only a 7-digit number. This ​ number is only validated when they batch. So, if you put it in incorrectly and they run transactions all ​ day, the batch will fail in the AM, and you cannot update the terminal with transactions on it: Catch-22.

We learned this the hard way. This must be an 8-digit number with a 7 prefix. Here’s an example of a correct number:

Beware that sometimes an ISO may send this number over without the 7 prefix -- seemingly because it is always a 7 and I guess they just assume you know that. ​

The other thing I would suggest is if you program a terminal in the office before installation, run a penny transaction, and then batch it. You can batch it on the terminal itself under Host Settings (safe ​ way to do it), or on the POS via Show Commands => Batch Credit Cards (be careful here -- if you do ​ ​ this and they also have swiped card setup via USAePay or Mercury, you will batch those with this command). ​ TSYS Tab => Merchant Parameters This section is where you’ll fill in the VAR sheet . It’s critical you get it right, or transactions ​ ​ will not work (you should test this after you deploy to the device anyway with something like a penny transaction).

It’s going to look different for each App + Processor combination here, and sometimes the VAR sheets will use slightly different terminology than what PAX uses, so it can be confusing. The good news is I was able to figure out how to do it for all three: Heartland, TSYS and First Data Omaha. Let’s have a look at TSYS merchant parameters and an associated VAR sheet and how the fields map from the VAR sheet to the web form.

Here’s what it looks like blank:

And here’s a of a VAR sheet we received for Player’s Club (PINNACLE RESTAURANT GROUP):

Now, here’s what it looks like completed after copying the proper fields from the VAR sheet to the template:

Here’s a list of the fields and some notes on them. The rows in yellow have special significance ​ ​ explained below.

Web Form Field Maps To VAR Sheet Name Note

Bank Identification Number Bank BIN#

Agent Bank Number Agent #

Agent Chain Number Chain #

Merchant Number Merchant # (12)

Store Number Store # (4) NUMBER MAY VARY PER VAR SHEET!

Terminal Number Terminal # (4)

Merchant Name Merchant Name MUST MATCH

Merchant Category Code MCC / SIC (4)

Terminal ID Number V Number (TID)

P2PE Mode n/a THIS MUST BE DISABLED

City Code Zip Code

Merchant State State

You may get some other VAR sheets that might look slightly different or use slightly different terminology but those are the big ticket items that you must input and get right. Please make ​ sure P2PE Mode is set to Disabled. ​

The fields that are highlighted in yellow have special significance: Terminal Number and ​ ​ ​ ​ Terminal ID Number. If the merchant is deploying more than one PAX device, you may have ​ multiple VAR sheets, or the underwriter may have sent you a single VAR sheet with just a list of different V Numbers and Terminal Numbers. This is because the template we are building is ​ going to be identical for all PAX devices except for these two numbers. Once you build the ​ template, you’ll put in a V Number here and a Terminal ID for the first device, and you can ​ ​ ​ ​ deploy it (see below for how to do this). When you want to deploy the second device, you’ll use the identical template, but before you deploy it, it will offer you the ability to make any last minute tweaks to the parameters. All you need to do is change these two numbers and you can roll out the same template.

So you only need to build the template once for a merchant location.

TSYS Tab => Host Feature This section is super important for Auto End Of Day locations. We have two ways to close the ​ ​ batch for a PAX terminal. We can do it through an API call from the POS to the terminal (this is supported if they run Manual End Day, or Batch Credit Cards command in the POS). all locations, however, use Auto End Of Day. For more info on batching and manual end of day, see the Frequently Asked Questions section. ​ ​

Here’s how we’ve configured it for Legends. Legends is set to run Auto EOD at 5AM. We want to set the terminals to begin trying to batch out about one hour in advance. This is 24 hour time ​ ​ here, so if you wanted it to batch at 1PM, you’d set it to 13:00.

So, we set the time at 04:03 (that’s local time) and when 04:03 AM comes, it will try to ​ ​ ​ ​ batch. If it fails for any reason, it will keep trying every 4 minutes (the Interval for AutoDial) until it either succeeds or it reaches 05:00. So, it will try to batch for about an hour. ​ ​

Now, this one I set for 04:03 because they have 14 terminals, and I just set them to stagger ​ ​ auto batch by about 1 minute. This is not critical to stagger the times, but it might make it easier to an issue with batching.

It is important that you set the auto-batch time in advance of the Auto End of Day time ​ ​ because after Auto End Of Day completes, the POS will try to contact each PAX terminal and pull its Batch report so we can have a record of whether it batched and for how much.

Here’s the other trick to getting this right. The keen observer may note that there’s no time zone setting for these timestamps. Indeed. In order for this to work properly, before you roll out the PAX terminal, YOU MUST SET THE ON THE DEVICE ITSELF TO BE LOCAL ​ TIME. Therefore, if you’re deploying the device to California (PST), you need to set the System ​ Time from Menu => Sy stem Settings => Set Date/Time to be local PST time, and ​ ​ then make sure these Start/End batch times agree with that. For more info about System Date/Time see the FAQ on DST Changes. ​ ​

SUPER IMPORTANT: I learned this the hard way, if you omit any one of these fields (start, end ​ or interval), the whole process fails and the terminal will not batch. You need all three to ​ ​ ​ make it work. Also, the interval cannot be anything than a 3 minute minimum or the ​ ​ ​ process will also fail. I learned both of these the hard way. These settings are not documented, and I had to contact PAX for to diagnose.

First Data Omaha Parameters If you’re using First Data, it’s a bit simpler than TSYS.

First Data Omaha Tab => Host Features, Host URLs

Here’s a look at a VAR sheet for First Data from CardConnect.

Here is how we configured the template for it. Note for First Data, we did update the Primary / Secondary URLs under the Host URLs section -- whereas for TSYS the defaults were fine for this section.

Review the section on Auto Batch above (in TSYS section) to understand what to set for the ​ ​ start/end/interval for batch times.

NOTE: THE PRIMARY AUTH / BATCH URLS FILLED IN ABOVE ARE NOT CORRECT. This ​ is the info that was in the Card Connect VAR sheet, but it is wrong. Stick with the pre-filled defaults that come when you generate a new PAX Template with the Omaha app.

With First Data, we can deploy this template (review the section on how to deploy below), and just change the Device ID each time (note the VAR sheet lists all the unique ids we can use.) ​ ​ The template starts at “0001” and each time we deploy to a new serial number, we’d use one of the other numbers listed in the VAR sheet “002, 003, …”. All the other settings stay the same.

First Data Rapid Connect Parameters Quick Note: PAX says RapidConnect does not support voiding of a Post Auth transaction. In ​ my limited testing, I found this to be true. Also, we rolled out one merchant and tokenization returned an error (INVALID TRANSACTION). I believe you have to explicitly request that

tokenization be enabled from First Data for the merchant. Sadly, I do not know who to contact to make this happen.

FirstData RapidConnect Tab => Host Features The important fields are the 12-digit Merchant ID and the Terminal ID and the Group ID. ​ ​ ​ ​ ​ ​ I’m unsure what Alternative Merchant ID is, but just set it the same as the Terminal ​ ​ ​ ID. The rest of the fields are already filled in. Just make sure you set the auto batch times here ​ to an hour before auto EOD.

FirstData RapidConnect Tab => Host URLs Leave this alone.

Heartland Portico Parameters

Hsptc Tab => Host Features

Note their auto batch is configured differently from all the rest in that it lacks a batch end time and interval. I don’t know why. Make sure you set it an hour in advance of the Auto End Of Day time.

Hsptc Tab => Merchant Parameters

This is the important part. You need to get License ID, Site ID, Device ID, User Name ​ ​ ​ ​ ​ ​ ​ and Password from Heartland. ​ ​

I believe Unique Device ID -- if set the same, will force them all into the same batch. Not ​ ​ sure it matters too much one way or the other. This is an optional field.

Hsptc Tab => Host URLs Leave these alone

Hsptc Tab => Dial Parameters Leave this alone -- we don’t use dial-up.

Misc Tab => This tab has some additional important fields that must be set to work properly. Here’s how it looks blank:

And here it is filled in with the correct values:

The important settings are below. We want to set all the passwords the same, the digit ​ sequence 916860. We need to tweak that GIFT/LOYALTY setting or they will not be able to ​ ​ ​ swipe those cards with PAX terminals.

Field Name Note

System Password SET ALL OF THEM TO: 916860

GIFT/LOYALTY Card Check Type for MUST BE SET TO: Excluded from CREDIT INPUTACCOUNT BIN

Communication Tab => General Make sure the Primary . Type is set to LAN, and the Backup Comm. Type is set to ​ ​ ​ ​ Disabled (it will just add latency to a failure). The other settings are fine as is.

Communication Tab => LAN The defaults here should be fine. We have a system in place whereby DHCP should work just fine as long as they leave things plugged in and stable. Make sure DHCP is enabled.

If you wanted to force a static IP, you’d do it here, but I wouldn’t recommend it.

Communication Tab => Communication between ECR/POS and PAX terminal This section must be set correctly. The Port must be 10009, the Communication Type must ​ ​ ​ ​ be Ethernet, and the Protocol Type must be HTTP GET. ​ ​

Communication => POS System Feature (Ethernet Only) This section must be updated for DHCP to work properly. Set the POS Register Type to be ​ ​ PAX, and the POS Register URL to be pos.emaginepos.com and the POS Register Port to be ​ ​ ​ ​ 80. Now configure the POS Register Page to be terminalip . That’s all one word: t - e - r - ​ ​ ​ ​ m - i - n - a - l - i - p, or TERMINALIP but all lowercase. Now set POS Auto Register to ​ ​ Enabled.

That covers all the settings we need for the template. Save it and it should lead you back to the list of templates and show that it is there but with a state of not active.

Tip Tab => We’ll only be setting this if we are going to capture signatures on the PAX terminals. I ​ recommend we turn this on by default now for all deployments, since we can control whether it will prompt for tip via the Station Type settings. Signature capture is a feature we are developing right now. In order to do the signature on the PAX, we must have the terminal also prompt them for the tip -- since there is no way to go back and legally add the tip, since they will not be leaving a signed slip.

In the backoffice, we’ll have a checkbox on the Station Type that will cause the POS to capture the signature on the PAX after the transaction. When it does this, it must also capture the tip, and so you must enable tip capture in BroadPOS to make this work.

To allow tip prompt on the terminal, you need to change Tip Select to be Enabled. The amount ​ ​ threshold determines whether it will prompt with dollar options or percentage options. With the setting above set to $20.00, if the amount to be charged is below $20.00 it will prompt with four dollar amount options:

1. $3.00 2. $5.00 3. $7.00 4. User types in dollar amount

If the amount is above $20.00 it will instead prompt with these four options:

1. 20% 2. 30% 3. 40% 4. User types in percentage amount

Step 4: Deploy The Template

Remember above when creating the template I said that in the Merchant Settings there were two special values, the V Number or Terminal ID Number, and the Terminal Number. ​ ​ ​ ​ ​

When you go to deploy, you’ll want to update this as you roll out each VAR sheet. Remember, each template is going to have identical settings except for these two numbers (and optionally staggering the Start Batch Time (hh:mm)). ​ ​

The template you created should show up in the list but indicate it is Inactive:

Select it and Activate it. It must be activated before you can deploy it ¯\_(ツ)_/¯ ​

I’m not going to deploy that test template called “My Test Temp late”, but I do have 5 fresh ​ ​ PAX terminals that are supposed to go to Players Club and we need to deploy them, so let’s go through that exercise. I already have a template built, because we already deployed one PAX terminal there previously and they’ve been using it. I’ve also gone through the exercise of adding the serial numbers for those (still boxed) terminals, you can see them sitting here:

It says “No Applicatio n” b/c they’ve never been deployed. Let’s do that now. ​ ​

I Select the template for Pinnacle/Players TSYS for the S300: ​ ​

Now hit the Deploy button. ​ ​

I’m going to fill out the form and put in the first serial number of one of the terminals: ​ ​

If you’re sure you got the serial number correct, click OK through the next screen.

Now you land here, where you have a last minute chance to tune any of the parameters before ​ you push this out. Here we need to adjust the Terminal Number, the Terminal ID Number, ​ ​ ​ ​ and Start Batch Time (hh:mm). Everything else stays the same. ​ ​ ​ ​

Now I refer to one of my VAR sheets to up these numbers and I plug them in.

Now press Submit on the bottom to deploy it.

Do this for each VAR sheet and serial number.

After this it should show the state of the terminal is “Waiting for Download ”. ​ ​

Now you need to power on the actual terminal and make sure it is connected to a network.

It will connect to BroadPOS, and configure itself with the app + params you setup. Afterwards, it should be ready to go, but you MUST REMEMBER TO ALSO SET THE SYSTEM TIME + ​ DATE on the physical terminal itself before you deploy it at the customer location. Make sure it ​ is set for the proper timezone setting.

Step 5: Install the Browser Extension for Emagine Payments

There’s a command for this now in the POS under Show Commands => Install Browser ​ Extension. Currently this install will only work for Chrome and it must be done when the URL ​ in the address bar ends in an emaginepos.com domain (i.e. it won’t work with localhost urls, ​ ​ etc.)

** We also have a Firefox Extension but it has not been extensively tested. Ask me about ​ it if you need it.

If for some reason the automated install does not work, you can do it manually by visiting this url in Chrome to install the extension: https://chrome.google.com/webstore/detail/emaginepos-payments/bdmagcfhdkdmhbmgcpaopo gicolehfmo?authuser=1

Please also update the desktop shortcut to the time Chrome checks for updates. ​ ​ Step 6: Setup Payment Terminals in the Backoffice

There is a new Payment Terminals icon in the backoffice where you can configure the PAX ​ ​ devices. You’ll need to add them here to match the same serial numbers (exactly) you added in BroadPOS and deployed.

You can leave the IP address blank for now. If you configured things correctly in BroadPOS it should post its IP to our backend server when any of the following events happen:

1. It boots up and grabs an IP from DHCP 2. The DHCP client lease expires and it gets a new one 3. You manually force it to send its IP to our server via the Menu command: System ​ Settings => POS Register

So, once it boots up, it should post its IP address and if you refresh the backoffice view, you should see the device has an IP address.

The Enabled flag is used to temporarily disable a terminal without having to delete it and ​ ​ re-add it later. Let’s say for example, one station is going offline for a week for maintenance (maybe a hardware return), and the network cables are unplugged. If you don’t disable it, certain commands sent to the PAX devices will continue to try to reach the offline terminal and could cause some timeouts. Just disable it here and it won’t participate until you enable it again.

PROTIP: If you’re going to add the payment terminal definition in the backoffice before the ​ ​ terminal is wired up and comes online, please mark it as Disabled; otherwise, it will cause some ​ failures in the batch reporting at the end of the day as it tries to reach out and get the batch report from a terminal that is not online yet.

PROTIP: Make absolutely sure you put in the correct serial number here. The backoffice will ​ ​ ​ not allow you to put in a duplicate serial number, but if you type the wrong number, it can screw things up.

Next, you need to assign a Primary Payment Terminal to a POS station (similar to printers). ​ ​ ​ ​ Go to the configuration page of a station, and choose a payment terminal that will serve as its primary payment terminal (i.e. the one closest to it.)

Step 7: Create New Payment Type for EMV (if necessary)

You need to setup a new Payment type that is different than the standard Credit Card type to use EMV.

Here’s how I configured mine locally:

Finally, you need to enable EMV payment type for certain job positions:

Step 8: Test The Terminal

This is NOT optional. ​ ​

Once the terminal has been physically wired up (hopefully you marked it as Disabled in the ​ ​ backoffice until is online and ready), try to execute a simple transaction through it. 1. Create a new order and add a menu item 2. Go to Payment 3. Select EMV Credit Card (or whatever you called it) 4. Adjust the payment amount to $0.01 ​ 5. Hit Apply Payment 6. The PAX Terminal should light up and ask you to insert or swipe card for $0.01 ​ 7. Do that 8. Make sure it succeeds and remove the card.

9. Now, on the terminal itself, go to Menu => Host Settings => Batch Close and close the batch. This guarantees that the terminal is setup correctly.

If you don’t do a batch close on your test transaction, there is a risk that it will not batch and the transactions that have been auth’d are at risk of being lost.

10. Void / close the order

!!! YAY CONGRATULATIONS !!!

Frequently Asked Questions / Troubleshooting

How To Capture Signature On PAX Terminals

This works and is tested on S300, D210S, PX5, PX7.

1. You need to enable tips in BroadPOS so we can capture tip on the terminal before the ​ ​ payment. 2. Next you need to enable these checkboxes for the Station Type in the backoffice.

3. Next, you should set the number of credit card receipts to print to zero, since they don’t need to sign twice.

4. Make certain the system will print a receipt when payment is rendered.

Once they insert their card for payment, it will prompt them for tip (see the tips section for how to configure the numbers that show up here), complete the transaction, and then the screen will ask them to sign.

If the PAX terminal executes a credit sale, but they hit the cancel button on the signature screen, it will retry one time. If they cancel again, or it fails at least two times for any reason, it will popup a dialog that asks them if they’d like to try to capture the signature again. If they choose no, it warns them that it will void the transaction.

The reason we make tip optional here is if we have a retail station type, then you won’t want to have it prompt for tip.

The terminals will also try to capture signature on a void.

Signatures are stored in our Amazon infrastructure and will be available in the reporting site if you pull up an individual order.

PAX Frequently Asked Questions List https://paxfaqs.wordpress.com/general-information/

That website is pretty useful in general for a lot of info.

CONNECT ERROR when I try to execute a transaction

If you get CONNECT ERROR when you try to run a transaction it could be a network problem. In ​ ​ the terminal menu, try a ping command under Communication Settings => LAN ​ Parameters => PING . If that works, but you still get it, check your auth and settle URL/Port ​ combo under BroadPOS Merchant Settings.

I got a few VAR sheets from CardConnect that listed an auth/settle URL/port combo as vxn.datawire./19000. This was incorrect and outdated and it caused us to see CONNECT ERROR. The default URL port combo for FirstData Omaha auth/settle URL is support.datawire.net/nocportal/SRS.do

SWIPE ONLY error when I try to Void or Adjust

We saw this happen with a Dallas BBQ rollout + First Data Omaha. They were concerned about manual credit card entry security, since if you hit “Apply Payment” in the POS it can’t ​ ​ differentiate between a transaction that will be swiped or inserted or manual entry of the card’s PAN. With the old legacy way, they can put a permission on the POS that doesn’t allow them to initiate a manual credit card charge. Dallas BBQ still wanted some kind of protection on manual credit card charges.

So, it turns out there is a setting in BroadPOS that allows you to disable manual entry under EDC => Credit Features => Manual Entry . We disabled it for them on most terminals ​ and only enabled it for a couple terminals. But it turns out when you want to do a Void or Adjust, PAX marks this as a Manual Entry so it fails with the SWIPE ONLY error.

You must have “Manual Entry” enabled to allow Adjust / Void follow on transactions. We requested a fix for this from PAX, and they are looking into it.

ENCR NOT CONFIGD when I try to execute a transaction with TSYS

In the Merchant Parameters configuration, change P2PE Mode to DISABLED instead of VOLTAGE E2EE.

NOTES on First Data Omaha

Here’s another thing I found out about First Data Omaha. In order to process with their gateway, something called a “datawire” must be provisioned on the backend. Our underwriter/partner (e.g. CardConnect) should take care of this before we provision and try to use the terminals, otherwise, you may get COMM ERROR when you try to run a transaction. If ​ ​ you are getting that error, contact Card Connect (or whoever we got the VAR sheet from) and ask them if a datawire has been provisioned.

Another thing, for FD Omaha, programming the VAR sheet just means we need to use a different terminal/device id for each device. The rest is the same (there is no V Number like with TSYS). However, I was told by Card Connect, that if you program one PAX terminal with a device id, and later try to use it on another device, it will cause an error, and you’ll need to call them to reset it. It seems like they uniquely identify a terminal the first time it runs a transaction and you can’t change the device id to another piece of hardware without calling them to reset.

How can I do a manual credit card transaction?

Go to the order screen and hit Apply Payment like you would if you were going to swipe / ​ ​ insert chipcard. Now, the PAX terminal will light up and say Insert or Swipe Card with the order total shown. Instead of doing that, simply start typing in the card’s account number on the PAX terminal itself. After you fill in the number hit the Green OK/Enter button.

It will accept the number and may to one or more additional screens asking for additional information like expiration date, cvv, zip code. Enter as much information as you have. It should succeed, but if the transaction fails it may depend on the processor settings and the settings we have in BroadPOS. Contact me if this is a problem.

Can I Still do a Pre-Authorization?

Absolutely, in fact with EMV we do a real Pre-Auth, whereas with the legacy processor ​ ​ ​ ​ integrations, it isn’t a Pre-Auth at all, but it actually just charges the card, and then later allows ​ ​ you to adjust the total.

With EMV you cannot adjust the amount on a normal Sale, but you can adjust a PreAuth ​ ​ ​ ​ ​ one-time only when you it to a Post-Auth. Therefore, it gives you the opportunity to ​ ​ adjust the authorized amount once with the Pre-Auth => Post-Auth conversion. ​ ​ ​ ​

You can adjust tips all day long on both...meaning you can adjust tips on any EMV transaction multiple times until you are satisfied with the final result.

Example 1: I Pre-Authorize a card for $100.00. Later they want to cash out and the order total ​ ​ ​ is only $70.00. Select the payment and choose Change / Finalize . It will prompt you ​ ​ ​ ​ with a warning. Set the amount to be $70.00 and apply. This will convert it to a Sale ​ ​ ​ transaction in the batch for $70.00. You are no longer allowed to change this amount again, ​ ​ but you can adjust the tip. You can also void it, if necessary.

Example 2: I do a regular Sale (i.e. Apply Payment ) on an order for the amount $50.00. ​ ​ ​ ​ ​ ​ ​ This was a partial payment and the order is not closed yet. I select the payment and see that there is no option for Change amount. This is not allowed. But you can void it or adjust the tip. ​ ​ ​

Can I Attach A Credit Card To An Order?

Yes, when you do this with EMV; we actually Tokenize the card and store the token with the ​ ​ order. This allows you to later use the token to do follow-on transactions (Sale, Void, Adjust ​ ​ ​ ​ ​ Tip) even if you no longer physically have the card. ​

IMPORTANT: Not all processors support tokenization. For the ones that do, you need to ​ explicitly request support for it when the VAR sheets are requested, and need to make sure they also enable it. Processor specific info is below.

BEWARE: When you tokenize a card, the PAX terminal will ask you to swipe (not insert ​ chipcard). Even if you have a chip card, it expects you to swipe. If you tokenize a chip card, you lose the security guarantee and if the customer disputes the charges, the responsibility for payment will again be with the merchant (as if they did not have EMV capability.)

TSYS Tokenization Support It appears TSYS tokenization does not work quite the same as Heartland. Heartland supports a specific Transaction Type called TOKENIZE. When you run a card and execute the TOKENIZE command, Heartland will return the token our POS stores with the order, and can later be

used to execute a credit sale. I received confirmation from PAX today that TSYS does not support the TOKENIZE Transaction Type, and if you try to execute it, it will return this error:

I was also told by PAX that in order for tokenization to work, BroadPOS must be configured with a Gen2 Auth Code which should be obtained with the VAR sheet.

For CardConnect, they call this the “Authentication Code”, and they always set it to CARD2016 ​ unless stated otherwise. We plugged this into a TSYS terminal and afterwards, it did start returning the token for regular credit sale type transactions.

Oct. 3, 2016: we will need to likely make a few modifications to the POS codebase to handle ​ ​ how to tokenize a transaction for TSYS. Stay tuned, getting more information. ​ Heartland Tokenization Support Heartland does support tokenization and they support the TOKENIZE Transaction Type, but it must be requested and enabled up front.

First Data Tokenization Support So far, I haven’t been able to get a answer from anyone at First Data. We know it doesn’t work with standard VAR sheets. They may not support it, but I’m unsure if this is true for all FD variants (Rapid Connect, Nashville, Omaha, etc.) or just some of them.

Here’s a doc that claims support for it and shows a FrontEnd/BackEnd support matrix: https://www.firstdata.com/downloads/marketing-merchant/TransArmor-FAQs.pdf

Their tokenization offering is called TransArmor.

Update: PAX confirms that First Data Rapid Connect Platform does support Tokenization and the TOKENIZE TranType. They also state that First Data Omaha platform does not support tokenization at all.

If I Take A Payment On Station #1 with PAX Terminal #abc, Can I Void / Adjust on Station #2 that has PAX Terminal #xyz

Yes, the software keeps track of the originating transaction and it will do the right thing. Follow-on transactions must be done on the same PAX terminal, but not the same POS station ​ ​ (we keep track of this). However, if they go in and muck with the serial numbers in the backoffice or start unplugging things all bets are off. MAKE SURE PEOPLE LEAVE THINGS ​ ​ PLUGGED IN AND CONNECTED TO THE NETWORK AND FOR GOD’S SAKE DON’T MESS WITH IT ONCE IT IS WORKING.

How Can I Batch Out?

BE VERY CAREFUL -- IF YOU BATCH OUT IN THE MIDDLE OF THE DAY ANY ​ OUTSTANDING ORDERS WILL NO LONGER BE ABLE TO ADJUST TIPS OR VOID, ETC.

The Show Commands => Batch Credit Cards should work for EMV too, but this should ​ ​ only be used under very rare situations and if you know what you are doing. Never leave this ​ ​ command open to non-managers, etc.

The terminals will also be batched if they do Show Commands => End Day ​

Here’s the difference between these two:

POS Command Result

Batch Credit Cards Will only close the batch for that station’s Primary Payment Terminal, and it will also try to close the batch on any Legacy credit card services (Mercury) BE CAREFUL

End Day Will try to close the batch on every enabled payment terminal at a location, and the try to finish the End of Day process as usual.

Most people will likely be using Auto End Of Day and you must have configured their PAX ​ ​ terminals to batch at a specific time of day (see section above on how to create a template). ​ ​

How Can I Check The Batch Status of These Terminals?

You can check this on the PAX terminal itself under Menu -> Display Transactions (if it ​ ​ has credit transactions it will need to batch those).

I also built a Batch History Report into the POS frontend. You can pull it up under Show ​ ​ ​ Commands -> Batch History

The Query Terminals button in the bottom left corner will cause it to try to reach out to all ​ ​ enabled terminals on the LAN and pull their last known good batch report and update our database with this information.

NOTE: this button will not work if you created a station remotely. It will only work if the station is ​ ​ on the same LAN as the PAX terminals. So, you should remotely login to one of the onsite ​ customer stations and run it from there.

If a location is set for Auto End Of Day -- when that process finishes, it will try to do the same ​ ​ thing as this Query Terminals button, essentially trying to update our record of the batch ​ ​ history.

Pressing this button multiple times should have no ill effect.

The Merchant Has An Outbound Firewall - What Rules Do We Need To Whitelist?

The PAX terminals need no inbound firewall rules. If they have outbound firewall restrictions, this is the list of hostnames and ports it needs to to.

Host Port Note

t.broadpos.com 9120 Must have this enabled to allow it to phone home to BroadPOS and get updates and do a health status check.

pos.emaginepos.com 80 Must have this enabled to allow it to phone home to our server and report its IP address (unless they are strictly using static IP)

In addition to the the two above, the host urls and ports in the terminal’s parameter settings must be whitelisted. For example, for First Data, that looks like this:

This will vary per processor. Check the terminal’s parameter settings so you can tell them exactly.

Note, they’ll also need to enable outbound rules to install the Google Chrome extension and allow the Google Chrome extension to update itself.

What about Daylight Savings Time changes?

If you’ve set-up a terminal and set an auto-batch time in the parameters, you know how critical it is that you set the correct System Date/Time on the terminal itself before you roll out.

But what happens when we have a DST shift? I asked PAX this directly, and the response wasn’t ideal.

Davis,

Currently DST shift needs to be done manually one terminal at a time. I am aware that our dev team is considering pushing the time during the download, but I don't have a more exact time what that is implemented.

Thanks,

Dan Radu

904-900-3741 option 1 for technical support

My response to them:

Dan,

Please strongly consider adding support for NTP if at all possible. I'm not sure if that poses a problem because of your certification requirements, but this having to manually update all these terminals in the wild is going to present us with a ....I'm not sure what the right word is here, to put it diplomatically: horrible problem?

We need to move forward with EMV and I've been really happy with your hardware, your software, and your support -- but this seems like it would be something you'd want to take care of. We auto-batch the terminals and we auto batch our POS terminals. We do have some timing considerations between the two and if the auto-batch is happening an hour off that could pose real problems for us.

We are ramping up and may be soon installing up to several hundred locations a month. Updating all those every DST change -- especially with restaurant people makes me lose at night.

Regards, Davis

BroadPOS Error: The configuration of source template is not available

When I try to deploy a template it errors out with this. Answer from PAX:

It’s because the application version in your BroadPOS account has been updated. You will need to update the version in the template to deploy using it.

BroadPOS Error: The source application has not been assigned to the reseller

Same issue as above. This means that since you created the template, PAX has pushed a new version of the App out. You need to Edit the template, update the App version to the latest, click through to the param changes and save it. Then it will work.

Debugging The Chrome Extension

You likely won’t ever have to look at this, I’m just documenting it here.

The Chrome Extension has an Options page which can show you how it is configured, and also ​ ​ allows you to turn logging up or down and view the console for logging output.

Visit the URL chrome://extensions and see the following (note mine is loaded from the ​ ​ system because I’m loading the development version):

If you click the Options link, you’ll get a pop-up dialog: ​ ​

You can turn logging up by changing the log level to TRACE (the highest level of logging) and ​ ​ turn it down to ERROR (the lowest level that only logs in the face of an error). ​ ​

This also shows how the extension is configured. It should be configured to know about ALL ​ PAX terminals at a particular location, and then have a primary terminal assigned to it. You can cross-check this against what’s in the backoffice settings for payment terminals and stations. If for some reason they get out of sync and you cannot seem to get them to match up, press the Reload link to reload the chrome extension. ​

In order to see log / error messages, click the background page link from the main extensions ​ ​ view. This will launch a Chrome Developer Tools console, and it will show messages here. So, for example, if you’re having trouble with a particular transaction, you can try it again and take a look at the console to view detailed messages (see below for example):

Updating the Extension / Update Settings

The extension should update automatically.

IMPORTANT: When you setup the link to launch Emagine in Chrome on the desktop, please ​ add the following flag on the command line shortcut:

--extensions-update-frequency=300

This is in seconds and will cause it to check for updates every 5 minutes. The default if you don’t set this is that it will check only every 5 hours.

Useful Contacts / Links

PAX Support

Email: [email protected] ​ Integration / Development Support: [email protected] ​ Phone: 877-859-0099

Website / Wiki with useful docs: https://paxfaqs.wordpress.com/ ​ Heartland Support

Email: [email protected] ​ Our Agent: [email protected] ​ Our Integration Specialist: [email protected] ​

Phone: 1-888-963-3600

TSYS Support

Phone: http://tsys.com/contact.html (use the merchant assist center # 800.552.8227) ​ ​ ​

I was told

When you dial in, they will ask you for the name of the merchant and other info straight from the VAR sheet. You must have this available or they won’t talk to you.

First Data Omaha Support https://www.firstdata.com/en_us/contact.html

This support line is different from the regular First Data support apparently. Phone: 800-228-0210

You will need the merchant ID.

First Data Rapid Connect Support

Phone: 855-869-2066 M-F 8AM-10PM EST https://www.firstdata.com/en_us/contact.html

You should have a 12 digit merchant ID and the merchant’s full address on hand before speaking with them.

DataWire Support

I’m not entirely sure how DataWire works, but it appears to be a separate company under the FirstData umbrella that handles all the gateway support for them. If you have problems with FirstData, you may, in fact need to reach out to DataWire support first.

Phone: 800-704-4202 Email: [email protected]

Our Internal PAX Rollout Database

I’ve been keeping a spreadsheet here:

https://docs.google.com/a/emaginepos.com/spreadsheets/d/19mwdMuVLV6h5x5a9dVqHwQMd Tg640w6-j7XjTxxjtmk/edit?usp=sharing

I’m not sure we’ll keep this up to date or maybe it will go in FileMaker, but this is easier for right now while we still have a small number of terminals.

Interlink Credit Card Processing

We have used them for Legends, Players, etc., because they underwrite the more risky gentleman’s clubs. Our contact there is Rob Pannell.

Rob Pannell: Email: [email protected] ​ Phone (office): 586.293.9000%20x11 Phone (mobile): 586.722.4300

Card Connect John Katoula: Email: [email protected] ​ Phone: 484-581-2185