1. Default is Schedule "D" compliance: for post dated payments only. In this case, encrypted credit cards are stored in the database only for as long as is needed for a post dated payment. This:
   • drastically limits any risk exposure and
   • should be used if the Merchant Profile option below is not suitable for the venue - such as Moneris who charges exorbitant fees for the privilege.
2. Schedule 'A-EP' if using Moneris Hosted Payment Page. This has other benefits for the venue like verified by visa, possible apple-pay online, and online debit.
3. Schedule "C" compliance with two sub-options:
   • do not store any credit card data in AMS cloud at all.
   • refunds are done by tokens for a period of time (currently seems to be 120 days after purchase).
   • (optional) implement any need for post dated payments via use of merchant profiles, if supported by your merchant provider. This adds card tokenization (not subject to PCI) specific to your merchant processor. Cards are still never stored in the database. Most merchant providers do not charge for this, Moneris does.

• It needs to be at least 5 megs up/down.
• Far better is higher download like 50+ down and 5 or 10 up.
• Test speed if need be using a login to an existing cloud client from client venue
Make sure client knows that we expect this to be dedicated to the sales process and not used for simultaneous download of large video files.

• We will create a custom TLS certificate for the venue (such as tickets.myvenue.org) using the standard processes

• Stop all their services on their site
• Make a backup copy of the database. Typically 30-45 minutes and depends on size of database. This can be determined exactly by looking at backup start time and last modified date on any backup.
• FTP the database to artsman. This is probably longest step and is mostly dependant on the client's upload speed. It can generally be calculated by testing their upload speed using a reading from speedtest.net inside their network and calculating

  Approx. time (minutes) = upload speed * database size in bytes / (8* 60)

• Load up the database to the cloud server. A reasonable estimate going to be about 10% of the time it takes to make a backup.
• Add in an estimate of time for updating versions of Theatre Manager to the latest. eg:
  • From any Version 10 should be short.
• Add an hour for contingency or (if the timing must be precise, do a practice run).

• Make an TheatreManager[myVenue] user in the main AMSCloud Postgres server and create a complex password (PGadmin can be used)
• Create an empty main Database and Test database for the customer with owner being the TheatreManager[myVenue] user
• Make an entry in the AMScloud database to register these two databases under the CustomerNumber
• Find the customer in Daylite and look for the Remote Access note. Add in the connection information for the AMSCloud which will include:
  • The customer number
  • The password for accessing the AMSCloud database.
  Note that is password is only for connection and is not the TheatreManager[myVenue] user account info. The patron can be told what this is, so it needs to be reasonably complex with mix of upper/lower/numbers. It should not be really obvious or follow a pattern from customer to customer so that it is predictable.
• Set up the backup script for dumping the database individually to another machine. It will be part of replication automatically

• PFSense Router
  • Determine an IP address for the virtual machine and assign to the DHCP settings
  • Edit the routing table on the to point tickets.myvenue.org to this virtual machine
• Virtual Machine
  • Create the virtual machine to be used for web sales and make sure it works

• Edit the config to point tickets.myvenue.org to this virtual machine
• Set up the TLS that was purchased for the client

• Log into the Virtual Machine that was set up for the client
• Install apache or web services as required
• Put the initial web pages in place
• Set up a git repository so that we can maintain version control on web pages and back them up

we will create the DNS record for myvenue.hosted.artsman.com

• Shut down web sales at the client site
• Turn off all user access by editing the ph_hba.conf so that only pgadmin and local clients can log in
• Run a backup
• FTP it to artsman site
• Set access on the file to be RWXRWXRWX - can be done with fetch

• Drop and recreate the database if it has anything in it
• Use PGadmin or terminal to load the database from the FTP folder to the production AMScloud postgres server

This occurs automatically when Theatre Manager Server started on the Sites Web Sales VM

set timezone 'xxxx'; Update F_PLAYBILL set PB_PERFORM_DATETIME = null returning PB_SEQ,PB_PERFORM_DATETIME

When it works internally:

• Relay that information to the client and assist them logging on the box office work stations
• Provide them with an email detailing how to do this for their other workstations
• Have them do a test purchase, including authorizing a credit card - using their card
• have them run a void on the credit card sale

• Adding a patron to their web site
• purchasing tickets, donations and gift certificates
• finishing the sales process and using a test card 4242 4242 4242 4242 - and getting a rejection

• Create an account on their web site and receive an email -or
• Request a password change for your own id, if you have one on their web site

If the client uses Facility Management, make sure the scheduling email and pop/imap server work.