System Setup (Explanation)

Installing or upgrading Theatre Manager is very similar on all platforms. Since Theatre Manager is a point of sale application for your venue that can deal with credit card information, care must be taken to install it correctly to ensure PCI compliance.

There are three components to the Theatre Manager System:

  • The Postgresql database server
  • The Theatre Manager desktop application used by Box Office, Development, Marketing, Finance, etc. for daily activities
  • The Web Services (also known as the Director) that can be configured to handle various web related functions including:
    • The TM Web Listener service that responds to all online patron requests.
    • The Web server that passes web requests from Patrons to the TM Web Listener

The installation of the database server, Theatre Manager and web sales is relatively simple and can be done in a few minutes.

  1. Network Setup

Mandatory / Artsman & Venue

Setting up network for PCI compliance

  1. Installation of Postgres Server

  1. Installation of Theatre Manager

  1. Installation of a Customer Database

Optional / Artsman

If this is the first time that Theatre Manager is being installed at a venue, an 'empty' venue specific serialized database will be provided. It will only contain the zip code lookup table and sample code tables.

  1. Credit Card Authorization

Optional / Artsman & Venue

Theatre Manager provides a selection of service providers for credit card authorization:

  1. Installation of the Nginx Server

Optional / Artsman

Installation of the TM Web Services Nginx server is platform specific if you are using web sales.

  1. Setup TLS Certificate

Optional / Artsman

If you are using web sales, you must set up an TLS certificate and configure your firewall to allow web traffic. You will need to set up a DNS record for '' rather than assigning the TLS to a static IP address.

  1. Upgrade of Existing Web Pages

Optional / Venue

This step indicates the general changes to existing web pages that must be made when migrating from any version to any other version.

In addition, a venue must be aware of OWASP and should bookmark it in their browser. This site has a 'top 10' list of ongoing security considerations and standards for website development. Arts Management reviews and implements each years suggestions annually - see this year's top 10.

Finally, if you accept credit cards on the internet, you may need an application firewall as per PCI requirement 6.6 and the web pages are significantly changed. We are looking at mod_security and may put that into a future release of the apache server on your behalf.

  1. Initial Settings in TM

Mandatory / Artsman & Venue

After Theatre Manager and the database have been installed, you will need to review minimum key standards and other security features for PCI compliance.

  1. Remote Access

Optional / Artsman & Venue

This step is a discussion on remote access and what a venue need to do if they wish to provide that for themselves, for Remote Box Offices. There are considerations for using RDP within the network and enabling security. Arts Management uses a tool for remote support called Teamviewer.

  1. Policy Manual Additions

Mandatory / Artsman & Venue

These are some policies that should be added to the customer service and/or security policy manual at a venue for PCI compliance.

PCI and Artsman   Top

Achieving PCI compliance for your venue comes with how you install it on your network and other protections you put in place. These protections are mandated by PCI standards regardless of whether you use software in your operation. We hope that our instructions make it easy for a merchant to meet PCI DSS compliance.

The how-to steps indicate how to install and run Theatre Manager in a manner that will help you meet your PCI compliance requirements as outlined in the latest PCI quick reference guide. A venue that chooses to opt out of some of the safety and security measures in this document needs to be aware that they have chosen to bypass some aspects of the compliance required in the merchant agreement with their bank and the PCI Security Standards Council that is operated by the credit card companies.

Venues may opt out of any compliance step by signing the appropriate area. The credit card companies have placed the onus on all point of sale software providers to help merchants meet compliance (instead of the banks) and highlight areas to address.

Theatre Manager assists you in meeting PCI compliance because:

PCI   Top

PCI Ecosystem

A Merchant's PCI compliance is obtained by setting up the network and office policies in the appropriate manner and following a few simple rules (green in the diagram). This is required regardless of software used to process credit cards and can generally be done at reasonable cost.

The software or hardware provided by any vendor is only a portion of the merchant's ability to meet PCI compliance. Software provided by vendors must meet the prevailing PCI PA-DSS standard to assist the merchant meet overall PCI compliance.

The life cycle of a standard provided by the PCI Security Standards Council is approximately every 2 to 3 years. Once approved at a standard, it is valid even though future standards are being worked on.

Compliance Levels   Top

PCI Self Assessment Questionnaire SAQ

Self Assessment Questionnaire (SAQ)
This is a self-validation tool for merchants who, because of transaction volume or other criteria, are not required to do on-site assessments for PCI DSS compliance. The SAQ includes a series of yes-or-no questions for compliance. If an answer is no, the organization must state the future remediation date and associated actions. In order to align more closely with merchants and their compliance validation process, the SAQ was revised and now allows for flexibility based on the complexity of a particular merchant’s or service provider’s business situation (see chart below). The SAQ validation type does not correlate to the merchant classification or risk level. Source: PCI 3.0 quick reference guide

The PCI council has established 4 main levels for merchant compliance; schedules A, B,C or D with some variations at each level. You can use this table to help determine the level that applies to your organization.

Compliance Levels Summary Table

Compliance Levels
The inherent nature of the ticketing business with a combination of walk up, phone and/or internet sales means that Theatre Manager (or any other ticketing system for that matter - hosted or non-hosted) probably results in Schedule C or D compliance when card data is stored. Per this summary table, Schedule A may be possible for venues using Moneris Hosted Payment Page and e-commerce only. Schedule B may be possible if using point of sale terminals and no cardholder data storage.

  • Schedule A
    • Means that credit card information is never touched, stored or processed within an organization.
    • This is possible for organizations doing web sales using a hosted payment page (e.g. Moneris Hosted Payment Page).
    • If phone or walk up ticket sales by credit card are entered to a pin pad terminal, it may allow you to stay at Schedule A or move you to Schedule B; please talk to your PCI assessor.
  • Schedule B
    • Could apply to merchants who only use point of sales terminals at box office and do not store any card data:
      • Schedule B
        • Those who do not use electronic processing and write credit card slips by hand apply to this level.
        • Those that use stand-alone DIAL UP terminals to process credit cards may also apply. DIAL UP means that the stand-alone POS terminal is not connected to a processor until an authorization is required.
        • Not applicable to e-commerce channels.
      • Schedule B-IP
        • Merchants using only standalone, PTS-approved payment terminals with an IP connection to the payment processor, with no electronic cardholder data storage.
        • Not applicable to e-commerce channels.
  • Schedule C
    • Means that Theatre Manager will render the cards useless by shredding them after use and never storing the data in the database (voids are done by sending a token, refunds may need the card entered again).
    • If you do not want credit card information onsite, please select this option and select a merchant provider from one of the Direct Credit Card Processors.
    • This also changes the scope of which part of the system is needs to be included for PCI reasons.
  • Schedule D
    • Means that you wish to store some or all credit card data using strong encryption for a period of time. Possible uses are for recurring credit card transaction for monthly donations, or the need to refund to a patron if they are displeased with the show.
    • If you chose this option, you can choose how long to store data for previously authorized cards. After this Retention Period, all credit cards are shredded doing a deposit (End-of-Day (EOD) process) unless still required for a future post dated payment, or it has been specifically marked as retain permanently under the patron record.

Data Flow Diagram for Schedule C VS D

Click to enlarge this diagram and step through teh data flow differences between Schedule C and D.

Compliance History   Top

The following table illustrates a brief historical summary of Theatre Manager PCI compliance.

Version 11 Review

Version 11 PCI PA/DSS 3.20

  • Upgrade automatically occurs July 2020
  • Theatre Manager version 11.0.zz has been reviewed for its PCI PA/DSS 3.21 audit as part of the 3-year cycle.
  • The audit took place in Sep 16-20, 2019 the final document was approved by the PCI council with an expiry date of Oct 28, 2022 for new installations. The image (above) is from the PCI council's website of validated applications. Search for Arts Management.

Version 11 Review

Version 10:06 PCI PA/DSS 3.1

  • Upgrade Oct 2015
  • Theatre Manager version 10.06.zz has been reviewed for its PCI PA/DSS 3.1 audit as part of the 3-year cycle.
  • The audit took place in Oct 2015 the final document was approved by the PCI council with an expiry date of Oct 28, 2019 for new installations. The image (above) is from the PCI council's website of validated applications. Search for Arts Management.

Version 11 Review

Version 10:02 PCI PA/DSS 2.0

  • Upgrade Oct 2014
  • Theatre Manager version 10.02 was has been reviewed for its PCI PA/DSS 2.0 audit as part of the annual change cycle.
  • The audit took place in Oct 2014 the final document was approved by the PCI council.
  • All vendors are required to tell you this.

Version 11 Review

Version 10 PCI PA/DSS 2.0

Version 11 Review

Version 9 PCI PA/DSS 1.2

  • Upgrade to version 9 ASAP
  • Meets the PCI PA/DSS 1.2 standard and approved by the PCI council in Dec 2010.

Version 8

Version 8 PABP 1.4

Version 7

Version 7 - Self Assessed in 2006

  • Implements the standards required of PABP 1.4 (as of 2006), including 3DES high encryption of cards and does not store any track II or CVV2 information. However, this version is neither audited nor certified by an external vendor (not a requirement from the PCI council at the time). Version 7 has name security measures as version 8 and was simply renamed version 8 as part of the audit.

Version 6

Version 6 - Self Assessed in 2003

  • Implements almost all PCI security features in effect at the time (early 2000's). Card encryption is DES and it does not track CVV2 information. Version 6 can be considered PCI-compliant.

Network Diagram for PCI Compliance   Top

TM Network Setup Diagram - Click to Enlarge

This block diagram explains the general setup of a network that is required to implement Theatre Manager in a PCI-compliant manner. Feel free to print this setup document. If any part of the network setup cannot be made to comply with the diagram, you will need to address that at a later date to become PCI-compliant. Some sample machine requirements are in the table in the picture, or you can view descriptive information on sample computer specs.

  • PCI compliance requirements for Credit Card authorization
    • Overview
      • There are 7 parts to the basic network in the diagram above that are described in more detail in the following sections. The firewall is the glue that connects them all together, yet protects each part from the other (also see firewall rules). Only 4 parts are in PCI scope, the others are simply illustrations of how customers, volunteers, actors and other devices interact with your network.
    • In PCI Scope (inside the firewall) if they touch credit card info:
      • The main firewall
      • The DMZ contains only the Apache server and restricts what can be accessed from the internet.
      • OFFICE Lan - all wired devices in the office. Computers that access any Credit Card information should always be hardwired, or access via a secure VPN
      • Remote box office
    • Out of PCI Scope
      1. You can exclude ranges of workstations if you've told TM that they cannot process cards by creating a subnet mask that focuses on only those that can in the System Preferences->PCI Tab
      2. You can exclude the database server if you set TM to be PCI Schedule Ccompliance in the System Preferences->PCI Tab and sue P2PE decides and hosted payments for online.
      3. Outside the firewall - basically the internet and customers purchasing online
      4. VENUE Lan - any staff, volunteers, or actors using wired or wireless devices and who are not capable of processing or looking at credit cards.
      5. Ticket scanners used at the venue
      6. P2PE devices like Moneris P400 which do not share PCI related data with Theatre Manager. Theatre Manager simply activates the P2PE device, which is outside PCI scope as there is no direct connection to the device from Theatre Manager.

AMS Private Cloud Diagram for PCI A, B or C   Top

Overview   Top

Venues using Theatre Manager can take computers out of PCI scope as per the diagram below. A device is in scope if a credit card touches or passes through it. Devices are out of PCI scope if they can never see any credit card information pass through at any time. AMS Cloud causes most things to be out of scope, and you can limit it further. It is possible to implement the same PCI scope within your own environment if desired.

AMS cloud allows a merchant to target the possible compliance levels to Schedule A, B, or C. Since most venues have face to face or phone orders, the default is Schedule C, but you may wish to reduce the number of machines in scope to the minimum. It can take all machines out of scope in the office environment using dial up or IP pin pads, you may be able to achieve Schedule B (very much dependent on your bank):

  • Schedule A Merchants using only e-commerce transactions and Moneris Hosted Payment Page. All e-commerce authorizations occur at Moneris, and card data never enters the network
  • Schedule B Merchants using only: Imprint machines with no electronic cardholder data storage; and/or Standalone, dial-out terminals with no electronic cardholder data storage. Not applicable to e-commerce channels
  • Schedule B-IP Merchants using only standalone, PTS-approved payment terminals with an IP connection to the payment processor, with no electronic cardholder data storage. Not applicable to e-commerce channels.
  • Schedule C Merchants with payment application systems connected to the Internet, no electronic cardholder data storage. Not applicable to e-commerce channels.
  • Schedule A-EP Merchants using hosted payments for web sales like Moneris

PCI Scope Diagram for AMS Cloud   Top

PCI Scope Diagram for AMS Cloud

The legend shows machines and network segments:

  • Organizational Areas:
    • that will never see credit cards (GREEN)
    • where a credit card passes through the machine while in flight to the bank during an authorization and is immediately gone (PURPLE). Cards in these zones are:
      • transmitted via TLS and
      • live for an instant in time and
      • are NEVER stored in a database
    • where the card data is outside the boundaries of the organization. Examples are in the customers hands (or wallet) or at your bank or service provider (who are required to perform their own PCI compliance) (RED)
  • TCP/IP Traffic:
    • RED ARROWS - traffic where there is absolutely NO card data ever transmitted
    • BLUE ARROWS - traffic where card data travels (encrypted and via TLS) while it is IN FLIGHT for an authorization. This means that a message is sent for credit card authorization and the card resides only in memory (and is never stored in any disk file)

Workstation Components - Option 1


  • Possible PCI Level(s)
    • B
    • B-IP
    • C
  • Goals
    • Use a POS pin pad device
    • This takes a workstation out of PCI scope and allows the workstation to use any software on it that can reach the internet (e.g. email and web browsing).
    • Credit Card authorization is via a P2PE pin-pad using:
      • Dial up or IP connectivity that is completely independent of Theatre Manager and not connected in any way
      • OR using a device like the Moneris P400 where Theatre Manager talks to Moneris cloud to activate the pin pad. There is no direct connection between Theatre Manager and the P400
    • If all workstations are subject to this rule, then Schedule B compliance may be possible (subject to your Bank's ruling).
    • Risk of card being part of TM components is ZERO.
    • Risk of any data breach limited to person hacking the standalone POS terminal.
  • Steps
    • Indicate to TM that a workstation cannot authorize credit cards by indicating a CIDR subnet that is outside scope of the network
    • Use a stand-alone P2PE pin pad device that talks to the bank without connecting to the Theatre Manager Workstation. These must be purchased from your bank or service provider and come in many varieties such as wireless, dial up, ethernet connected, accept Apple Pay, chip and pin cards, etc.
  • Pros & Cons
    • Can still authorize credit cards for walk up and phone sales via external terminal.
    • Workstation can be used for any purpose such as email, web, analytics as it is not subject to PCI scope.
    • End of day is broken into web sales and other payments for box office.

Workstation Components - Option 2


  • Possible PCI Level(s)
    • B
  • Goals
    • No credit card authorization at all
    • This option should definitely be used for all non-box office computers or computers used primarily for setup, reporting and analysis.
  • Steps
  • Pros & Cons
    • Workstation can be used for any purpose such as email, web, analytics as it is not subject to PCI scope.
    • Only web sales will have a settlement for credit cards.

Workstation Components - Option 3


  • Possible PCI Level(s)
    • C
  • Goals
    • The workstation is defined as one of those that may accept credit cards entered into the system so that it does.
  • Steps
  • Pros & Cons
    • Since Theatre Manager does the authorization, it can also do a void or refund. Depending on the credit card provider, it can be as long as a year after Bambora using authorization toke.
    • Authorization will use higher level TLS transport encryption if supported by merchant services provider.

Workstation Components - Option 4


  • Possible PCI Level(s)
    • A
    • C
  • Goals
    • NGINX and TM Server can be in or out of scope depending on processor choices
  • Steps
  • Pros & Cons
    • Under Moneris hosted payment page processing, TM does not see any card data, just the authorization, allowing for PCI A.
    • Hosted payments does not support the feature of post dated payments online.
    • Advantages are no data enters the network, and you can be PCI A compliant.
    • Disadvantages come with inability to use post dated payments, and perhaps processing refunds.

AMS Private Cloud Components

Credit card data can never be stored on the AMS Cloud, taking the database server out of scope. Credit card data can pass through the firewalls and security appliances on the way to your Service Provider for authorization. It is transferred via TLS 1.2 and is subject to SPI (Stateful Packet Inspection), DOS detection, rate limitation, etc. to ensure security and privacy.

Bank & Service Provider Components

This is the merchant provider you selected out of those supported by Theatre Manager. The bank is not in scope of you PCI compliance requirements.

AMS Cloud Risk Profile   Top

Theatre Manager, the AMS Cloud, and POS terminals offers a very low PCI risk profile (almost negligible) for the following reasons:

  • Card data never enters your network - no risk
  • Cards are authorized using standalone pin pad terminals sold by the bank. This represents a negligible risk as only the physical device, sold and certified by the bank, could ever be compromised. Even if it were, it is not part of your network and has no communication with TM
  • Card data is never stored on disk. Having no card data in the database means no risk and no PCI exposure even if the entire database was given into the wrong hands. There simply is no card data in it.
  • Card data is transmitted from the user to the bank via TLS 1.2 (transport layer security) which is the highest form of security for sending data on the web.
  • Card data lives on the AMS network only for that instant in time needed to get to the service provider. TLS 1.2 cannot be sniffed by bad guys - very low risk
  • The TLS certificate can be reissued as often as you want to ensure that your key strings are secure. Google signaled intent to re-sign certificates every few months as additional cautions for commerce.

PCI UserID and Password Requirements   Top

See current help pages.

Main Firewall   Top

See current help pages

Office Lan   Top

See current help pages

Venue Lan   Top

See current help pages

The MDZ (NGINX Server)   Top

See current help pages

Policy Manual   Top

See current help pages

Remote Box Office   Top

See current help pages

Outside the Firewall (the internet)   Top

See current help pages

PCI Audit Logs   Top

See current help pages

Compliance Statement (required by PCI Council)   Top

See current help pages

Miscellaneous Requirements   Top

See current help pages