22. Payments - Payment Processors

Connect and configure payment gateways to process card payments and other online payment methods across your ticket shop and box office.

A payment processor (or gateway) is the external service that authorises and captures electronic payments on your behalf. Before you can accept online payments, you need to connect at least one payment gateway and configure it for the channels where you want to accept payments.

The platform supports over 25 payment gateways. Each gateway connects using credentials from your gateway account, and can be enabled separately for the ticket shop and box office. The gateway you choose affects which payment methods are available to your customers - some gateways offer only standard card payments, while others support local payment methods, in-person terminals, or mobile wallets.

To connect a payment gateway:

1. Navigate to Settings > Payment

2. Find the gateway you want to connect in the Payment gateways section

3. Click the gateway to open its settings

4. Enter your gateway credentials (API keys, merchant IDs, or other details specific to the gateway)

5. Click Save - credentials are validated before being stored

Most gateways require separate credentials for test (demo) and live modes, entered on different tabs within the settings modal. A few gateways - Stripe, PayPal, and SumUp - use an OAuth connection flow instead, where you click a connect button and authorise the platform to access your gateway account.

Gateway credentials are encrypted before being stored. If you need to disconnect a gateway, you can revoke its credentials from the same settings panel.

After connecting a gateway, you choose where it's available:

A gateway can be enabled in one or both channels. You can also have multiple gateways connected simultaneously - for example, Stripe for the shop and a different gateway for the box office.

When multiple gateways are enabled for the same channel, you need to designate one as the primary gateway. The primary gateway is the default used for processing payments in that channel.

Primary gateways are set independently for each channel:

• Shop Primary - the default gateway for ticket shop transactions

• Box Office Primary - the default gateway for box office transactions

To set a primary gateway, click Set primary gateway on the gateway you want to use as the default for that channel.

A gateway must be enabled for a channel before it can be set as the primary for that channel.

Each company has a payment mode that controls whether transactions use live or test credentials:

The payment mode toggle is found at the top of Settings > Payment. Switching between modes is only available when your account manager allows self-management of payment mode.

Switching from demo to live mode means all subsequent transactions will process real payments. Verify your live credentials are correct before switching.

Not all gateways work the same way. The platform handles four distinct integration patterns, each providing a different checkout experience:

The payment form appears directly within your checkout page. The customer enters their card details without leaving your site. The form is rendered by the gateway's JavaScript SDK, so card details are transmitted securely to the gateway without touching your servers.

Gateways using this approach: Stripe, Adyen, Nuvei, Onvo

This is the smoothest customer experience - no redirects, no page changes. Stripe's Payment Element also supports wallets (Apple Pay, Google Pay) and local payment methods within the same embedded form.

The customer is redirected to the gateway's hosted payment page to enter their card details. After payment, they're redirected back to your site.

Gateways using this approach: QuickPay, PayTabs, Worldpay, DPO Pay, SimplePay, Revolut

The customer briefly leaves your site, but this approach can be simpler for gateways that don't provide an embeddable SDK.

The platform generates a hidden form with encrypted payment data and submits it directly to the gateway's endpoint. The gateway processes the payment and redirects the customer back.

Gateways using this approach: Barclays ePDQ, Pay Retailers, Bloomin, Banorte, Transbank

Similar to redirect from the customer's perspective, but the technical mechanism differs - the form is submitted from your site rather than navigating to a gateway URL.

Card details are tokenised client-side (if needed) and the payment is processed entirely via server-to-server API calls. The customer stays on your checkout page throughout.

Gateways using this approach: Authorize.NET, Tap, PowerTranz, Netpay, Curlec, M-Pesa, Hyperpay, SumUp

For most of these gateways, the customer experience is seamless - they enter card details and the payment processes in the background.

The following sections detail each supported gateway, grouped by connection method. Each entry covers the credentials required, any special capabilities, and where the gateway operates.

These gateways connect via an authorisation flow - you click a connect button and sign in to your gateway account rather than manually entering API keys.

Stripe is the most feature-rich gateway integration on the platform. It uses Stripe's Payment Element for an embedded checkout experience and supports the widest range of payment capabilities.

Connection: Click Connect with Stripe to authorise via Stripe Connect. Your Stripe account ID and publishable key are stored automatically.

Capabilities:

Additional payment methods available via Stripe:

Stripe supports a growing list of local and alternative payment methods that can be enabled from the gateway settings. These include Klarna, Afterpay/Clearpay, Affirm, iDEAL, Bancontact, EPS, Przelewy24 (P24), GrabPay, FPX, Alipay, WeChat Pay, Cash App, and Swish. Each method is currency-restricted - the platform automatically shows only the methods that match the customer's order currency.

Apple Pay and Google Pay require your shop domain to be registered with Stripe. The platform handles this automatically on first payment, but custom domains may need the Apple Pay domain verification file to be accessible at /.well-known/apple-developer-merchantid-domain-association.

PayPal connects via OAuth and provides a PayPal checkout button that customers click to pay through their PayPal account or enter card details on PayPal's hosted pages.

Connection: Click the Authorize button to connect your PayPal account. Your merchant email and account details are stored automatically.

Settings:

PayPal supports two product types: Express Checkout and PayPal Commerce Platform (PPCP). The product type is determined during the OAuth connection and affects which features are available.

SumUp connects via OAuth and provides online card payment processing. It's a straightforward gateway suitable for simple card payment needs.

Connection: Click the authorise button to connect your SumUp account.

Settings:

These gateways require you to enter API credentials directly. Most provide separate fields for test and live credentials.

Adyen uses an embedded checkout form (Drop-in component) and requires webhook configuration for payment confirmation.

Credentials (test and live):

Capabilities:

• MOTO payments (enable the MOTO toggle)

• Webhook-based payment confirmation - the gateway settings display the webhook URL you need to configure in your Adyen dashboard

Adyen requires you to manually configure webhooks in your Adyen dashboard. The webhook URL is displayed in the gateway settings modal - copy this URL and add it as a Standard webhook in Adyen.

Revolut uses a redirect-based payment flow - customers are redirected to Revolut's hosted payment page to complete their payment.

Credentials (test and live):

Capabilities:

• Webhook-based payment confirmation

• Webhook management directly from the gateway settings (view, delete, and restore registered webhooks)

Worldpay redirects customers to a hosted payment page. It supports separate credential sets for standard (ecommerce) and MOTO transactions.

Credentials (test and live, for both ECOM and MOTO):

Settings:

Nuvei uses an embedded checkout form and supports Google Pay. It requires minimal configuration.

Credentials (test and live):

Settings:

Capabilities:

• Google Pay support

• Webhook-based payment confirmation

• MOTO payments (enabled automatically)

Authorize.NET processes payments via server-side API calls using the Accept.js SDK for secure card tokenisation.

Credentials (test and live):

QuickPay redirects customers to a hosted payment page for card entry.

Credentials (test and live):

Tap processes payments via server-side API calls and is commonly used in the Middle East.

Credentials (test and live):

Settings:

SimplePay is a Hungarian payment gateway that redirects customers to a hosted payment page. It supports multiple currencies with separate credentials per currency.

Credentials (per currency - HUF, EUR, USD, and SZEP):

Capabilities:

• SZEP card support (Hungarian employee benefit cards) - only available for HUF currency transactions

Each currency requires its own merchant ID and secret key pair. If you only accept payments in one currency, you only need to configure credentials for that currency.

Ryft connects via an email-based account linking flow and uses webhooks for payment confirmation. It supports automatic platform fee collection - your account manager's fees are deducted at the point of payment, so funds arrive in your Ryft account with fees already settled.

Configuration:

Settings:

Capabilities:

• Automatic platform fee collection - fees are split at the point of payment

• MOTO payments (mail order / telephone order)

• Webhook-based payment confirmation

When a partial refund is issued, the platform fee collected on the original payment is retained - it is not reversed proportionally. On a full refund, the platform fee is automatically reversed.

Curlec (powered by Razorpay) processes payments via server-side API calls with support for platform/marketplace payment models.

Configuration (test and live):

Hyperpay supports multiple currencies with per-currency entity configurations. It's commonly used in the Middle East and North Africa.

Configuration (per currency):

Capabilities:

• Apple Pay and Google Pay (configurable per entity)

• Multiple entities per currency for routing payments to different merchant accounts

Hyperpay requires separate configuration for each currency you accept. Within each currency, you can configure multiple entities to support different card brands or payment channels.

M-Pesa is a mobile money payment method used primarily in East Africa (Kenya). Customers receive a push notification on their phone to authorise the payment.

Credentials (test and live):

The customer enters their M-Pesa phone number at checkout and receives a push notification to confirm the payment on their device.

DPO Pay (formerly 3G Direct Pay) redirects customers to a hosted payment page. It's used across Africa and the Middle East.

Credentials (test and live):

Onvo uses an embedded payment form via its JavaScript SDK.

Credentials (test and live):

Barclays ePDQ uses a form POST approach - an encrypted form is submitted to the Barclays payment endpoint.

Credentials (test and live):

PayTabs redirects customers to a hosted payment page. It requires the customer's billing address at checkout.

Credentials (test and live):

Pay Retailers uses a form POST approach and supports a variety of local payment methods across Latin America, including cash payments, online bank transfers, and credit cards. It requires the customer's billing address at checkout.

Credentials (test and live):

Netpay processes payments via server-side API calls with 3D Secure support. It is a Mexico-based gateway and requires the customer's billing address and phone number at checkout.

Credentials (test and live):

Transbank (Webpay Plus) is a Chile-specific gateway that uses a form POST approach via the Webpay SDK.

Credentials:

• Test mode: Test credentials are automatically configured - no manual entry needed

• Live mode: Enter your Commerce code and API key

PowerTranz (First Atlantic Commerce) processes payments via server-side API calls with 3D Secure 2.0 support. It is commonly used in the Caribbean.

Credentials (test and live):

Bloomin uses a form POST approach with optional 3D Secure support. It requires the customer's billing address at checkout.

Credentials (test and live):

Banorte uses a form POST approach and is a Mexico-based gateway. It requires the customer's billing address at checkout.

Credentials (test and live):

Some gateways require customer billing information at checkout. When you enable one of these gateways, the relevant fields are automatically added to the checkout flow.

Ryft also supports billing address collection but makes it configurable - you can choose none, minimum, or full address collection from the gateway settings.

Mail Order / Telephone Order (MOTO) payments allow box office staff to process card payments by manually entering card details provided over the phone or by mail. Staff enter the card number, expiry date, and CVV directly into the box office checkout.

MOTO is supported by:

• Stripe - enable the MOTO toggle in gateway settings

• Adyen - enable the MOTO toggle in gateway settings

• Worldpay - requires separate MOTO credentials (username, password, installation ID, and merchant code)

• Nuvei - MOTO is enabled automatically

MOTO capability may need to be enabled on your gateway account before it can be used. Contact your payment gateway provider to confirm MOTO is available on your account.

Physical card terminal integration allows customers to tap or insert their card at a connected terminal device for in-person payments. Currently, only Stripe supports terminal payments through Stripe Terminal.

To set up terminal payments:

1. Enable the Terminal toggle in your Stripe gateway settings

2. From the box office, select or register your card reader device

3. Wait for the reader to connect and any firmware updates to apply

4. Process payments by selecting the terminal payment method at checkout

The terminal supports tap (contactless), chip insert, and swipe payments. In Canada, Interac debit payments can also be accepted on the terminal when the Interac toggle is enabled.

In demo mode, you can use a simulated card reader for testing. Enter a Stripe Terminal test card number to simulate different payment outcomes.

Apple Pay and Google Pay are supported through Stripe and appear as wallet payment options within the embedded payment form when available. Customers using a supported device and browser see the wallet buttons alongside the standard card entry fields.

Hyperpay also supports Apple Pay and Google Pay, configured per entity within the gateway settings.

Your shop domain must be registered for wallet payments to work. The platform handles Stripe domain registration automatically. For Apple Pay specifically, the domain verification file must be accessible at /.well-known/apple-developer-merchantid-domain-association - this is served automatically for standard setups, but custom domains may need additional configuration. You can upload a custom Apple Pay verification certificate from Settings > Payment under Apple Pay domains.

Several gateways support region-specific payment methods beyond standard cards:

Local payment methods on Stripe are enabled from the gateway settings under Payment method types. Each method is currency-restricted - for example, OXXO only appears for MXN transactions, iDEAL only for EUR. The platform automatically filters which methods are shown at checkout based on the order currency.

OXXO payments are asynchronous - the customer receives a voucher to pay at a convenience store. The order moves to Awaiting local payment status until the payment is confirmed via webhook. The voucher expiry can be configured from 1 to 7 days (default: 3 days).

Stripe is currently the only gateway that supports saved cards. When a customer checks the Save this card for future checkouts option during payment, their card details are securely stored by Stripe. On subsequent checkouts, the customer sees their saved cards and can select one rather than re-entering card details.

Saved cards are stored per customer. The platform creates a Stripe Customer object for each customer who saves a card, linking their saved payment methods to their account.

In some configurations, your account manager may manage gateway credentials on your behalf. When this is the case:

• The account manager connects the gateway at the platform level

• Your company uses the platform credentials for processing

• You may not see credential fields or payment mode toggles in your settings

Gateways that support platform-level management include Stripe, SumUp, PayPal, Ryft, Curlec, and Nuvei.

When your account manager manages the gateway, certain gateways can collect platform fees automatically at the point of payment. Instead of fees being settled separately after the fact, the gateway deducts the platform fee before funds reach your account.

How this works depends on the gateway:

For gateways that do not support automatic fee collection (such as Adyen, QuickPay, and Worldpay), platform fees are tracked separately and settled through invoicing.

Whether automatic fee collection is active depends on how your account manager has configured your gateway. If you are unsure how fees are being collected, contact your account manager.

Common issues when configuring gateways:

• Introduction

• Payment Lifecycle

• Split Payments

• Deposit Payments

• Invoice Payments

• Default System Fees