AES Suite 3.0

Download the full release notes here

April 2018 Release Notes (Sprint 3).pdf

First Pay Processor Support

The parent company of iATS Payments is First American Payment Systems (FAPS), one of the larger processors in the USA. FAPS has recommended we switch to their legacy platform (First Pay) as the iATS platform will cease to get any significant feature updates moving forward. Also, the First Pay platform is more robust from a technical standpoint, which we fell will improve reliability and uptime.

In this release, the majority of our work was done to:

a) Genericize our payment processing in order to make it easier to integrate with new processors, both now and in the future

b) Integrate First Pay processing as an alternate option to iATS

This release supports both the iATS and First Pay platform, Over the coming months, we will begin the process of onboarding clients onto the First Pay platform in a gated fashion with the expectation that all clients will make the move within the next 12-18 months. Until that time, iATS processing will continue to work as usual.

Future AES releases will leverage exciting new features that are available on the First Pay platform, such as automated onboarding, Apple Pay, and recurring payments.

For now, this release is intended to be a stepping stone for a small number of clients to transition to the FirstPay platform. Please talk to your regional lead for more information.

Note: Existing card readers may be used on either the First Pay or iATS platform.

uReader is now AES KIOSK

This release contains multiple changes to uReader, including a naming change.

Android 7 support

In order to support the newest operating system on the Galaxy Tab E, we needed to make changes to KIOSK to support kiosk mode and keyboards.

First Pay support

Card swipes in KIOSK now support First Pay processing, utilizing the same card readers.

Card swipes return raw encrypted data

Whenever a card is swiped using KIOSK and a mobile card reader, the raw encrypted card data is returned, making the process of accepting cards on tablets faster and more reliable.,

Note: AES KIOSK MUST BE INSTALLED in order for EC 2.0.0.14 to work properly

Auction Conductor

Bug Fixes

Contributor grid filter for Type

Sometimes the grid filter would not show all results. This has been fixed and performance has been improved.

Safari browser on Mac.

Users could not check the box for “Patron” which resulted in some “Attending” only contributors. This has been fixed.

First Pay

Payments grid

• It is now possible to have processed and/or tokenized transactions from multiple processors in your grid at once. For example, it would be possible to change processors mid-event should there be a major issue that could not be quickly resolved.
• To ensure you can correctly reconcile your payments in this scenario, we have added a grid filter that will allow you to choose either iATS or First Pay transactions.

• First Pay transactions can be identified by the “F” in the token
• iATS transactions can be identified by the “A” in the token

• The Payments grid will now calculate the total dollars and number of transactions based on the contents of the grid, with filters applied. For example, filtering by Approved First Pay transactions will cause the totals at the bottom of the screen to reflect your selection.

Tokenization

• When you have Multi-Unit Instant Pay (MUIP) transactions from Event Conductor, you will notice that cards swiped at the point of sale are not yet tokenized. This is by design, to improve speed and reliability of the mobile card readers.
• As a result of the above, you will need to tokenize your cards before submitting them to the processor. The correct procedure is:

1. Apply to Accounts
2. Tokenize Cards
3. Submit Charges

Submitting transactions in batch

• As noted above – it is now possible (although not recommended) to have some credit cards tokenized with iATS and some tokenized with First Pay. When it comes time to submit those transactions for processing, we will submit those transactions to the appropriate destination, basedon the original token. For example, a card that has been tokenized on First Pay will always be submitted to First Pay, as is the same for iATS.
• The processor assigned to each card can be viewed in the submit charges grid.

Note: In rare circumstances, processing codes may not be available in time for the event, or you may need to disable processing due to an outage. In these cases, submitted transactions will be sent to the currently selected processor in Benefit Conductor.

Adding payments from the contributor detail screen

• When First Pay is the processor, you will notice a new hand-key screen

Reporting

Bid Sheets

The bid sheets have been updated to show the client logo on the left and sponsor logo on the right.

Patron Receipts

On the detailed receipt, we changed the “Phone” field to display Cell Phone instead of Alternate Phone. The receipts have also been updated to show the client logo on the left and sponsor logo on the right.

New Master Report – ELP Report

There is a new report saved to the Custom Report Generator for all users. In order to run the report properly – you need to change the date to your event date to show only admission tickets and donations made prior to the event.

Benefit Conductor

First Pay

Client Codes

A new section has been added to the BC event profile to accommodate the First Pay client codes.

• Users will now be able to select which processor they want to use.
• If codes are present for each individual processor, they will be validated upon save
• First Pay account details may be shown via the “get details” button. This is an excellent way to validate you have the correct codes entered, along with obtaining more detail on your clients account such as

a) DBA name

b) Client contact information

c) Current account status (live, disabled, etc)

Outgoing Email

Email settings for ELP/Self-Checkout

There is a new section on the “Preferences” tab for outgoing email. This section is linked to the same section found in the AC ELP Wizard.

Enable email to activate outgoing emails in:

• ELP receipts
• EC self-checkout receipts
• EM checkout receipts

• “From Name” is mandatory
• “Reply-To Email” is mandatory
• “CC Email” is optional. Multiple emails must be separated by a comma.

Self-Checkout

Activating Self-Checkout

Previously, there was a separate checkbox required to activate self-checkout in the “Event Preferences” section. That checkbox has been removed as it was unnecessary. Now, all that is needed to activate self-checkout on all devices is a saved self-checkout start and end time, in the event timelines section of the event profile.

Event Conductor

Self-Registration

• Improvements have been made to the search algorithm to reduce duplicate records being created. Previously, self-registered names and emails were searched across all events, which could cause problems for “guest of” records that had attended prior years events. In this release, we are only searching through the existing event, which will eliminate this issue. Self-registration is now approximately 95% accurate, with more changes coming in the next release to further improve this ratio.

Self-Checkout

• Start/End times now reflect the timelines in BC.
• Start time can be overridden on a single device by checking the “is Checkout Device” box in EC tools.

Note: The device must be NAMED in order to effectively use self-checkout on a tablet. ALWAYS use mobile card readers for self-checkout tablets.

Emailing receipts

When the BC event profile setting “Email guest receipts” is enabled, self-checkout users will be required to enter their email in order to receive a receipt.

Note: If we already have an email on file, it will be loaded in this screen. If there was no prior email, or the existing one was changed, we will save the NEW email to the primary guest record.

Note: Always be sure to fill out the appropriate “self-checkout message” in the event profile, on the preferences page.

Event Manager

Check-Out

Layout Changes

• The location of the Invoice Balance Due checkbox is moved.
• There is a new checkbox for “email receipt”. Once this checkbox is selected, it will remain selected for every guest, for the remainder of the user session.

Emailing Receipts

Once the Finalize button is pressed, the print and/or email functions will run. Should you have both selected, you will see the “enter email” screen first. Then the print screen second, and the email confirmation screen last.

Note: If we already have an email on file, it will be loaded in this screen. If there was no prior email, or the existing one was changed, we will save the NEW email to the primary guest record.

First Pay has been implemented

Missing Bid Sheet Report

There was a bug where the missing bid sheet report was showing packages with no bids. This has been corrected. No bids will no longer show as long as users key in those bid sheets with bidder #0 at $0.

Printed Receipts

• Client logo is now on the left, with sponsor logo on the right
• Cell phone has replaced home phone on the detailed receipt

Event Landing Pages

First Pay

First Pay support was added to ELP

Bug FIxes

Internet Explorer 11

We fixed a bug where the “Proceed to Payment” button was not appearing in Internet Explorer only.

Note: IE 11 is currently the only version of IE that is supported. In older versions, this bug may still exist.

Event Landing Page Error Emails to Planners

• We added the event name and ELP instance URL to the error emails to assist with troubleshooting\
• We also increased the session timeout from 30 to 60 minutes to reduce errors

Contributors associated in ELP

Previously, when there were multiple tickets being purchased in ELP, it was possible to have a conflict with bidder numbers and associations, when one or more of the secondary contributors wanted to share a bid# that was different from the primary bid#. This would cause issues with EM check-in.

This has been rectified by breaking out the secondary contributors into their own associations when this occurs.

For example, this is BEFORE the fix. Notice how all 5 bidders are associated together.

And this is AFTER the fix. Notice how the group that wanted to share their own bid# is broken out into a separate association.

Note: This change will only impact contributors that purchase tickets after this release is made. Contributors that purchased tickets prior to this date will need to be fixed manually in AC.