1. Purpose
This guide explains how a bundle ticket (for example a Family ticket made up of two Adult and two Child tickets) is configured in Expian Admin, how the platform treats a bundle during booking, and how to test it end to end. It follows the issue raised on the HRP test environment in which a bundle ticket was either not displayed in the B2C booking flow or failed at checkout with a capacity allocation error. That issue has been resolved and the test script in Section 6 is designed to give HRP confidence that the fix behaves correctly against HRP's own configuration before it is relied upon in production.
2. Background to the issue
Two separate behaviours were observed during testing and are worth distinguishing, because they have different causes.
| Symptom | Cause | Resolution |
|---|---|---|
| Bundle ticket type was not visible in the B2C "Who" (ticket selection) step even though it existed in Admin. | Configuration. A bundle only appears in a booking flow once it has been added to the product, given a price, and made available on that sales channel. In the original test the ticket type and product set-up had not been completed on that environment. | Follow the configuration steps in Section 5. No software change was needed for this symptom. |
| Bundle could be added to the basket, but clicking "Continue to checkout" returned an INVALID_CAPACITY_ALLOCATION / CAPACITY_ALLOCATION_FAILURE error (the on-screen text may show a slightly different spelling). | Software defect. On versions before 3.3.0 the platform did not correctly break a bundle down into its component tickets when checking and allocating capacity. Where a service had a finite capacity, the bundle could not be allocated and checkout failed. Products with unlimited capacity were unaffected, which is why the problem did not surface earlier. | Fixed in Expian v3.3.0 (change reference EXPIAN-308). Capacity is now checked and consumed for each ticket within the bundle, so a Family bundle of 2 Adults and 2 Children consumes four units of capacity, not one. |
3. Prerequisites
Version check comes first. The capacity fix is only present on v3.3.0 or later. Testing bundle tickets with finite capacity on an environment running an earlier version will reproduce the original error and will not tell you anything useful about the fix. Please ask Expian to confirm the version running on the environment before starting.Before running the test script, please make sure the following are in place:
| Requirement | Detail |
|---|---|
| Environment | A non-production HRP environment running v3.3.0 or later. At the time of writing, HRP UAT (hrp-uat) is on a 3.2.x release candidate and HRP QA (hrp-qa) is on a 3.3.x release candidate, so hrp-qa is currently the environment on which this script can be run. Expian will confirm when UAT has been upgraded. |
| Admin access | An Admin user with permission to create and edit Ticket Types, Products, Pricing and Capacity settings. |
| Reservations access | A Reservations (RES) user able to view, amend and cancel orders, for the amendment and cancellation tests. |
| B2C access | The B2C booking portal URL for the test environment and a test card that is accepted by the payment provider on that environment. |
| A test product | A dated, timed-entry product (for example a test admission at Tower of London) on which you can set a small, finite capacity for one or more test timeslots. This is essential: capacity behaviour cannot be verified on an unlimited product. |
| Test naming | Prefix all test ticket types and products clearly, for example "TEST Family Bundle", so they can be identified and removed afterwards and are never exposed to real customers. |
4. How bundle tickets work
A bundle is a ticket type that acts as a parent to one or more existing "unit" ticket types, each with a quantity. The customer sees and pays for one item (the bundle); the platform issues the individual tickets inside it. The rules below determine how a bundle behaves and are the basis for the test script.
| Area | Behaviour |
|---|---|
| Price | The price is set on the bundle. The tickets inside the bundle are recorded at £0.00 so the customer is only charged the bundle price and not double charged. In the basket and order summary the customer sees one line for the bundle with its price, and the component tickets listed underneath without a price. |
| Capacity | A bundle has no capacity of its own. Its availability is driven by the tickets inside it. A timeslot is only offered if there is enough remaining capacity for every ticket in the bundle, and when the bundle is booked each component ticket consumes its own capacity. Where component tickets draw on different capacity pools, availability is limited by whichever pool is most constrained. |
| Channels, limits and entitlements | Sales channel availability, limit-per-booking and entitlement (membership) rules are taken from the bundle, not from the tickets inside it. A Child ticket that is unavailable on B2C can still be sold inside a Family bundle that is available on B2C. |
| Customer details and add-ons | Where a product collects details per customer, the booking flow asks for one set of details per person in the bundle (four for a 2 Adult + 2 Child bundle). Where an add-on must be bought for every person, the required quantity is the total number of people in the bundle. |
| Ticket issue and wallets | Each person in the bundle receives an individual ticket, so tickets can be downloaded to separate digital wallets and scanned independently. |
| Cancellation and amendment | Cancellation is all or nothing. Selecting any ticket in a bundle for cancellation selects the whole bundle, one cancellation reason is captured for the group, and the refund is calculated on the bundle price. Removing or moving a bundle during an amendment releases or consumes the capacity of every ticket inside it. |
| Mandatory companions and restrictions | Bundles do not use the Mandatory Companions settings (the tab is hidden when a ticket type is set as a bundle) and bundles are excluded from the "Required" and "Not allowed" ticket type restriction lists on capacity options. Those rules are applied through the component tickets instead. |
| Ticket collection | Ticket collection is set in the bundle not the component tickets. All tickets in a bundle must either be ticketed or set to collect. |
5. Configuration steps
Screen labels below reflect the current Admin design. If your environment shows slightly different wording (for example "Bundled Tickets" versus "Grouping: Bundle"), the behaviour is the same.
Step 1: Confirm the component (unit) ticket types
- Go to Admin > Building Blocks > Ticket Types.
- Check that each ticket type you intend to include in the bundle (for example Adult, Child) already exists and is published.
- Open each one and confirm the Capacity tab has a capacity type assigned with the correct number of capacity units (normally 1 per person).
- Note the display order of these ticket types. This order controls how the component tickets are listed inside the bundle across B2C, Reservations and emails.
Step 2: Create the bundle ticket type
- In Ticket Types, select Create New.
- On the Description tab, enter the title the customer will see (for example "Family (2 Adults and 2 Children)"), a short title and description as required.
- Open the Capacity tab and set the ticket type to be a bundle (the "Bundled Tickets" option, shown in the list as Grouping = Bundle).
- In the bundled tickets section, add each component ticket type and set its quantity, for example Adult x 2, Child x 2. A ticket type can only be added once; the quantity controls how many are included.
- Check the capacity summary. It should show the total capacity the bundle will consume, for example "4 x Visitor", aggregated from the component tickets.
- Confirm the Mandatory Companions tab is no longer shown. This is expected.
- Complete any other tabs you would normally set for a ticket type (channels, limits, entitlements, analytics). Remember these are read from the bundle, not from the component tickets.
- Save. Saving is blocked if no component tickets have been added, which is also expected.
- Back on the ticket type list, confirm the new ticket type is flagged as a bundle in the "Is bundle" (or similar) column.
Step 3: Add the bundle to the product and set a price
- Go to the Product the bundle will be sold on (for example the test admission product) and add the new bundle ticket type to the product's ticket types.
- Set a price for the bundle for each site or market it is sold at (for example Tower of London). Until a price exists, the bundle will not be offered in the booking flow. This was the first symptom in the original issue.
- Confirm the bundle is available on the sales channels you intend to test (B2C, Reservations, POS as required).
- Publish the product changes.
Step 4: Set a finite capacity for testing
- Open the capacity settings for the test product or service and choose one or two test timeslots on a future date.
- Set a small, known capacity on those timeslots, for example 4 and 6 visitors. Record the values; the test script depends on them.
- If the product uses Ticket Type Restrictions on capacity options, confirm that the bundle does not appear in the "Required" or "Not allowed" lists. Only the component ticket types should be selectable there.
Step 5: Quick smoke check
- Open the B2C booking portal for the test environment, choose the test product, date and timeslot.
- Confirm the bundle appears in the ticket selection step with the price you set.
- Add one bundle to the basket and continue to checkout. If checkout is reached without a capacity error, configuration is complete and you can proceed to the full test script.
Was this article helpful?
That’s Great!
Thank you for your feedback
Sorry! We couldn't be helpful
Thank you for your feedback
Feedback sent
We appreciate your effort and will try to fix the article