Common issues when choosing existing platforms by fees or reputation alone

In municipal ticket sales digitalization projects, discussions often jump to asking whether existing ticket platforms or sales systems can be used because they are affordable, proven, or used by other municipalities.

The problem arises when the platform type doesn't match your program needs. Examples include:

  • Trying to run shopping vouchers and store payment programs solely through a single-event sales site
  • Attempting to handle multiple ticket types with custom settlement entirely within a nationwide digital coupon service
  • Forcing facility admission sales across multiple channels and web into a single-event sales page

While contract fees may appear lower, on the ground staff face increased manual work (duplicate data entry, exception handling, settlement transfers), and the operational burden digitalization was supposed to reduce returns—such cases are not uncommon. This article takes the approach of aligning who does what and how settlement works before comparing prices, letting the platform type emerge from requirements.

Document first | Operational flows and four program patterns

Paper presale tickets, cash at the counter, shopping voucher distribution—within ticketing in municipalities, who sells tickets (sales entity) and who receives revenue (settlement destination) vary by program.

Ticket digitalization discussions often begin in scenarios like:

  • Events and product fairs — Paid admission for limited-time events, reserved or general seating sales
  • Shopping vouchers and coupons — Premium shopping voucher distribution, local currency-style distribution and store payment
  • Museum and facility admission — Timed tickets for permanent or special exhibitions, combining counter and web sales
  • Tourism passes and transit bundles — Multi-facility passes or transit + facility sets (joint programs with transit operators)

For each program, document these three points on one page (this becomes the foundation for subsequent platform selection):

  1. Who sells tickets (municipality, tourism association, facility, event organizer, etc.)
  2. Who validates entry on-site (ticket window, gate, merchant terminal, etc.)
  3. Who receives revenue and how (single vendor or multiple, distribution rules)

If this page remains vague when sending out RFPs, returned proposals mix types, and each row in your comparison table operates under different assumptions.

Select platform type from requirements | Four categories with service examples

Once the page above is clear, choose the platform type. Platform type refers to the kind of service or public site you'll use for ticket sales, payment, and entry validation (standalone transit or lodging OTA programs are outside this article's scope).

Table scrolls horizontally

Category Service examples Good fit (requirement indicators) Common issues when type doesn't match
Digital coupon and shopping voucher platforms PayPay Shōhinken, e-machi, etc. Voucher programs centered on merchant payment (e-machi also supports tourism coupons and passes) Using only for reserved seating or gate entry event tickets. Trying to replace nationwide facility sales channels with this type alone
Tourism ticket distribution platforms Goodfellows JTB (Ticket HUB / Webket / PaaSket), etc. Connecting facility admission and experience tickets to web, travel agencies, convenience stores; entry check and revenue by facility (multi-facility passes available) Primary goal is voucher store payment. Municipality/DMO-branded programs needing web event ticket sales, merchant coupons, conditional distribution separate from facility admission distribution
Ticket sales system (cloud) e+ (Eplus), TicketMe, teket, etc. Ticket sales for a single event or performance (advance and day-of, seating; typically contracted under organizer name) Trying to handle voucher store payment or settlement beyond events under a single contract
Program-dedicated site SmartPlate Ticket, etc. Integrated design of multiple ticket types, custom settlement and eligibility rules, public site and ticket wallet together Requirements fit within standard vouchers, facility distribution, or single-event sales alone

Service examples are indicators for type selection. Confirm features and contract terms with each vendor when requesting quotes.

PayPay Shōhinken and e-machi — Vouchers and merchant payment

PayPay Shōhinken is a digital coupon distributed or sold through PayPay by municipalities, used by residents at participating merchant PayPay checkouts. Official materials list categories where it cannot be used, including entertainment tickets, online orders, and vending machines, making this type less suitable as the primary solution for gate entry or reserved seating sales. e-machi is a municipal package combining shopping vouchers, tourism coupons, and digital tickets for sightseeing. On-site operations center on merchant and facility payment terminals combined with app balance; dedicated entry check terminals or bulk connections to travel agencies and OTAs are outside its design. For premium shopping vouchers or programs with broad merchant participation, this type alone often suffices, while selling multi-facility admission through nationwide sales channels or managing event seating should be quoted separately in another category.

Facility admission tickets — Goodfellows JTB and similar

Goodfellows JTB's ticket platform combines Ticket HUB (channel connections, product registration, settlement), Webket (facility web sales), and PaaSket (entry check app) as a facility-by-facility distribution system. Admission tickets for individual facilities like museums or theme parks are sold through multiple channels—travel booking sites, agencies, convenience stores, facility websites—while on-site operations standardize QR code entry validation and revenue reporting. Multi-facility passes bundle admission across multiple sites into a single QR as a joint facility product (tourism passes, etc.). When municipalities or DMOs want to front-load branding and integrate event ticket web sales, merchant coupons, conditional distribution, and operator settlement separately from admission distribution, consider another type.

Single event or performance sales — e+, TicketMe, and similar

e+ (Eplus), TicketMe, teket, and similar services are cloud-based ticket sales for one event or performance. Sales channels—web, convenience store printing, day-of windows—vary by service, but designs typically stay within sales, entry check, and revenue reporting for the same event. Regional events, product fairs, and hall performances are typical use cases; most handle both advance and day-of sales and can support reserved seating and lotteries within the same event. Contracts are often under organizer names (cultural foundation, tourism association, executive committee), and when municipalities need wide-area settlement or multiple ticket types in a single wallet, the contract entity and feature boundaries may not align.

Program-branded dedicated sites

SmartPlate Ticket and similar program-dedicated sites design a public URL under the municipality, DMO, or executive committee brand, integrating eligibility rules, multiple ticket types, and operator-specific settlement as a unified system. This type is appropriate when you want users to see the program site and their ticket wallet (portfolio) under the same brand. If requirements are limited to event web sales alone or single facility admission alone, other types in the table often suffice. When advance event tickets, merchant coupons, conditional distribution, and transit bundles must run under unified operations with different rules, quotes for this type may appear.

Municipal ticket sales — From requirements to four categories
Municipal ticket sales — From requirements to four categories

After deciding type | Pre-RFP checklist

Once you know which of the four categories fits best, narrow to vendors within the same type for quote requests. Before that, share the following items among stakeholders to reduce post-contract operational mismatches:

  • Sales entity and contract name — Municipality name or tourism association/facility operator name
  • Program branding — Public site name, logo, domain
  • Sales period and refund policy — Including cancellation and severe weather scenarios
  • Settlement recipients — Revenue split approach when multiple merchants participate
  • Ticket type addition frequency — One-time event only or ongoing catalog expansion
  • Relationship to existing platforms — Whether you can migrate from contracted voucher or admission platforms
  • Personal data and payment handling — Handled directly by municipality or third-party
  • Settlement data and audit — CSV export and subsidy program reporting or audit requirements (if applicable)
  • Tourism passes and transit bundles — Operating-day and route constraints (if applicable)

Compiling the selected type and the checklist above into one page before RFP or quote requests helps reduce gaps between operational flows and contract terms.

See features and rollout examples on the service site.

FAQ

Where should we start with municipal ticket sales digitalization?

One-page operational flows (who sells / who validates entry / who settles) → Which of the four categories fits → Compare quotes among same-type services is the recommended sequence.

What if we want to use the same service another municipality uses?

It's a useful reference, but program type and settlement structure may not be the same. Mismatched types can increase operational burden, so prioritize documenting your own municipality's one-page flows first.

What if we want to handle vouchers and event tickets on the same smartphone screen?

For premium shopping vouchers centered on merchant payment, PayPay Shōhinken or e-machi are often candidates. e-machi also handles tourism passes, so verify fit with your one-page requirements. When multiple programs with different eligibility, ticket types, and settlement need unified public site operations, program-dedicated sites enter the evaluation.

Summary

1. One memo for field flow, owners, settlement desks. 2. Pick the closest category and note limits. 3. Request quotes from 2–3 same-type vendors with the checklist. 4. Compare quotes on seller, settlement, bundled products. 5. Record selection rationale and schedule contract / pilot meetings.

Related service

SmartPlate Ticket | Program-dedicated ticket platform

For cases where requirements have become concrete: unified display of multiple ticket types, custom settlement, and integrated public site design.

SmartPlate Ticket service site and materials request