Capitan Release Notes - October 12, 2026

What's in this release

Recurring memberships gain three new controls in this release: members can pay ahead on a membership they already hold, each upfront payment option can be limited to a date range, and a membership can restrict when a customer's cancellation takes effect. Alongside them, benefit memberships can now outlast the event and be granted from repeating schedules, staff can bypass an age restriction when inviting a participant, and there are a number of fixes.

Memberships

• Climber App: pay upfront on an active recurring membership
• Upfront payment options: set the dates an option is available
• Cancellation policies: limit when a customer's cancellation can take effect

Events and bookings

• Benefit memberships: extra days after the event, repeating schedules, and a per-customer limit
• Invitations and waitlists: bypass the age restriction when inviting a participant

Plus a number of fixes, at the end of this article.

Memberships

Climber App: pay upfront on an active recurring membership

Previously, a customer on an active recurring membership had no way to switch to paying ahead on that same plan. The upfront payment options were offered only at purchase, so moving to a prepaid period meant cancelling and buying the membership again.

A customer with an active recurring membership now sees Pay Upfront on that membership's page in the Climber App, when the plan has upfront payment options and your organization allows Climber App membership management. The page lists each option with its total and the next bill date it would produce, and the customer selects Pay Now to pay with the membership's saved payment method. The purchased periods are added after the date the membership is already paid through, so the next bill date moves out by that many periods, no recurring bill is charged before then, and regular billing resumes at the standard price when the period ends. The customer is charged immediately and receives a confirmation email, and the purchase is recorded in the activity log.

Staff can start the same purchase from the customer's profile: the recurring membership's Edit menu gains Purchase Upfront Payment Option, which opens the Climber App as the customer. It needs the Manage Members permission.

The price is what that many regular bills would cost, less the option's discount. Each period is priced as the membership's current bill, including members, add-ons and discounts; a discount set not to be used with upfront payment options is left out and applies again when regular billing resumes. When the saved payment method is a bank account, the plan's bank-transfer discount applies to every purchased period, provided that discount can be used with upfront payment options. If the plan grants event vouchers, one set is granted per purchased period, expiring on the new next bill date.

The purchase is unavailable, with the reason shown on the page, when the membership is not Active (frozen, payment failed, pending staff approval or not yet started), when a cancellation or freeze is scheduled, when a member, add-on or freeze change is waiting for the next bill date, when the next bill date is more than one billing period away (upfront payments cannot be stacked), or when the membership has no saved payment method. Options limited to customers who have not held a membership recently are not offered. If the price or payment method changes between the page loading and Pay Now, nothing is charged and the page asks the customer to review the updated details.

A bank transfer moves the bill date as soon as it starts processing. If the transfer fails, the bill date moves back and regular billing resumes.

The Memberships report gains two column options, Upfront Purchases While Active and Last Upfront Purchase Date, and a Purchased Upfront While Active filter. The existing Paid Upfront columns and filter keep their meaning of paid upfront at the initial purchase.

Upfront payment options: set the dates an option is available

Previously, an upfront payment option was purchasable year-round. A seasonal offer, such as a discounted prepaid period sold only in the run-up to a session, had to be added and removed by hand.

Each upfront payment option on a recurring membership can now carry a Start Date and an End Date, set in Add Upfront Payment Option or with the new Edit button beside Remove in the Upfront Payment Options table. Either date can be left blank: with no start date the option is available up to its end date, with no end date it is available from its start date on, and with neither it is always available. The table shows each option's dates beneath its time period. The dates are one-time calendar dates, both inclusive, and an option is available when today's date in your organization's time zone falls within them; the membership's start date plays no part. The same fields appear on the Membership tab of a rolling event type in Event Setup.

In the Climber App, the Upfront Payment Options step of a new membership purchase lists only the options available today, and is skipped when none are. On an active membership, Pay Upfront and the staff Purchase Upfront Payment Option action offer only the options available today, and are hidden when there are none.

A customer who chose an option while it was available keeps that price for the checkout, even if the end date passes before they pay. Options with no dates behave as before, and periods already paid upfront are not affected by a change to an option's dates.

Cancellation policies: limit when a customer's cancellation can take effect

Previously, a customer cancelling in the Climber App could choose any future bill date that cleared the membership's wait period and notice period. There was no way to say that a cancellation may only take effect in a particular window, as with a monthly-billed annual membership that can only end in December.

A recurring membership's Cancellation Policies now include "Date range in which a customer's cancellation may take effect (optional)", with a Start Date and an End Date, shown when customers are allowed to cancel. Both dates are set together, and the end date cannot be before the start date. The range is a one-time fixed range, not a window that repeats each year.

In the Climber App, a customer cancelling a membership with a range can only choose bill dates that fall within it, start and end dates included, and the wait period and notice period still apply on top. The cancel page tells them the range. Once no bill date qualifies, for example because the end date has passed, the customer cannot cancel in the Climber App until staff change or remove the range, and the page gives the range as the reason.

Cancellations made by staff are not restricted. In the customer's membership Edit menu, Cancel (Future Billing Date) shows a warning when the chosen date is outside the range, and Cancel (Immediately) shows one when today is, but both still go through. The bulk Set Membership End Dates action is unchanged. A cancellation that is already scheduled is not changed when a range is added or edited, and it can still be undone.

Example: a membership that bills monthly but is sold as an annual commitment gets a range of December 1 to December 31 and a 30-day notice period. A member who asks in October is offered December's bill date; one who asks after it has passed sees the range on the cancel page and cannot cancel in the Climber App. The range does not roll forward on its own: once December is over, staff set next year's dates on the membership.

Events and bookings

Benefit memberships: extra days after the event, repeating schedules, and a per-customer limit

Previously, a benefit membership granted by an event lasted only for the event's own dates, and it could only be set on one-off events. An introductory session that should come with two weeks of climbing afterward, running every week, could not be set up.

Benefit Additional Days After Event now sits next to Benefit Membership (optional) on a one-off event's occurrences, and both fields are now offered on each schedule and each schedule exception of a repeating event type, reached from Event Setup. Each participant booked onto a session receives the membership from the start of the session's day through the end of the last additional day: with 13 additional days, a session on Monday October 5 grants a membership through the end of Sunday October 18. As before, the membership is granted once the booking or its deposit is paid, stays in place if the participant does not attend, and ends if the booking or the participant's reservation is cancelled. Rolling event types do not offer it.

Saving a schedule grants the membership to participants already booked onto its upcoming sessions. Sessions that have already started are not changed, and nobody who attended an earlier session receives it after the fact. Changing a schedule's benefit membership or additional days updates the memberships its upcoming sessions granted, and removing the benefit membership ends them.

A membership with purchase type Benefit gains Maximum Grants per Customer (optional), the most times one customer can receive it across every event, schedule and schedule exception that grants it. Blank, the default, means no limit. A participant who has reached the limit books and attends as usual but does not receive the membership again, and their activity log records that the limit was reached. A grant counts while the participant still holds a paid, uncancelled reservation on the session that granted it, past or upcoming; a grant that ended because the booking was cancelled, or because the benefit was removed from the session, does not. The limit never ends a membership that has already been granted, and lowering it leaves existing grants in place.

Invitations and waitlists: bypass the age restriction when inviting a participant

Previously, an event type's age restriction was never checked when staff invited a participant or added them to a waitlist, but it was enforced with no way around it when the family accepted. The invitation went out looking fine and ended on the parent with "The following participant is too young for this event", which came up whenever staff moved a child into the class one year outside their age band.

Invite Customer to Event, Invite Participants to Another Event, Invite Waitlist Entry To Book and Add To Waitlist now check each selected participant against the target event type's age band. When one is outside it, a warning under the participant list names them and the limit, for example "Jordan Lee is 7. This event type requires participants to be at least 8 at the event's start.", followed by the checkbox "Bypass the age restriction for the participants listed above. This will be recorded in the activity log." Send stays disabled until it is ticked. The age is taken as of the event's first start date, or today for an event type waitlist, and a participant with no birthday on file is neither warned about nor blocked. Each bypass is recorded on the participant's activity log, naming the staff user, the restriction and the event. Accepting a waitlist invitation in the Climber App no longer fails on age, however the entry got there, and an automatic invitation from a waitlist is never refused on age.

Pending invitations that families could not accept became acceptable on release, without being re-sent. Rolling event types are unchanged.

Fixes

• An abandoned booking's activity log read "canceled with a full refund" when nothing had been charged. The refund wording now appears only when a captured payment was refunded, and existing entries were rewritten.
• A waitlist invitation paid slowly could leave the family charged, refunded, and off the roster. When the payment completed after the hold had released the booking, the booking was only revived if the event had room, which an invitation to a full event never does. It is now revived regardless of capacity.
• Adding an add-on from the Membership tab of a rolling event type left it unavailable at every location. The add-on got no price in any location-specific pricing matrix and nothing on the page said so. That page's Pricing section is now the same one as the Membership page's: a new add-on gets its default fee in every matrix, and the Pricing Summary column lists each add-on's price or Not available.
• The Climber App showed an error at the participant agreement step when the event type no longer had one, for example after the agreement was removed from the event type. The step is now skipped.
• Visits from ads to the Climber App were recorded as Direct in Google Analytics. Several redirects, including an organization's front door, a single-location organization's schedule page and the sign-in redirect, dropped the UTM, click-ID and cross-domain parameters the visitor arrived with. They now carry them through; sessions already recorded as Direct cannot be re-attributed.
• The Documents report took over a minute to filter by expiration date or document type at organizations with a long history. Those filters now return in seconds, and the report's emailed and exported versions benefit too. Documents signed at the same moment may now appear in a different order relative to each other.
• API integrations paging through long lists, such as payments, reservations and entry passes, waited several seconds per page. Pages are now sorted before the rows are loaded, and the row count on the middle pages of a crawl is reused for up to 60 seconds rather than recomputed. Responses are otherwise unchanged, except that rows sharing a timestamp may swap order and the count on a middle page may be up to a minute old.