Travel and experiences,
all on one wishlist.

Things you can’t put in a cart.

Wishlists were invented for products. Experiences have always been the awkward exception.

Amazon’s wishlist works because every Amazon item is a SKU and every SKU has a quantity, a price, an in-cart action, and a checkout. The shape of the data and the shape of the action are aligned. Pinterest is wishlist-shaped without the action; Etsy is action-shaped without the wishlist. The model has been refined over twenty-five years.

None of it works for experiences. The thing your partner wants is not a hotel. It’s the King Garden Suite at the Andaz Maui, July 12 through July 19, ocean view, late checkout. The thing your dad wants for his sixtieth is not concert tickets. It’s the Brandi Carlile show at the Hollywood Bowl on June 14, two seats, section L. The thing the bride wants in her honeymoon registry is not a flight. It’s Delta SEA to LIS, August 4 through 14, main cabin, one passenger. Each of those is a structured booking object with a date window, a configuration, a guest count, a seat or room class, and — critically — a real-money price that only resolves at the moment of booking, not at the moment of wishing.

Honeyfund, Hitchd, and GoFundMe collect cash for trips. They don’t capture the trip. They can’t. They’re fundraising surfaces; the booking happens elsewhere, off the platform, and the couple has to translate dollars to a hotel reservation by hand. Gish is the first wishlist platform built end-to-end for experiences as a first-class object: capture the booking parameters, accept contributions against the budget, and settle the actual booking on a Stripe Issuing per-booking virtual card with the parameters intact.

Five booking surfaces, parameter-capture native.

Each adapter understands the booking shape of its surface and stores the right fields. No free-text guessing.

The five live adapters cover the largest surfaces in vacation rental, hotel, air, and live events. Each parses the structured booking object from its native surface (deep-link, share-link, mobile share-sheet) and stores the parameter set on the wish. When a contribution closes the budget, Gish has everything needed to issue the actual booking — not a vague amount, but the named room at the named property for the named dates. Additional adapters — Hipcamp, GetYourGuide, Booking.com, JetBlue, Resy — are in the queue; the framework is the same.

What this actually unlocks.

Four shapes of experience wishlist that didn’t exist before.

Real money moves, real bookings happen.

Per-booking Stripe Issuing virtual cards, MCC allow-lists, and a closed-loop confirmation trail.

The hardest part of experience-wishlists is the last mile: turning a fully-funded wish into a confirmed booking. Cash-collection platforms punt — they pay out the dollars and the recipient has to book by hand. Gish doesn’t. When a booking-wish closes its budget, the system spins up a virtual card via Stripe Issuing, scoped to the merchant category code of the destination (lodging MCC for hotels, airline MCC for flights, ticketing MCC for events) and capped at the funded amount plus the buffer the couple authorized. The booking transacts through that card. If the merchant tries to settle for more than the funded amount, the card declines and a notification fires. If the merchant tries to charge a different category, the MCC allow-list declines the transaction.

The card lives for the booking window. After confirmation it’s frozen; after settlement it’s closed. The confirmation email from the merchant routes back to the wish, attaches as a fulfillment artifact, and the wish moves to fulfilled state. Every party in the contribution chain gets a clean receipt that ties their contribution to the actual booking they helped fund. The closed loop is what makes the model defensible.

Self-booking is supported too. If the couple wants to book the room themselves, the card can be issued to them at the funded amount and the wish settles when they upload the confirmation. We don’t insist on automation when the user wants control. The system is a broker, not a forced workflow.

Confirmed bookings ship as Apple Wallet and Google Wallet passes alongside the email confirmation. The recipient adds the pass once and the venue, gate, hotel, or restaurant scans it on arrival — no PDF-hunting, no screenshotting a confirmation number at the door.

Passenger details, encrypted on device.

Secure Enclave on iOS, Tink AEAD on Android. Biometric key release at booking time. 90-day auto-delete.

Booking a flight, a hotel, or a concert needs sensitive data the user reasonably does not want sitting on a server somewhere: passport numbers for international flights, government ID for hotels in certain jurisdictions, the full legal name and date of birth required by airline manifests, sometimes a frequent-flyer number. The classic SaaS approach is to collect all of it server-side, encrypted at rest with a vendor-managed key, and hope the breach never comes.

Gish does it differently. Sensitive booking data lives in the on-device vault — Apple’s Secure Enclave on iOS, Tink’s AEAD primitives on Android — encrypted with a key released only on biometric authentication at the moment of booking. The data is sent directly from the device to the merchant’s booking API, end-to-end, with the Gish backend acting as a relay that never sees the cleartext. We don’t have it; we can’t lose it.

After ninety days the encrypted blob auto-deletes from the device vault unless the user explicitly extends it. The default posture is that sensitive data has a TTL, not a permanent residency. Users can re-enter on the next booking; biometric is cheap and the security gain is real.

• iOS: Secure Enclave, hardware-backed key, Face ID / Touch ID at release.
• Android: Tink AEAD with Android Keystore, biometric prompt at release.
• Server-side: relay only. Cleartext never lands on Gish infrastructure.
• Auto-delete: 90-day default TTL on the on-device blob, extendable.
• Two-person rule: bookings over $1,000 require a second authorized signer’s biometric confirmation before the issuing card settles.

Bookings over $1,000 take two signatures.

A real-money safeguard built directly into the booking flow.

A $1,000 booking is the threshold above which we believe the asymmetry of harm justifies a quorum. A keystroke mistake, a stolen device, a hostile actor with a moment of access — below the threshold the recovery is annoying; above it the recovery may be impossible. The two-person rule asks for biometric confirmation from a second authorized signer on the wish (the second member of a couple’s honeymoon, a co-organizer of a group-buy, a treasury second) before Stripe Issuing releases the card to the merchant.

The second signer can be set up in advance — partners are the most common case — or solicited just-in-time, with a push notification that surfaces the booking summary and asks for a yes/no. The push is signed and time-bounded; old notifications can’t be replayed. If the second signer rejects, the booking aborts cleanly and the funded amount stays in escrow with no transaction. If both signers approve, the card releases and the booking goes through.

Solo bookings under the threshold don’t require the second signature; we calibrate friction to risk. The threshold itself is user-tunable per wishlist and defaults to $1,000.

Honeymoons and anniversary trips, natively splittable.

Every experience wish is a group-buy candidate by default. The math is the same as any other Gish wish, with parameter-aware booking on the back end.

A $4,800 honeymoon Maui stay can be split across forty wedding guests at $120 a head, twelve guests at $400, or any mix in between. The group-buy ledger surfaces who’s contributed what; the wishers can leave the ledger public or private. When the budget closes, the booking issues and every contributor gets a confirmation receipt that says exactly what they helped book — not just a dollar amount.

The same shape works for the friend-group anniversary getaway, the office leaving-gift trip, the kids chipping in on a parental cruise, the milestone-birthday concert outing. Every shape is fundable by group; every shape settles into a real booking with the parameters preserved.

Side by side with the cash-collection incumbents.

Honeyfund, Hitchd, GoFundMe. They’ve been around for years; they don’t do this.

The cash-collection platforms aren’t wrong; they solved the easier half of the problem fifteen years ago and built durable businesses around it. Gish takes on the harder half: turning the funded amount into the booked itinerary, with the parameters preserved and the money settled through a real merchant rail rather than a manual translation step. That’s the missing primitive.

Honest limits, today.

The roadmap is real; the surface is finite.

The five live adapters are the largest surfaces in their categories but they’re not all of them. Hipcamp, Booking.com, GetYourGuide, Resy, OpenTable, Eventbrite, and a long tail of smaller booking sites are not adapter-native yet; for those, you can still capture a wish with a URL and a target amount, and the broker will issue a card at the booking moment scoped to the right MCC, but parameter capture will be best-effort from the URL rather than structured. The framework is generalizable; the queue is just finite.

International is partial. Most adapters work cleanly for US-issuing cards; cross-border bookings work when the merchant accepts US cards (which is almost always), but parameter-locales for non-US date formats, currency, and address fields are roadmap. International passport-required flights work through the on-device vault but require the user to have entered passport data on their device first.

Why we built it this carefully.

Money moves through this product. The trust posture has to be calibrated to that.

Most consumer wishlists handle no real money. They’re intent-capture surfaces; the purchase happens elsewhere, on a real retailer’s checkout, with a real card the user already trusts. Gish’s experience product breaks that pattern because the booking necessarily happens through a card we issue, scoped to a merchant we don’t directly control, against a budget that often pools contributions from many people. The asymmetry of harm if something goes wrong is large: a stolen card is replaceable, but a stolen honeymoon — both the money and the trust between contributors and recipients — is not.

Every choice in this section is downstream of that asymmetry. The MCC allow-list exists so a compromised card cannot be used for groceries or electronics. The per-booking card lifecycle (issue, settle, freeze, close) exists so a card has minimum surface area and minimum lifetime. The two-person rule above $1,000 exists because the harm above that threshold is large enough to justify the friction. The on-device vault exists so the worst-case backend breach cannot reveal passport numbers. The 90-day TTL exists so even on a successful login a stale credential isn’t sitting around for a future attacker. None of this is paranoia; it’s calibration to the actual risk surface of a product that moves real money for real bookings on behalf of multiple contributors.

We publish the threat model in the security documentation, and we update it when the product surface changes. If a control changes — the two-person threshold moves, a new MCC is added to the allow-list, the TTL is adjusted — we publish the rationale. The product is designed to be inspectable by the people whose money flows through it, because that’s the only durable basis for trust at this scale.

For couples and groups whose pooled gifting predictably exceeds the booking-month windows, Treasuries are the right adjacent shape: standing pools with quorum-vote deploys onto any wish, including experience wishes. For organizations running employee-trip programs or alumni-getaway funds, the same primitive scales up. Both pair naturally with the experience adapter set.