Web Listener Log Detail

If you wish to view log entries from all web listeners, you can do so from the Patron Sales->Web Sales Module->Web Listener Log menu item as per below.

This will open a list of log entries and you can search for any range of days, patron, listener, type of log entry, etc. You can:

  • also view all log entries for all people or view the logs for a specific cart.
  • Search the logs for failed password requests due to unknown email address. This is quite helpful of people say they did not get an email after requesting one - to see if they entered it right. If they did enter it right, you may want to look at Pending Emails in case there is an error in your email setup.

 

Log of when Emails were sent

You can use the web listener logs to determine generally when emails were sent from TM and if there are ongoing issues.
  • Open up the web listener log
  • Search the log Message field content for Batch Mailer
  • You will see one type of message that indicates Sent and Failed each with a count.
    • A Sent count reflects the number of emails that Theatre Manager was able to send successfully
    • A Failed count of other than zero indicates some problem with the email that will need to be diagnosed
    • If everything is successful, then nothing to worry about
  • The reason for failed emails is usually in a separate line with an error message. if there are a lot of these, then you can edit/fix some reasons by jumping over to the Manage Pending Emails screen to correct invalid email addresses, etc.

Patron did not receive Password Reset Email

Patrons can request a reset of their password online. They will receive a response from the web servers but only if ALL THE FOLLOWING CONDITIONS ARE TRUE:
  • they typed their email address correctly. (we've found that some people don't type anything).
  • the email address exists exactly once in the database. Nothing will be sent if the email address:
    • does not exist, or
    • exists more than once under multiple patrons
    (see below to find these messages)
  • the user checked their email program, including spam/trash folders, on all their devices or computers they can use for reading emails
  • the email settings in company preferences are valid.
  • and the email is not stuck in the pending email list due to some error

Otherwise they will receive nothing

If the patron types an email address that is not in the database, they WILL NOT RECEIVE A WARNING that the email address does not exist. This also occurs if the email exists more than once because it is an error condition.

The reason: PCI compliance and privacy laws (like GDPR) require that a system does not divulge any identifying information like names, addresses, or validity of email addresses to anybody who might be trying to determine who or what is in a database. The sample message from web site clearly indicates they will only receive and email if what they type exists.

This approach prevents 'bad guys' from scamming emails elsewhere and determine if an account exists on a second web site, where they could obtain products (Like reprinting tickets they could sell to others on the secondary market) should they be able to guess a login id.

Error messages can be changed to divulge more information (like email address exists, but password is invalid). This is not recommended if you wish to implement TM in PCI manner for information security.

 

Finding requests for invalid/nonexistent email addresses

If a patron calls and says that they asked for their password to be reset and did not get an email, you can check to see what email address they used by looking at the web listener logs.

This window is opened from Patron Sales->Web Services->Web Listener Log. For criteria, you may want to use something similar to below:

  • Date/Time to narrow things down to a range of days - searching for a month or two is not a problem
  • Search within the message text for:
    • email does not exist - use Email Cannot to see those people who did not get an email because the email address does not exist.
    • email exists multiple times - use Email is linked to see those patrons whose email is in the database at least twice and need de-duplicated using the find duplicate email addresses

 

Looking for only Failed Password Requests

You can see that there are some attempts to request passwords that did not exist. To verify, first ask when the patron requested their password; then using this window, confirm that this is the reason that they received nothing from the system. If there is no message in the log for the email address they described using the day they had the problem, then you will need to check to see if the email is in the queue pending to be sent, or if it was sent.

 

Verifying all or Specific Password Requests

The following search might also be used to find both requested and failed password requests. it could also be tailored to only search for part of the email address such as 'artman.com' to see all requests from that one domain. The:

  • request message will always appear
  • failed message will only appear if there is a failure.

Viewing credit card issues in Web Listener Log (EMV Devices)

General troubleshooting steps are found in the EMV pin pad setup at the end of the web page.

If you activate a pinpad, you should see 6 entries spread out in the web listener log that might help identify where things are in the communication process. These are:

  1. the activation of the pin pad
  2. a payment validation receipt with the request id - saying that we are going to request the CUSTOMER receipt
  3. a payment validation receipt with the SAME request id - saying that we are going to request the MERCHANT receipt
  4. a notification that the CUSTOMER RECEPT was retrieved (matching the request ID in step 2)
  5. a notification that the MERCHANT RECEPT was retrieved (matching the request ID in step 3)

The above messages are followed by a housekeeping message indicating the number of receipts processed and the number that had an error. Normally, that is 1 processed and 0 in error (unless it is declined for some reason)

Viewing credit card issues in web listener log (card not present)

If you are looking for problems with one cart, please look at the cart logs to see what the patron has been doing
You can find the majority of shopping carts that have had problems with their credit cards if you search the web logs for:
  • a range of dates and
  • the contents of the web log as being 3d-

Once you see the message, you can double click on it to see what the message means. Almost all errors are provided to Theatre Manager from the bank such as:

  • Do Not honor! (the bank doesn't like the card)
  • Declined! (the bank doesn't like the card
  • Hold card! (The bank doesn't like the card - it is probably stolen and the want wants to you keep it)
Some errors are generated by Theatre manager and are self evident, such as:
  • Card is Blacklisted (means the venue said they didn't want anybody to use this card
  • Emergency processing is on (means that the venue turned the merchant processor into emergeny mode and took the cards anyway

 

Actions that you can take

checking for scanned tickets

if you would like to search for particular scanned tickets, you can do so on the web listener log, since the ticket scanners send the scan messages to the web listeners. You can search:

  • for a date range if you know when the ticket was scanned
  • the message for the word Scan if you want to see failed scans, successful scans and checkouts
  • for the word scan ###### where ###### is the ticket number if you are interested in a particular one
  • of whatever combination of criteria you wish.

Note: the logs of scanning are not kept for a long time - only for the retention period set in company preferences.