Moving payments between bookings

Sometimes a payment ends up on the wrong booking, or needs to move as part of a normal booking lifecycle event — a guest rebooking after their booking expires, a contract renewal, or a room move. The money was received correctly; it just needs to sit on a different booking.

Moving a payment reassigns it to another booking without reversing it and re-recording it by hand. The payment keeps its original identity and its card or bank link, so your records — and any later refund — stay connected to the original transaction.

What happens when you move a payment

The payment’s receipt (the record of the payment) is reassigned to the destination booking.
Nothing is reversed or re-created — there is no payment reversal note and no duplicate payment. It is the same payment, now on the correct booking.
The link to the original card or bank transaction is preserved, so a refund can still be issued — now from the destination booking.
The payment is re-applied to the destination booking’s open invoices automatically (oldest invoice first, matching currency). See Allocations.
Every move is recorded for audit, so you can always see which booking a payment belongs to now and the outcome of its most recent move.

What you can move

Payments on bookings within the same workspace.
Payments where the original and destination booking use the same payment provider.
Whole payments — a payment moves in full; it can’t be split across bookings.
Regular receipts and deposit receipts.

Both the original and destination booking must be in one of these states: tentative, confirmed, expired, or cancelled.

When a payment can’t be moved

A payment can’t be moved, for example, if it:

hasn’t been issued yet;
has already been reversed or refunded (in full or in part), or has a refund in progress. A refund that has since been cancelled by a refund reversal note no longer counts;
came from an online travel agent (OTA) channel; or
is on a workspace where the feature isn’t switched on yet.

You don’t have to guess: a payment carries its own “can this be moved?” status and, when it can’t, the reason — so this can be shown in your tools before the action is offered. A few checks depend on the destination booking — such as it using the same payment provider — and are confirmed when you make the move.

Recording why a payment was moved

When you move a payment you can record a reason — for example that it was on the wrong booking, a duplicate, a guest request, or a general correction. The reason is kept with the audit record so the move is easy to understand later.

Using the API

Moving payments is available through the Accounts Receivable & Payments API. Rather than repeat request formats here, use the ready-made examples in the Postman collection and Apollo explorer — they show how to check whether a payment can be moved, perform the move, and confirm the result. Links are on the Accounts Receivable & Payments API integration page.

Moving a payment uses the same permission as issuing a refund: anyone who can refund a payment can move it.

Getting notified when a payment moves

A single move raises two webhooks, so your systems can stay in sync without polling:

Webhook	Topic	What it signals
`v2.invoicing.receipt.moved`	invoicing	The receipt has been reassigned to the destination booking.
`v2.payments.payment.updated`	payments	The underlying payment has been updated to reflect its new booking.

Subscribe to whichever fits your integration. For payloads, schemas, and to test events, see the webhook catalogue at https://webhooks-docs.lavanda.app/.

Availability

Moving payments within a workspace is available today, enabled per workspace by Lavanda. Moving payments between workspaces, and moving them automatically as part of rebooking and renewal flows, are planned for a later release. If the capability isn’t available on your workspace, contact your Lavanda representative.