Schedule A/B/C/D Compliance - Self Assessment Questionnaire

The Self Assessment Questionnaire (SAQ) 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 the table to the right to help determine the level that applies to your organization below.

Compliance Summary

Theatre Manager can achieve compliance for

schedule 'A' using Moneris Hosted Payment Page and only web sales with no card holder data storage

schedule 'B' or 'B-IP' if using pin pad machines for walk up and using Moneris Hosted Payment Page for web sales with no card holder data storage

schedule 'C' using a setting in System Preferences for venues processing cards through TM for both box office and e-comerce -and- no storage of card holder data

schedule 'D' using a setting in System Preferences for venues processing cards through TM for both box office and e-comerce -and- storing cardholder data for any purpose such as recurring transactions and post date payments.
schedule 'A-EP' Merchants using hosted payments for web sales like Moneris

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 the table above, 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 card holder 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 (eg 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 standalone 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 also chose how long to store data for previously authorized cards. After this 'Retention Period', all credit cards are shredded doing a deposit (end of day process) unless still required for a future post dated payment, or it has been specifically marked as retain permanently under the patron record.

Shredding Credit Cards

	Theatre Manager can implement either Schedule "C" or "D" for the SAQ - the choice is yours. You can define a retention period for credit card information in Theatre Manager on the System Preferences on the PCI Security Screen before it is 'shredded' per PCI DSS standard 3.1
	A card is stored in the database is only contained in one table/field called fCreditCards.CD_CARD_NO. There are no other permanent or temporary locations where it is stored. The card number can be removed using the shred feature. PCI DSS standard 3.1

Notes:

A shredded card is stored in the database as '#### **** **** ####'. This renders the PAN useless for all purposes. However, if given the first 4 and last 4 digits of any card, you can still search for and find the patron who used a card starting and ending with those digits (the card, of course, will not exist in the database).
Schedule "D" compliance with about 120 days of retention is sufficient for most venues, especially if you are using post dated payments or may have to deal with refunds for cancelled events
Schedule "C" compliance means that no card information will every be stored in the database. It means cancellation of an event will need the customer service team to call a patron to get the card to process a refund, or to convert any refund to patrons to store credit such as a gift certificate.

Reencrypting Credit Cards

Credit cards stored in a database must be encrypted using a key that is distinct to the venue per PCI DSS standard 3.6. This must occur:

Immediately after the initial implementation and data conversion has taken place
on a minimum of an annual basis. If the procedure is not invoked manually, it will be done automatically during any upgrade.
if there is any suspected security breach at the organization

It can be invoked manually by using a button on the System Preferences on the PCI Security Screen to re-encrypt cards.

CVV2 requirement and possible effect on post dated payments

Your merchant processor may be set up to require use of CVV2 - which is a setting you may wish to turn off in their online portal, if you follow the steps below.

Theatre manager cannot store the CVV2 data per the PCI council.

The chart on the right indicates which data can be stored and it is explained further in PCI Requirement 3 rules.

Since the vast majority of credit card transactions are real time with a CVV2, most venues will see limited effect for 99% of credit card authorizations:

It will affect:

situations where the credit card provider is down or unreachable - a rare occurrence which does happen
authorizing existing post dated payments and recurring donations

It may affect:

Mail order - since your customers should not write the CVV2 on any form you send to them to remain PCI compliant.

Set your MERCHANT SETUP to NOT require CVV2 in their ONLINE PORTAL

Theatre Manager does not store CVV2 data (per PCI compliance). It cannot send CVV2 for post dated payments. You have two ways to address this:

Turn OFF CVV2 requirements for your merchant account AT THE BANK
- Turn off CVV2 requirements at your merchant
- Leave CVV2 as a requirement in TM's merchant setup
- Authorize the post dated payment in end of day.
- This means TM will send one if it has one (for first time authorizations), and the bank will accept a charge if it does not (post dated payments)
Use Theatre Manager's Merchant Profiles feature. (note: do not use this feature for Moneris)
- This is a feature where you initially send all the credit card data to the bank
- The bank returns a token to Theatre Manager, which is stored in the database
- From that point on, Theatre Manager will use the token for post dated payments, eliminating the need to store the credit card
- This works because the token uniquely identifies the merchant (you), the patron, and a specific card.

Setting Theatre Manager to Require CVV2

Please confirm the following three settings for your venue:

'Send CVV2'/CID number is checked in the merchant profile->Authorization Tab.
Require Credit Card CID/CCV2 is checked for all credit cards payment methods
Each employee's security setting in the Employee Access->Function tab is unchecked so that CVV2 is no longer optional for that employee.

Effect of CVV2 on Emergency Mode

Theatre Manager's Emergency Mode was designed for situations where the credit card company's processing was down or not available. This requirement for CVV2 (plus the inability to store it) means that the Credit Card companies prefer Real Time Authorizations.

Note: if a card is declined for lack of CVV2 after emergency mode is tuirned off, it likely would have been declined anyway. you'll need to call the patron to get the CVV2 # when your services come back.

Effect of CVV2 on Post Dated Payments

If you can make one post dated payment work (without CVV2), then they will likely all work. Theatre Manager does not store CVV2 data (per PCI requirement 3.3).

A alternative is to explore merchant profiles as mentioned above (do not do this for Moneris)

How will Theatre Manager respond to Post Dated Payments?

We have felt for a long time that the unstated direction of the bank industry was elimination of card data storage at a merchant. It is fortunate that we anticipated this as have a project underway to migrate patron card information to the bank and use tokenization instead. Effectively, this means:

When a patron use a card for the first time, TM will direct your merchant processor to store the card data and provide Theatre Manager a unique token for that card
If you are setting up post dated payments, TM will then refer to the patrons token at the bank for future authorizations - which is consistent with the Bambora statement

How will switching merchant providers affect Tokenized Post Dated Payments?

If the post dated payment token is stored at the merchant processor and is unique to your merchant account, it adds a step when switching from one merchant provider to another. You will need to keep your old merchant account active until all future post dated payments set up for your original merchant provider are completed and authorized.