The invoice page now takes the money — and can keep the card

Here is how paying a Gurita invoice used to end. The guest opens the link you mailed them, reads the charges, presses Pay — and lands on a payment provider's website in a new tab. The invoice is gone from the screen. Their bank asks for a confirmation. Something times out, or the tab gets closed, or they finish and never come back to the page that started it.

Nothing about that was broken. The money usually arrived. But the guest spent the most nervous thirty seconds of the transaction on a page that did not look like yours, and if it went wrong they had nothing left to look at.

The payment now happens on the invoice.

The payment happens where the invoice is

Press Pay and the right-hand column changes; nothing else does. The charges, the booking details and the payment schedule stay exactly where they were, on the left, for the whole transaction.

The guest payment page: charges and schedule on the left, the amount due and the payment panel on the right

It runs in three steps.

First, How would you like to pay? — the methods this invoice can actually take, each with a plain description and, where your provider adds one, the fee it would cost. Card, Apple Pay, Google Pay, SEPA direct debit, PayPal, Klarna, iDEAL, and whatever else your account has switched on. A method that cannot be used for this currency is not hidden; it is shown greyed with the reason, because "why can't I pay with the thing I always use" is a support mail either way.

Then the provider's own card form, embedded right there in the panel. If the bank wants a 3-D Secure confirmation the guest is taken through it and brought back automatically. A Change method link goes back to the list, which is the part the redirect never had — a guest whose card was declined had to start over from the mail.

And then the result, in place of the panel: Instalment paid, Paid in full, Transfer initiated, or The payment did not go through. That last one says what a payer needs to hear and nothing else — "Your bank declined the charge. No money was taken." — and offers Try again and Choose another method without leaving the page.

The card details are typed into fields that belong to the payment provider. They do not reach Gurita, and we do not store them. The line under the pay button says so in the guest's own language: "Encrypted and 3-D Secure — your card details never reach us."

The page around it got rebuilt too

Since the payment moved onto the invoice, the invoice had to be worth looking at.

The status is a chip at the top — Payment due, Partly paid, Overdue, Payment processing, Paid in full, Invoice cancelled — and each instalment on the schedule carries its own state, so Due now and Upcoming and Overdue are three visibly different things rather than three dates the guest has to compare against today.

Where a booking has instalments, the panel asks the question directly: What would you like to pay?, with Next instalment or Full open balance. Bank transfer details sit under the pay button — account holder, IBAN, BIC, the reference, and a code to scan with a banking app — and disappear when nothing is open. There is a language switcher, and the result screen prints a receipt.

One thing quietly went away with this release. There used to be two invoice pages and a plugin flag choosing between them, which meant the page a guest saw depended on a setting they could not see and staff rarely thought about. There is one page now, for everyone.

A card the guest leaves behind

The second half of this release is about the money you do not know about yet — the minibar, the extra dive, the towel that came back in three pieces, the guest who does not arrive.

A guest can now store a card. Nothing is charged when they do.

There are three ways to get one, and the same rule holds in all three: the guest types the card themselves. Staff cannot enter a guest's card number anywhere in Gurita. The list that shows the stored cards says it out loud — "A card is always saved by the guest on their own device — it can never be entered here."

The first way is a card link, created next to the ordinary payment link. It collects no money; the footer says "No amount — this link only stores a card." The guest opens the same page they would open for an invoice, except it reads Card for incidentals and Nothing to pay today, and instead of charges it explains what the card is for: on-board extras, a damage deposit only if something is broken.

The payment link dialog: standing and issued links on the left, and the Payment Link, Store Card and Charge Stored Card actions on the right

The second is at the desk, for a guest standing in front of you. Same dialog, same mandate, except the provider's card form opens inside it and the guest types on your screen. The third is the pre-arrival guest form, which now has a Store a card step on its final page.

Underneath all three is the part that matters legally and the part we were strictest about. The guest agrees to a specific sentence:

I agree that this card may be charged for amounts I owe for this stay — the remaining balance, extras booked on site, a no-show or damage. I can withdraw this consent at any time.

That agreement is recorded with the moment it happened, the version of the wording they saw, the IP address and the device. And it is not decoration: a card with no consent on record can never be charged, whatever else is right about it. The list greys it out and says why.

Charging it

The charge lives in the same dialog, one tab over.

Charging a stored card: the guest's cards, the amount, and the required reason

Pick the card, type the amount, type the reason. Confirm.

Two of those deserve an explanation, because both went against the obvious choice.

The reason is required. It started as an optional note and did not survive the first review. An off-session charge is money leaving somebody's card with nobody standing there to be told why, and that sentence is the only record of the intent — it is what your colleague reads back three weeks later when the guest disputes it, and it is what travels to the payment provider as the description on the statement. A field that important cannot be optional, and it cannot be enforced only in the dialog, so the server rejects a blank one too.

The amount is not capped at the open balance. Damage is by definition not in the calculation. Charging more than is open gives you a warning and a confirmation — "Only €320.00 is open. €500.00 will be charged in full — the surplus is recorded as a credit" — and then does exactly what you told it to.

What comes back is worth reading properly. A charge that needs a 3-D Secure confirmation is not a failure: a link has been created and is waiting for the guest, and the dialog says so in those words, because staff who read that as an error charge the card a second time. A charge whose outcome is genuinely unknown says the one thing that helps — "Do not charge again" — and resolves itself against the provider within about two hours. And a double-click cannot charge twice; the second attempt is recognised as the same charge.

Every confirmation carries the same reminder: "The guest is not present — this cannot be undone here." A refund is a separate step with your payment provider, and pretending otherwise in a dialog would be a lie.

What you can see afterwards

Every card a guest has stored appears on their customer record, on the Payment methods tab.

Cards on file on a customer record, with the consent record behind each card

Brand and last four digits, validity, whether the token is bound to a single currency, and the consent block — agreed on, version, IP address, device. Delete card detaches it at the payment provider so it can never be charged again, and keeps the consent record, which is the half you want if anybody ever asks.

Worth knowing: a guest cannot remove their own stored card. The provider's page has that control switched off on purpose, which makes deleting it here the only way it happens. If a guest asks, do it.

Switching it on

Three fields on the provider, under Settings → Plugins: the Publishable key (Stripe calls it that; it starts pk_), Inline payment form, and Allow saved cards.

If you leave them alone, nothing breaks. The invoice page still works and Pay still takes the guest to the provider's hosted page, the way it always did. The fallback is intentional, and it doubles as the answer to the support question this will generate: an invoice page that still redirects is a provider missing its publishable key, not a bug.

Notes

• Inline payment and stored cards are available on Stripe and FlyWire. Other providers keep the hosted redirect.
• Storing a card and charging one both need the right to create booking payments — the same permission that issues a payment link, so front-desk staff already have it. Deleting a stored card needs its own separate right.
• A successful charge is recorded as an ordinary payment on the booking and raises the usual Payment received notification. Whether that reaches the guest depends on whether you have that notification switched on for the booking contact. A failed charge raises Card charge failed for staff, with the reason the provider gave.
• Stored cards live on the guest, not the booking — a returning guest's card is there next time.

Full details in The guest payment page and Stored cards and charging a card.