Here and Now Travel — Stabilising a Live Booking Platform

The Brief

Payments were failing. That was the fire.

Travellers were trying to give Here and Now money — for four-figure deposits and full trip balances — and the platform wasn’t reliably letting them. Charges silently failed. Cards that should have worked didn’t. Bookings ended up in ambiguous states where neither the customer nor the company could tell whether the payment had actually gone through. For a curated travel business, where the moment a traveller decides to commit is the moment that has to convert cleanly, this was the most painful problem the business could have. Painful for the staff trying to recover the booking after the fact, and painful for the customer trying to give the business their money in the first place.

Here and Now Travel was already live, already taking real bookings, and already running a curated group travel business on a fully bespoke application — the public site, the guided checkout, the post-booking traveller portal, and the admin suite the team uses to actually operate. Bubble was the runtime; the platform sitting on top of it was custom, end to end.

KnowCode wasn’t asked to build something new on a blank page. The job was to step into a running business, fix the payments fire first, and then bring the rest of the platform up alongside it — more reliable, more capable, lighter on technical debt, more visually consistent, and more findable in search — without taking the site down or interrupting the booking flow that pays the bills.

What follows is how the engagement broke down, across five linked tracks.

Stability First

The first job was making the platform predictable — and that started with payments.

A failed charge that the system thinks succeeded, or a successful charge the system thinks failed, is the worst possible state for a booking platform. Both leave staff guessing and customers anxious. The fix was structural: treat the moments where things go wrong as designed states, not as exceptions to be caught after the fact.

When Square is unavailable, the traveller now sees a clear, branded outage message — in both the checkout flow and the in-app portal, served by the same component in both places — instead of a half-completed cart and a confusing error. When something fails server-side, staff can see what happened and recover the booking without guessing.

Behind the scenes, every charge, refund, and failure now writes to a structured payment log, with a separate debug log providing a full audit trail. Manual success overrides were added to the admin so staff can record a payment confirmed outside the normal flow — a wire transfer, a phone-arranged charge, a Square charge the platform couldn’t quite confirm in time — without having to fight the system. Cancellations, which are not one thing but four (standard, 24-hour, no-credit, and non-primary traveller removal), were each given a proper, documented workflow so the admin’s most stressful actions stop being where mistakes get made.

The goal was never to make failures impossible. It was to make them legible, recoverable, and never silent — so a payment problem becomes a five-minute admin task rather than a frantic email thread.

Payments: Square and ACH

Once the platform could survive a bad payment moment, the payment moment itself had to be rebuilt.

The previous integration was the source of the original fire — failing charges, ambiguous states, no clear audit trail. The principle for the rebuild was simple: card data is radioactive, none of it should ever touch Here and Now’s servers, and every transaction the platform initiates should be traceable end-to-end.

The entire Square integration was built by KnowCode, ground-up, and is now a published Bubble plugin — not a third-party connector we configured, but a piece of infrastructure we own end to end. That matters because the failure modes that started the engagement weren’t going to be fixed by tweaking someone else’s wrapper. Owning the plugin meant owning the surface where things go wrong, the data model the platform reads from, and the upgrade path when Square’s own APIs evolve.

Card capture runs inside the app’s own UI using the Square Web Payments SDK. The traveller types their card details into what looks like a native Here and Now form, but the field is hosted by Square; Square tokenises the card on its own infrastructure and the app only ever sees a nonce. That nonce, the amount, and the booking reference are sent server-side to Square’s Payments API via our plugin, and the result is written against the booking. Refunds run the same way, triggered from the admin, with the original payment reference passed straight through to Square’s Refunds API.

The checkout supports the realities of group travel rather than fighting them. A traveller can pay the minimum deposit, the full balance, or a custom amount. Invoices, discount codes, and Square payment references are stitched together in a single record that links cleanly back to the booking — what the customer paid, what they were charged, and what the discount actually was are all recoverable from one place. Discount codes are validated against trip scope, expiration, and prior redemption before they’re applied, so a code restricted to one departure cannot accidentally drift onto another.

Alongside Square card processing, we added ACH as a parallel payment path. Not every traveller wants to put a four-figure deposit on a credit card, and for the business, ACH is materially cheaper to process. We built it as a separate data model — ACH Link and ACH Payment records sitting alongside the Square ones — so the two flows stay clean and either can evolve without breaking the other.

The result is a payments stack that looks like Here and Now’s own, behaves like Here and Now’s own, and offloads card security and processing infrastructure entirely to Square underneath.

Paying Down Technical Debt

Live products accumulate debt. Workarounds become permanent. Data models grow by accretion. Logic that should live in one place ends up duplicated across three. This is not a failure of the original build — it is the cost of being used.

A meaningful portion of the engagement was spent quietly cleaning this up. Duplicated logic in the checkout and cancellation flows was consolidated. The data model around payments, invoices, and bookings was tightened so the relationships were unambiguous — Bubble-normalised amounts and Square-formatted amounts (in cents) now coexist in the same record without contradicting each other. The patterns that had been copy-pasted across pages — payment capture, outage banners, traveller profile forms — were rebuilt as proper reusable elements, defined once and consumed everywhere.

None of this work shows up on the marketing site. None of it is something a customer would ever notice on a single visit. But the cumulative effect is a platform that is materially easier to change. A pricing-display tweak that previously had to be made in four places now happens in one. A fix to payment capture, once made, propagates everywhere the component is used. The next thing the business needs is built on a cleaner base than the last thing.

This is the part of the engagement that earns its keep on month six, not month one.

Design as Engineering

Most engineering teams treat designers as decorators applying paint at the end of a build. On this engagement we treated them as collaborators with veto power over the surface of the product.

Bespoke platforms drift visually over time. Pages get added to solve immediate needs. Reusable elements diverge from each other. The price bar on the checkout slowly stops looking like the price bar on the trip detail page; the room occupancy selector behaves differently from the cart’s solo-room upgrade; the profile form ends up with three different button styles depending on whose week it was when it shipped. Individually invisible — collectively, the reason a booking flow stops feeling trustworthy.

Working directly with Here and Now’s design team, we ran consistency passes across the destination pages, the trip calendar, the multi-step checkout, the in-app traveller portal, and the admin — typography, spacing, photo presentation, button behaviour, and the small load-bearing details (price bars, room occupancy controls, e-signature waiver capture, status badges) that make a four-figure online purchase feel safe to complete.

The engineering work and the design work fed each other directly. Consolidating duplicated logic into reusable elements meant a design change could be applied once and land everywhere it was used. A tightened visual language, in return, gave us a clearer specification for what those reusable elements should look and behave like. Stability, code health, and design polish are usually treated as separate tracks; on this engagement, they were the same one.

Discoverability and Attribution

A travel platform nobody finds in search is a brochure.

Discovery is the front door of the business: a prospective traveller lands on a destination page from a Google query, gets convinced by what they read, and starts a booking. We brought the platform up to a modern search baseline — clean URL structures across destinations, trips, and blog content; a redirect manager in the admin so URL changes don’t quietly destroy hard-won ranking; structured metadata, canonical URLs, and Open Graph tags on every page so search results and social shares render correctly; and an integrated blog engine with multi-section posts and an author model, so content compounds over time rather than expires.

Attribution is the related but separate problem of knowing which marketing spend produced which booking. Purchase events at checkout now fire to Klaviyo for email audiences, to Facebook CAPI for ad attribution (with separate live and test endpoints so QA traffic doesn’t pollute the production audience), and to Stape as a server-side tag management layer. That gives Here and Now a full-funnel view of campaigns to bookings without depending on browser-side pixels that increasingly don’t fire.

Findability brings travellers in. Attribution tells the business which channels are working. The platform now does both.

Where It Sits Now

What changed during the engagement is not a single feature. It is the platform as a whole.

The booking flow that pays the bills runs cleanly. The admin the team lives in is easier to use and easier to recover from when something goes wrong. Payments can move on card or on ACH, and the company can see every transaction, refund, and override in one place. The codebase underneath has been rebuilt around proper reusable elements, so the next thing the business needs can be shipped quickly rather than fought through. The platform is consistent enough end to end that travellers trust it. Search engines can index the content the marketing team produces, and the marketing team can see which campaigns drive bookings.

That is the deliverable. Not a feature list — a platform Here and Now can still be running, and still be evolving, five years from now without a rebuild.