Individual User Challenges
V13.0 now supports the creation of individual user challenges. Within your existing loyalty program, you can now incent a single member of your loyalty program to complete a set of actions pertaining to visit, spend or a mixture of that behavior and award him or her with a badge and discount or free item once they cross the finish line. Guests will be automatically opted-in to challenges if they have completed the registration process in your loyalty program. Multiple auto-opt-in challenges can be run simultaneously.
The feature further allows you to restrict the days of the week on which your guests can participate in a challenge. For example, you could challenge your users to spend $10 every Monday, Wednesday and Friday for the entire month of April.
To set up a Challenge, login to your Merchant Homepage and follow the flow below:
Programs >> Challenge >> New Challenge
With this feature, you can configure your individual challenge. Title the challenge and, depending on the nature of the challenge, exclude individuals that participated in a previous challenge, or include guests that completed a prior challenge to incent them to build on their success.
When the technolog consultant saves the Challenge, they can then setup the challenge counters. The types of counters include:
An example of the first counter configuration screen is shown below. Visit and spend behavior are tracked through our wallet technology. Set the threshold, maximum number of qualifying events per one account per day, and the days of the eligible days of the week for individual challenges on the “Challenge Counter” screen:
Upload a badge image for your particular challenge. After a guest earns a badge, it will be displayed in the guest interface. The placement of this badge within the portal is configurable.
Guests will be notified via email automatically throughout the challenge period when they exhibit specific behavior.
Facebook is disallowing the ability to post to a friend’s wall via Graph API
The restrictions placed on Facebook’s Graph API have impacted the deliverability of eGift and Wallet Gifting posts via Facebook. In v13.0, changes have been made to accommodate the new API within our Wallet Gifting feature. Guests can now send a free item to a friend with the improved posting flow.
The new flow for sending eGifts via Facebook is currently in development and will be released by May 1, 2013.
New Functionality
The iphone is being updated on a different versioning number system because it is not tied to main PXS code base. In v3.0, of the iphone mobile App, you will have access to the following new features.
New B2B REST Interface
In v13.0, all transactions available at the POS are now available for B2B REST integrations. You can now do everything via REST that you could previously do via SOAP.
Refer-a-Friend
The Refer-a-Friend feature is now integrated to the REST interface. Referral programs can be integrated to third party mobile phone applications. There are two new API calls, including:
As part of the enrollment service, you can now pass referrerEmail registering (by the referent) so that the referrer and referent are linked within the flow.
CheckinService
If a guest is already checked-in to a location, a subsequent CheckinService REST call would yield an “Already Checkedin” error message. This reply will now include the most recent short code. The mobile app will need to be updated to take advantage of this feature.
We have added a new condition to the Account Filter called Age Condition. This condition enables the user to select accounts that belong to members who meet a certain age threshold. For example, many merchants filter member data to create unique promotions for two distinct groups: 1) members who are 21 years of age and older and 2) members who are under 21 years of age.
There are four ways to select the age of the target audience. They are separated into two categories: Age “Relative To” and “Age Range.”
Relative To.
Using this part of the condition, the user can select members who are either “at least” the age defined or “younger than” the age defined.
To identify all members who are at least 21 years of age set the condition to say:At least 21 years and leave the months and weeks blank. Setting this condition will return all accounts who are 21 years of age or older as of the time the account filter is run.
To identify all members who are younger than 21 years of age set the condition to say: Younger than 21 years and leave the months and weeks blank. This condition setting will produce member who are 20 years 364 days old and younger.
Age Range.
To select members within a particular age range, use the Age Range Condition. There are two options within this condition: Between and Not Between.
Selecting the “Between” option enables the user to pinpoint members are between two ages. For example, selecting “Between the ages of 18 and 21” will return a segment of members whose ages are 18, 19, 20 and 21 years. Included in this set will be members whose ages are 18 and 0 days up to 21 years and 364 days as of the day the account filter is run.
On the other hand, selecting the “Not Between” option will return all records with ages that are not in the specified range. That means, if any accounts have either null or only have the month and day of the birthday in the date of birth field, the filter will include those members.
Setting the condition to “Not between” the ages of 18 and 21 will select accounts with null and no birth year available as well as accounts that have ages from 13 years to 17 years 364 days and 22 years 0 days and older.
At this time, Paytronix does not store specific birth date information for individuals under the age of 13.
Merchants who have permission to see the Advanced HTML tab in the email tool will now be able to view the HTML code behind sent emails. This feature is helpful when users want to copy parts of existing email code to complete the code for new emails.
Usability Improvements
The dashboard menu page has been re-designed. It lists all dashboards available to each user. Dashboards are grouped by category: Gift, Loyalty, and Analyzer. Analyzer is a tool that resembles a web based pivot table. It allows a user drag and drop the individual facts they wish to analyze and then the dimensions into rows and columns. Once the correct data is found, the user can also switch from a table view to different types of charts and graphs.
In addition, the existing dashboards have been updated. The titles and axes have better labels. The time period buttons updated the data in all of the panels; however, it was not always clear within a panel what the time period was. There is now a button on the top bar that explains the time period. We also added drill down on the trend graphs. If you find a time period of interest; e.g., December 2012, click on the data point and the system will drill down into a daily chart for that month.
Online Gift Card Sales Dashboard
We have added a new data cube that covers online gift card sales. This data cube includes both eGift and Web Card Sales (physical cards purchased online). There is a corresponding dashboard that has 5 panels:
The graphs can be set to present either the number of cards or the gift dollars purchased. We are excited about this new dashboard and look forward to your feedback.
Gift Card Expiration Logic Now Respects Card Template
A few states, such as Massachusetts, allow gift cards to be expired. Paytronix allows for these expiration rules to be defined and attached to specific card templates. Prior to v13.0, this logic would run for all card templates in a merchant. This logic was fixed in v13.0 to only run for the chosen card templates.
Hiding Expiration Dates
It is now possible to hide expiration dates for specific wallets. This is meant for wallets that are used for temporary purposes (e.g. tracking a daily use reward) and it is not desirable to show the date to guests. This feature can be turned on by Paytronix technology consultants on the Wallet Specification page using the check box “Are Expiration Dates Hidden”.
Validation of Automatically Created Card Batches
Automatically created card batches are used for cardless program features such as: web reverse enrollment, text to join, or mobile app account creating. These batches can be confusing to create because the last three digits of the card are non-sequential. There is now a validation check to make sure that the number of requested cards will fit into the minimum and maximum card range defined in the card batch setup form.
Point Accruals Allowed On Split Checks Using Sub Check Feature
In POSitouch, there is a feature for split checks called sub-checks. When Check 4 is split it will create check 4-01, 4-02, etc… Paytronix’s integration did not treat these as separate checks and would prevent a card being swiped on the split checks. In v13.0, cards can be swiped on these sub checks.
Re-Swipe To Check For Added Rewards
In POSitouch, we block a second card from being swiped when a card is already associated with a check. We also prevented the same card from being swiped into the check. However, a few customers had issues where rewards might be added to a card while the guest was at the restaurant; for example, it could have been a registration reward. With v13.0 this card can be swiped again into the check and, if there were no vouchers already in the check, the registration reward will automatically be inserted into the check.
Balance Based on Account Lookup
We added balance inquiry based on account lookup for customers who forgot their card or are in a card-free program. This has been added to the main menu screen of the user program. Placement of the main menu screen allows access to this feature when the cashier is outside of a check.
Transaction History
POSitouch will be the first POS that has transaction history available at the POS. This will be available as a new button from the balance inquiry screen. The user would start from either the Balance Inquiry or Account Lookup buttons from the main menu screen (above). On the balance output page there is a History button. The image to the left shows an example of the transaction history that will show to the screen. A similar history will print simultaneously to a receipt so that it can be handed to the guest. The transaction history will return the 15 most recent transactions. The value can be changed by editing the TRANSACTION_HISTORY_MAX_NUMBER_OF_TRANSACTIONS parameter in the pxposui.cfg file. Since this is a report, these transactions are going to the reporting database server. Normally the reporting database is within seconds of the transactional database. However, there are some high-load conditions where the reporting database may be a few minutes behind.
Send Check Not Required For Late Flow Point Accrual
Previously, a send check was required to do the Identify Customer transaction at the start of the check. In v13.0, we removed this restriction. You can now do the initial swipe without sending the check.
Transaction History
Surprise! Transaction history has been added for the Aloha User program as well. A button can be created in Aloha TX to call the transaction history feature by adding the following line to the txbutton.cfg file: 1,996,1,Transaction\nHistory,C:\Paytronix\pxalohaui.exe TRANSACTION_HISTORY,1
The user will be asked to swipe or type in a card number (or use one swipe) and the transaction history will display on the screen. In v13.0, the history will not print to a receipt; that is coming in v15.0. The transaction history by default will show the most recent 15 transactions that adjusted wallets. The following pxalohaui.cfg configuration parameter TRANSACTION_HISTORY_MAX_NUMBER_OF_TRANSACTIONS can be used to change the default number of transactions. Some customers have asked to be able to change the names of specific Paytronix transaction types. For example, to replace "Reverse" with "Undo" and "Redeem Stored Value" with "Gift Redeem" on the transaction history display, add the following lines to the pxalohaui.cfg file:
This is a report; these transactions are going to the reporting database server. Normally the reporting database is within seconds of the transactional database. However, there are some high-load conditions where the reporting database may be a few minutes behind.
Store and Forward Added For Late Flow Point Accruals
In late flow point accrual, if the Internet was down the identify customer message would fail and the card would not be associated with the check. This meant that guest would NOT get points when the check closed.
In v13.0, if the Internet is down the card will be saved with the check and at the time of check close a point accrual transaction will be created and stored by the PXC. When Internet returns, the PXC will automatically forward these transactions to the PXS giving the guest credit for their purchases.
Added Expiration Date to Bulk Gift Card Sales
Some of our customers run gift card programs in which the gift cards expire after some period of time. For example, in Massachusetts, you can expire an unused gift card after 7 years and keep the remaining balance – without having to escheat any funds to the state. For these customers, we have added the expiration date for these cards on the bulk gift card sale screen in v13.0. The image below shows you what a sample receipt will look like.
The single card transactions - Sell, Add and Redeem - have always shown the expiration date.
Gift Auth ISL Error with too many rewards
This release fixes an ISL error for gift card authorizations in the rare case that the card had more than 10 rewards on it.
Only the first 10 will be displayed.
9700
The MICROS 9700 integration has not been officially released as a production version for several releases. In v13.0, our MICROS 9700 integration has been brought up to date with all of the latest features. The integration is under going a complete regression test. The production kits will be posted soon to the download site.
Post Check Transaction and REST support
The PXC now supports a post check transaction. This allows an integrator to send the full check to Paytronix at the time of check close. Paytronix will review the posted check and calculate the point accrual transaction. The posted check can also be saved at the PXC and streamed at a later time to the PXS as part of the new Data Insights product offering. The PXC also supports REST transactional input. Integrators can now send either XML or JSON to the PXC.
Java 7
The v13.0 PXC has been tested to work with Java 7. We recommend any versions between upgrade 11 and 19.
We know of no reasons that older PXC’s will not function properly on Java 7; however, we have not tested all versions. If you do upgrade Java, please try your lab system first and then one store to make sure you do not see any issues with functionality.
Versions below upgrade 11 have dangerous security vulnerability and should be avoided.
Upgrade Notes
***If the system is running Windows NT you will need a special keystore which is NOT present in the standard download kits.***
To upgrade to the v10.3 PXC from a version lower than v8.0, you will need to upgrade the Java JVM to v1.6.
For additional information regarding installation of v10.3 please contact your Technical Consultant at 617-649-3300, press 1 and then 3 for a Technical Consultant.
1. Third-Party Library Software