Payment & Access

Top-level flag indicating whether any form of payment is required to access this destination. When false, all other payment fields may be omitted. When true, at least payment_type and payment_amount must be present.

Classification of what the payment is for. Determines which downstream rendering templates and access-control integrations apply. A single destination may require multiple payment types — in that case, repeat the payments object per type.

Identifier of the payment processor or system operator handling the transaction. Used by kiosk and app integrations to route to the correct payment SDK. May reference an internal provider ID or a well-known payment platform slug.

Max: 64 chars — Convention: lowercase-hyphenated slug

UUID of the physical location where payment must or can be completed. References a WIM place record — typically a pay station, ticket machine, or reception desk. Used to route users to the correct payment point before granting access.

Specific terminal or device identifier at the payment location. Provided when a site has multiple terminals at the same location and the system needs to direct users to a particular one — for example, an accessible-height terminal.

Max: 64 chars — Source: payment provider terminal registry

Array of accepted payment methods at this location. Used by apps and kiosks to pre-select the correct payment flow and to warn users if their preferred method is not accepted before they walk to the terminal.

Three-letter ISO 4217 currency code for the payment amount. Required whenever payment_required is true. Consumers use this to format amounts correctly for the visitor's locale and to apply the correct exchange rate for multi-currency displays.

Format: ISO 4217 alpha-3 — Examples: EUR, GBP, USD, SEK

Base payment amount in the specified currency, expressed as a decimal. For time-based tariffs (parking, hourly access), this represents the rate per unit period defined by the associated tariff. Set to 0 for explicitly free-entry destinations where a payments object is still needed for audit purposes.

Min: 0 — Precision: 2 decimal places — No currency symbol

Current operational status of the payment system at this location. Downstream channels display warnings when the status is not operational — for example, redirecting users to an alternative pay point or warning before they reach a broken terminal.

Whether a valid ticket must be presented or validated to access this destination. Distinct from payment — a ticket may already be paid for (e.g. a pre-purchased event ticket or an included-in-admission pass). When true, ticket_type should be populated.

Classification of the ticket required for access. Determines which validation logic and scanner integrations apply at physical access points. Used by mobile apps to surface the correct ticket format in the visitor's wallet.

Reference identifier of the specific ticket or booking linked to this access record. When present, access-control systems compare this value against the visitor's presented ticket before granting entry. Sourced from the booking or ticketing system of record.

Max: 128 chars — Format: opaque string, system-defined

UTC timestamp from which the ticket is valid. Access-control systems reject entry attempts before this time. Used to prevent early arrival at restricted areas and to queue users with time-slot based access.

Format: ISO 8601 — Timezone: always UTC (Z)

UTC timestamp after which the ticket expires and access is revoked. Downstream systems must not allow entry past this timestamp. For open-ended tickets (e.g. annual memberships), this field is omitted or set to null.

Format: ISO 8601 — Timezone: always UTC (Z)

Whether separate parking payment is required in addition to the destination's primary access payment. Set to true for destinations where the visitor is likely arriving by car and the parking facility operates an independent payment gate. Used by navigation apps to prompt payment before exit barriers close.

Reference to the applicable parking tariff in the parking operator's system. Consumers use this to look up rate schedules, maximum stay periods, and exemption rules. Required when parking_payment_required is true and the operator exposes a tariff API.

Max: 64 chars — Source: parking operator tariff registry

Identifier of the parking zone or deck associated with this destination. Used to guide visitors to the correct parking area and to apply zone-specific tariff rules. Displayed in pre-journey briefings and on parking guidance signage integrations.

Max: 32 chars — Convention: operator-assigned zone code

Whether a public transport ticket is available for purchase or collection at this location. When true, journey planning apps can surface this destination as a transit ticket point in multi-modal routing — for example, a hospital reception desk that also sells combined bus-and-admission tickets.

Whether a refund can be requested for unused access or time. When true, payment confirmation screens and receipts should surface the refund process. Used by kiosk and app UX to set correct visitor expectations at point of payment.

Invoice or purchase-order reference number for pre-arranged or corporate billing relationships. When present, the payment flow bypasses point-of-sale terminals and instead records the charge against the referenced invoice. Common for insurer-funded clinic visits and corporate event access.

Max: 128 chars — Format: billing system reference, opaque string

Applicable VAT or sales tax rate as a decimal percentage. Used by billing integrations and receipt generation systems to calculate the tax component of the displayed payment_amount. Omit for jurisdictions or payment types where VAT does not apply.

Range: 0.0 – 100.0 — Example: 21.0 for 21% Dutch VAT

Whether physical access is automatically granted immediately upon successful payment completion. When true, access-control systems listen for the payment confirmation event and release barriers or unlock doors without additional staff intervention. When false, payment is a prerequisite but access is granted through a separate process (e.g. staff check-in).

Deep-link URI that opens the payment provider's app or web flow directly, pre-populated with this location's payment context. Surfaced by mobile wayfinding apps as a "Pay now" action so visitors can complete payment from their phone before reaching the physical barrier. Must be a stable, dereferenceable URI — not a one-time session token.

Format: RFC 3986 URI — Schemes: https://, app-specific (e.g. qpark://)