Settings Use settings to define the overall behaviour of the shop catalogs for your event. This includes configuring the shop currency and applicable tax rates, also the choice of and behaviour of associated payment service providers. Note that Visit does not handle payments directly, but partners with a number of external providers to provide this service. Payment Service Provider This section configures the options for connected payment services. To take real payments through your shop, you’ll need to have a Payment Service Provider configured with a connected merchant accounts. All payment service providers also offer a testing environment, with a second set of user credentials. This enables you to simulate payments for both successful and unsuccessful transactions before taking real payments from registrants. Generally a test environment will only accept ‘test’ card details, which will be supplied by the provider, whereas a live payment will expect real card details. By default a Visit registration form will assume the transaction is real, so will use the configured Live payment service provide profile. To submit a test payment, use the testing tools available within the form editor: from Live PSP profile, select a configured live Payment Service Provider. These are set up in Visit Create under Organisation->PSP Profile Setup. This list only contains configurations defined as the live type Select an associated Test PSP profile. These are set up in Visit Create under Organisation->PSP Profile Setup. This list only contains configurations defined as the test type. Typically you will use a test and live PSP profile from the same provider. Optionally select an Onsite PSP profile for taking onsite payments at events. Currently we support Stripe payment terminals only, please contact us for further information on the availability of this service in your region. Select the Payment period (in days). This is the time window within which Visit will await a confirmation of successful payment from the PSP. For example some payment methods offered include a deferred payment. Beyond this time Visit will mark the transaction as having failed. Payment code prefix enables you to enter your own identifier to prefix Visit’s payment IDs. Since Visit payment IDs don’t reveal anything about the related event, you can add your own custom prefix to help differentiate the transactions within your Payment Service Provider’s data. Use this optional property if you use the same account to take payments from multiple events. Select Invoicing to enable offline payments. For this kind of transaction, you are responsible for marking the payments as complete, either in the Visit Create user interface or via the API. Note that an event must always offer a PSP based payment collection as a minimum. Invoicing provides an optional second method for a registrant making payments. The option to pay online or by invoice is presented to the registrant when checking out their basket. Shop Shop settings define the currency, tax display preference and the handling of any associated transaction costs. Currency and Tax behaviour Select the currency for the shop products. The available currencies will depend on the capabilities of the connected Payment Service Provider. Note that a Visit event can display catalog pages in a single currency only, however same Payment Service Providers may offer conversion within their payment environments. Set the Tax behaviour to control the entry of prices against shop products. Be careful not to change this setting after prices have been entered. Visit will warn you about the risks associated this setting, which will over-value or under-value existing products. When entering product prices, see the onscreen messaging about whether prices are inclusive or exclusive of tax Show prices controls whether prices shown onscreen in catalog pages and int he basket environment are shown inclusive or exclusive of taxes. Taxes are always displayed in the final checkout phase. Transaction Costs To apply a transaction cost to the order, you’ll need to have at least one product defined as a Transaction Cost type. Note that only one transaction product can be in use for all catalogs at any point, though it’s possible to define multiple in the products list to switch between. Transactions costs can be configured to be added once to each purchase (for example, a registrant who upgrades in the future may be subject to two transaction costs). Alternatively the transaction cost can be applied once per ticket, so it cumulative depending on the number of tickets purchased. For this workflow, your shop products must have a ticket document associated with them. See products for more information. Basket Hold Time The time (in minutes) defines the duration from first addition to the basket during a registration to the basket timeout. The time countdown is presented to the registrant in the basket when viewing it within a registration form. During the time, any items with restricted availability (by date or by quantity) are assumed to be reserved by the current registration. They are free up when the hold time expires, or the registrant chooses to manually remove them from their basket. Tax Classes Use tax classes to set up one or more rates to be used within your shop items. Depending on your geographical region and local policies, any taxes which apply can vary depending on the kind of goods or service being purchased. To add a new tax class: Define a name for your tax class, and set the rate (percentage) Optionally you can provide a description, for your own use. This is not presented in shop catalogs or baskets Set the default tax class to assign to products you configure in the shop. Note that it’s always possible to remove the tax from a product, or to select one of the other (non-default) classes defined. It’s recommended to define tax classes before adding shop products, so that they are available when setting pricing. If you change the definition of a tax class once a shop is live, that will affect the rate applied to products assigned that tax class from that point onwards, so caution is needed. Generally the tax rates will be known and assigned (in line with local requirements) before beginning to process real payments.
