> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://learn.nuwebgroup.com/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://learn.nuwebgroup.com/_mcp/server.

# What questions should you ask a ticketing provider before signing?

> Questions to ask about ticketing contracts, payments, service levels, implementation, customer data, integrations and exit rights.

**Before signing with a ticketing provider, ask precisely what the service will deliver, who is responsible for payments and customer data, how incidents are handled, what changes cost and how you can leave.** The answers should appear in the agreement, its schedules or referenced technical specifications—not live only in sales emails or demonstrations. Questions about functionality are as important as questions about price because a missing workflow can become a major operating expense.

A good pre-contract review connects commercial promises with the actual roles, rights and system behaviour a business depends on.

## Which capabilities are included in the agreement?

**Ask the provider to define the purchased product and separate standard capabilities from configuration, integrations and custom development.** Useful questions include:

* Which event types, sales channels, seating models and access-control modes are included?
* Which features require additional licences, volume bands, feature activation or development?
* What is available in the current product, and what is only on the roadmap?
* Which company users can administer events, refunds, customers, permissions and reports?
* Are accessibility, language, currency and localisation requirements supported for our target markets?

Request a requirement matrix incorporated into the procurement record. A supplier statement that something is 'possible' may mean anything from an admin toggle to a six-month development project.

## Who controls the brand, checkout and customer relationship?

**Separate presentation, technical control and commercial responsibility.** Ask whose domain hosts ticket sales, whether checkout can be embedded or customised, whose name appears on confirmations and customer service messages, and whether the service is branded by the provider.

Also establish who contracts with event organisers, who sets fees, who can offer promotions and who handles customer support. A white-label appearance does not, by itself, establish any of these commercial rights.

If the provider supports a custom frontend, agree what APIs and components are included and who maintains them. If custom journeys depend on fragile undocumented interfaces, that risk should be visible before signature.

## What should you ask about payments, fees and settlements?

**Clarify the flow of money before comparing headline ticketing fees.** Ask:

1. Who is merchant of record for each sales model and market?
2. Which legal entity contracts with the payment processor and holds settlement obligations?
3. Which platform, booking, transaction, gateway and refund fees apply—and who pays them?
4. When are funds remitted, and what deductions, reserves or chargeback exposures may apply?
5. How are refunds, deposits, split payments and failed transactions reconciled?
6. Can the business choose a payment provider or use existing merchant arrangements?

Different payment setups can require different compliance and finance processes. Have finance and legal reviewers check the contractual description against the actual payment workflow. A fee model that appears attractive at one ticket mix may change substantially at another.

## What should the agreement say about reliability and support?

**Service commitments should define a measurable service and a usable response process.** Ask what uptime covers, how it is calculated, which exclusions apply, and whether a successful checkout is measured separately from a website being reachable.

Confirm priority definitions for critical events, response and restoration targets, on-call availability, planned maintenance, incident communications and post-incident reporting. A service credit may be commercially useful, but it does not replace lost ticket-sales opportunity or an operational response plan.

Find out who coordinates failures across payment gateways, cloud services, scanning devices and third-party integrations. Named incident ownership is particularly important when several suppliers are involved.

## What data and integration rights do you need?

**Ask not only whether data can be viewed, but whether it can be used, moved and recovered for legitimate business purposes.** Clarify access to event, customer, ticket-holder, order, transaction, scanning and reporting records.

Ask for documentation of API scope, token permissions, rate limits, webhooks, export formats and versioning policies. Who can revoke access? What happens when a feature is changed or retired? Can the business receive complete records on a regular schedule rather than requesting one-off vendor extracts?

Data 'ownership' is not a substitute for defining privacy roles and contractual rights. In jurisdictions where controller-processor rules apply, a separate processing agreement may be needed. [The ICO's UK guidance](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/contracts-and-liabilities-between-controllers-and-processors-multi/) includes end-of-contract processing and audit issues, but legal obligations vary by geography and use case.

## What are the actual implementation commitments?

**A delivery plan should name dependencies, acceptance tests and the party responsible for each task.** Ask who maps event, customer and seating records; who configures payment accounts; who builds integrations; and who trains venue and finance staff.

For an existing operation, ask what happens to tickets sold before migration, wallet passes, memberships, refundable orders and legacy financial records. Agree whether launch will be phased, what determines readiness, and who can delay cutover if critical defects remain.

Avoid signing up to a fixed launch date that depends on undefined data quality, unavailable API work or unconfirmed payment acceptance.

## Which contract terms deserve particular attention?

**The highest-impact terms determine what can change during the relationship and how the business exits it.** Review:

| Term                        | What to clarify                                                          |
| --------------------------- | ------------------------------------------------------------------------ |
| **Pricing changes**         | Indexation, new fees, minimum commitments and volume tiers               |
| **Service changes**         | Roadmap promises, feature withdrawal and API deprecation notice          |
| **Responsibility**          | Liability limits, exclusions, subcontractors and incident duties         |
| **Data handling**           | Processing roles, retention, security, sub-processors and breach notices |
| **Intellectual property**   | Ownership of custom developments, branded assets and exported data       |
| **Termination**             | Notice periods, early exit charges and transition assistance             |
| **Post-termination access** | Export timing, format, charges and historical record availability        |

Questions about legal effect and enforceability should be resolved with qualified counsel, especially across multiple jurisdictions. The point of this checklist is to surface decisions before they are buried in contract language.

## How should you verify answers rather than accept assurances?

**Turn important answers into demonstrations, tests and written commitments.** If a supplier promises restricted organiser access, test a user who must not see another organiser's event. If it promises an API-led checkout, complete an interrupted order and verify the final reservation and payment states.

Ask for evidence of peak-event support, sample incident reports, security assurance within the correct scope and a sample data export. For changes that will happen later, record acceptance criteria and remedies if delivery does not occur.

A useful agreement makes operational boundaries clear enough that two teams can follow it during an incident—not only when the relationship is going well.

## What is the single most important question before signing?

**Ask: 'Can we run our real business on the service that is contractually included, and what happens when something goes wrong or we need to change it?'** That question brings capabilities, economics, support and exit arrangements into one decision.

The strongest procurement outcome is not a contract with the most promises. It is one where **the buyer and provider share the same, testable understanding of the service**.

## Related explanations

#### [What should you look for in a white-label ticketing provider?](/strategy-selection/what-should-you-look-for-in-a-white-label-ticketing-provider)

Strategy & Selection · Choosing a provider

#### [What scalability evidence should a ticketing provider provide?](/strategy-selection/what-scalability-evidence-should-a-ticketing-provider-provide)

Strategy & Selection · Choosing a provider

#### [How do you compare enterprise ticketing infrastructure providers?](/strategy-selection/how-do-you-compare-enterprise-ticketing-infrastructure-providers)

Strategy & Selection · Choosing a provider

#### [What do large event organisers expect from a ticketing platform?](/strategy-selection/what-do-large-event-organisers-expect-from-a-ticketing-platform)

Strategy & Selection · Choosing a provider

[More in Strategy & Selection →](/strategy-selection)