Two ways to charge for the extra. Neither moves your banking.

A guest taps yes on the sunset cruise at 14:20 on a Wednesday. Forty euros, party of four.

Every article about upselling ends roughly here, with a conversion rate and a chart. The operator's actual next question is the one nobody writes about: where does the money go?

There are only two honest answers, and the useful thing about them is that neither requires you to move your banking.

Path one: post it to the bill

The guest already has a bill. They opened it when they checked in, it lives in your property system, and they settle it at the desk or on the way out like they always have.

So the simplest thing to do with a sold extra is to put it on that bill.

That is what add-to-bill does. The experience and its products go onto the guest's PMS bill as line items; the cruise, four at forty, with whatever they answered when they ordered. The guest pays at checkout, through the PMS, exactly as before. Nothing about their payment experience changes and nothing about your month-end changes.

The part worth saying slowly: HolidayHero collects nothing on this path. No money moves through us at any point. There is no merchant account to open, no new processor, no new entity in your banking, and no settlement to reconcile against ours, because there is no settlement. We write a line onto a bill your PMS already owns.

This is live on four property systems today: Mews in production, plus ClockPMS, eviivo and MyTourist. It is not live on Cloudbeds, StayNTouch or Oracle Simphony yet, but available on request. The current list is always on the integrations page.

What posting to the bill actually asks of you

Here is the paragraph the rest of this category leaves out.

Add-to-bill is not magic and it is not zero-setup. Your PMS does not know what a "Sunset cruise, adult" is. It knows about its own products and its own tax codes. So before the first charge can post, somebody maps the two together: each HolidayHero experience product to the corresponding product in your PMS, and each VAT rate to the matching tax code on their side.

On Mews that is a matching tab. On ClockPMS it is a charge template. Either way it is a sit-down of perhaps twenty minutes per property, done once, by whoever knows your rate structure.

We say this plainly because the alternative is you discovering it on a Tuesday. An unmapped product does not post. A mismatched tax code posts a line your finance team will query. And a folio that is already closed, the guest checked out an hour ago, will refuse the charge, correctly.

Anybody who tells you a charge lands on a folio with no configuration at all is describing a demo, not an installation.

Path two: take it in the app

Sometimes there is no bill to post to. The guest booked direct and prepaid. They are in a villa with a door code and no desk. The experience is run by somebody who wants paying this week. Or your PMS is one of the ones we have not built yet.

Then the guest pays by card in the guest app, on your own domain, without walking anywhere.

Mollie or Stripe processes that payment. We do not. We orchestrate — we present the right amount in the right currency at the right moment, and we record what was sold. The money goes from the guest to your processor to you. We are not a payments company, we are not a PSP, and we hold no funds. That is not a disclaimer at the bottom of this post. For most finance teams it is the single most important sentence in it.

Card today. Not Apple Pay, not Google Pay. They are not available, and we would rather say that than put them on a slide.

Why the rail matters if you are in Europe

For a long time taking a card payment in this category meant routing a European guest's money through an American processor, because that was the integration everyone had.

Mollie Connect shipped in August, alongside Stripe rather than instead of it. A European operator can settle on European rails, with a European processor, under the rules their accountant already works with. You choose which processor your workspace uses; you are not stuck with ours.

Two pieces of precision, since this is the part people repeat inaccurately. The choice is made per workspace, not per property. And payouts are Mollie's or Stripe's — we do not sit in the middle of them.

Guest data is held in the EU, under GDPR, across 23 countries.

Authorise on tap, capture on approval

A small thing that nobody writes about and every operator worries about.

Some experiences need you to say yes first. The boat has four seats left, the chef needs a day's notice, the massage therapist is not actually free at six. You do not want to take a guest's forty euros for something you then have to refuse.

So on those experiences, the tap authorises the payment and does not capture it. The money is held, not taken. When you approve the booking, it captures. If you decline, the authorisation is released and the guest was never charged.

That is one of those details that sounds like plumbing until the first time you would otherwise have had to apologise and refund.

You find out before the guest does

A guest reaching a payment screen that cannot process their currency is the worst possible place to discover a configuration gap.

So the admin tells you first. For every payment provider you could use, it shows whether it is supported in your workspace's currency, supported with limits, or not supported at all — and if nothing covers you, it says so prominently, in the settings, before a guest ever sees a button.

The two processors do not cover identical ground — their currency lists differ, and in a few currencies one of them is card-only. Rather than ask you to cross-reference two pricing pages, the admin resolves it against your workspace and tells you. If you operate somewhere the combination does not reach, you find out there rather than in a support ticket.

The front desk still has to know

A sale that only exists in our system is a sale your reception will be surprised by.

So when an in-house upsell is sold, we can write a note straight onto the reservation in your PMS: the experience, the products and quantities with the guest's own answers, the scheduled time, the total, any message they left, and the inquiry number. Your front desk sees it where they already work, without opening HolidayHero at all.

That is live for Cloudbeds today. It is off by default — you turn it on. And it covers in-house experiences only: anything run by a third-party supplier does not produce a note, because the arrangement with that supplier is yours and we are not going to pretend otherwise.

Which brings us to what this release does not do.

What this does not do

Four limits, said out loud, because you would find them in week two anyway.

There is no supplier routing. An order for an experience run by the kayak company down the road does not reach the kayak company by itself. You are still the one who tells them. We record what was sold and when it is scheduled; getting that to a third party is manual today.

There are no automatic commission splits. If you owe a local supplier their share, that arrangement and that payment are between you and them. Nothing in HolidayHero calculates a split or pays one out.

Reconciliation is not automatic. The charge posts to the bill; matching it is configuration you set up once and finance work you still do. We do not produce a reconciliation report, and anyone claiming charges reconcile themselves with no manual matching is overselling.

Refunds and reversals are not built on the add-to-bill path. A charge posted to a Mews or ClockPMS folio is reversed in the PMS, not here.

None of those four are secrets and none of them are coming next week. Tasks — who does the thing once it is sold — is a different piece of product and a different conversation.

The number, and the honest size of it

A luxury property manager in Spain running five villas put paid upsells in front of guests in the app and saw 25% of guests purchase an upsell, with guest inquiries dropping 75% because the information they needed was already in front of them.

That is one operator and five properties. It is a good signal and it is not a market average, so we are not going to print it as one. We do not have an aggregate revenue-lift figure for in-app payments, and when we do, it will arrive with a method attached.

What a finance team actually asks

Five questions, in the order they get asked, with the short answers.

Do you hold our money? On add-to-bill, no money passes through us at all. On in-app payments, the funds go guest → Mollie or Stripe → you. We are never a party to the transfer and we hold no balance.

What does it cost to process? The processor's rate is the processor's, and it is on their pricing page, not buried in ours. Our own commission on an in-app payment is separate and published. If you are on an add-to-bill rail, the external-payment rate applies rather than the card rate — worth checking your invoice, because that was wrong until recently and we fixed it in your favour.

Who is liable if a charge is disputed? The processor's chargeback process applies, as it would on any card payment you take. On add-to-bill there is no card transaction for us to be part of; it is a line on your folio and your PMS's rules govern it.

What happens if we leave? On add-to-bill, nothing — the charges are already on your bills, in your PMS, in your ledger. There is no balance of ours to unwind. On in-app payments, your Mollie or Stripe account is yours and stays yours; we disconnect from it.

Where is the data? In the EU, under GDPR.

That is the whole finance conversation, and the reason it is this short is the architecture rather than the sales pitch.

We are not a payments company

That sentence usually appears in small type at the bottom of a page like this. It belongs at the top.

Your PMS owns the reservation's ledger and should carry on owning it. A guest-experience layer that inserts itself into your banking has made itself expensive to remove and has taken on a risk it is not set up to carry. We would rather write a line onto a bill you already have, or hand a card payment to a processor you already trust, and be judged on whether the extra got sold and delivered.

Two ways to take the money. Post it to the bill, or take it in the app. Neither one moves your banking, and you can run both at once on different properties.

If you want the half before this — how a message reaches the guest who has not bought it yet, rather than everyone — that is last week's post on targeting by itinerary. The argument around both sits on effortless revenue.

HolidayHero runs on top of the property system you already have, across 3,500+ properties, in 100+ languages. Pricing is published, from €6.50 per unit per month with no setup fee.