To manage security deposits across multiple holiday rentals, track each deposit against a unique booking reference and review authorization exceptions, capture deadlines and inspection decisions in separate queues. One property can have an outgoing guest awaiting inspection and an incoming guest awaiting authorization on the same day. Those are two different deposits.
This guide gives small property-management teams an original register design and daily handover routine. PayRequest supplies the deposit-payment workflow; the register, inspection assignment and escalation process below are proposed operating practices you can implement in your existing tools.
Track bookings rather than counting properties
The number of homes does not tell you how many open deposits the team must manage. A new request may remain pending before arrival. An existing authorization may stay open until inspection. If both guests occupy adjacent dates in the same property, both records can need attention simultaneously.
Use a booking reference that remains unique even when the same guest returns or several properties share an owner. Combine that reference with the exact deposit request and provider authorization references. The guest's surname, property nickname or month alone is too ambiguous for a final capture or release decision.
Separate accommodation payments from security funds. Keep the rent invoice or payment reference available for reconciliation, but never mark a deposit active because the rent was paid. Equally, releasing a damage-deposit hold should not be recorded as refunding the accommodation price.
The holiday rental security system guide defines the whole lifecycle. Here the task is narrower: keep several simultaneous lifecycles visible, assign responsibility and avoid losing a deadline during a busy changeover.
Build a multi-property security deposit register
Start with the smallest record that lets a colleague make the right next decision. Store sensitive inspection evidence in the appropriate restricted location, linked from the register when needed. Do not copy card numbers, security codes or identity-document images into a shared spreadsheet.
| Register field | Why it matters |
|---|---|
| Unique booking and property references | Distinguishes visits and units |
| Guest contact through established channel | Supports recognizable communication |
| Arrival and departure with timezone | Makes the operating timeline explicit |
| Agreed amount and currency | Prevents cross-currency assumptions |
| Deposit request and provider references | Connects the row to the actual funds |
| Last confirmed status and checked time | Distinguishes known facts from stale notes |
| Actual capture deadline | Sets the final decision boundary |
| Inspector and inspection target | Assigns evidence collection |
| Decision owner and next review time | Keeps an exception from becoming ownerless |
| Captured amount, released amount and confirmation | Supports final reconciliation |
This is an original proposed worksheet, not a PayRequest export specification. Adapt the columns to the records your connected provider and booking system actually expose. A field with an unknown value should remain visibly unknown; a guessed deadline is worse than an explicit task to verify it.
Use consistent currencies and timestamps. If the spreadsheet sorts dates as text, “9 November” and “13 November” may not appear in the order staff expect. Use a real date-time field and show the timezone. Preserve the provider's exact deadline rather than rounding it to midnight for convenience.
“Funds reserved” is a status. “Inspect Monday at 11:00, then review by 13:00” is an action. Both matter. A table full of active deposits can look reassuring while several authorizations are approaching expiry and no inspector has been assigned.
Likewise, “Waiting for customer” needs a contact owner and review time. It should not sit indefinitely beside completed stays. Keep your operating labels distinct from provider status values and do not rewrite the provider state because a member of staff sent a reminder.
Work through three properties on one changeover day
Imagine a fictional manager with three cottages. At 09:00 Monday, Oak has an outgoing booking awaiting inspection and an incoming Friday booking with a pending request. Dune has an active guest hold whose confirmed deadline is Tuesday at 12:00. Harbour's previous guest has checked out and its clean inspection is complete.
The team sees three properties but four open deposit records. The following amounts illustrate register design only; they are not suggested security-deposit prices or typical authorization windows.
| Booking | Property | Agreed amount | Confirmed position | Next action |
|---|---|---|---|---|
| OAK-OUT | Oak | €400 | Funds reserved; inspection due | Inspector reviews at 10:00; owner decides by 12:00 |
| OAK-IN | Oak | €400 | Waiting for guest | Contact guest; verify timing before Friday |
| DUNE-STAY | Dune | €300 | Funds reserved; Tuesday deadline | Confirm departure and inspection can finish in time |
| HARBOUR-OUT | Harbour | €350 | Clean inspection; funds reserved | Request release and verify confirmation |
Do not offset Harbour's €350 against Oak's €400, or treat the incoming Oak guest as covered by the outgoing guest's reservation. Each authorization protects its own agreed booking. The table helps staff see work to do, not a pooled balance available for general property costs.
For Dune, the deadline triggers a review even if no guest has complained. If the stay or inspection would extend beyond it, the manager needs a supported solution and guest communication before the deadline. A deposit tool does not make an expired authorization capturable again.
Review three operating queues each day
Create an arrival queue for requests not yet confirmed, a deadline queue for active holds approaching their actual expiry, and an inspection queue for completed stays awaiting a final decision. These can be filtered views of the same secure register. They need not be three separate systems or another property-management subscription.
At the start of the day, confirm who owns each exception. At handover, review what changed, what remains uncertain and the next review time. Before staff leave, check the deposits whose deadlines occur before the next staffed shift. Choose a buffer that reflects your operation rather than copying a universal number of hours.
If a guest reports a decline, use the failed deposit authorization checklist. Check the original provider record before creating a replacement. A processing attempt or missing confirmation email should not automatically become a second request from another employee.
For recurring operational reports, measure your own counts: requests awaiting guests, unresolved attempts, holds approaching deadline, inspections overdue and provider-confirmed releases. Those are proposed management metrics. This article does not claim PayRequest automatically produces these combined reports or that a particular threshold guarantees lower losses.
Hand inspection evidence to one decision owner
The inspector records what they found; the decision owner checks whether any amount is supported by the agreed conditions and evidence. In a small team these may be the same person. When they differ, make the handover explicit before the deadline approaches.
A useful inspection note identifies the booking and unit, inspection time, relevant before-and-after evidence, description of the issue and itemized cost basis. A vague message such as “something broken at Oak” cannot safely support a capture. Do not charge ordinary wear or items already included in the accommodation price simply because funds remain reserved.
Finish the review before submitting a final Stripe capture. PayRequest's current Stripe flow allows one capture; a partial capture releases the unused amount and closes that authorization. If a €400 hold supports an agreed €70 charge, the final outcome is €70 captured and €330 released, rather than €330 remaining available for later discoveries.
For a clean inspection, request release without waiting for the authorization to expire as a routine substitute. Then record the provider confirmation. Tell the guest what was released and when, while explaining that their bank determines when its pending display and available balance update. A release is not a refund of an amount previously charged.
Plan request capacity around overlap
Estimate both new requests per calendar month and peak simultaneously open requests. In the fictional table above, four records are open even though there are three properties. If all three cottages instead had an outgoing open hold plus an incoming pending request at the same time, that would be six open requests.
PayRequest's current deposit plan limits count pending requests as open. Free includes three new requests per calendar month and one open request; Premium includes fifteen new requests and five open; Business has unlimited requests. Closing an eligible unused request frees open capacity but does not restore its monthly request allowance.
Therefore, an operator expecting six simultaneous open requests should evaluate Business capacity rather than assuming Premium's five open slots cover three properties. This arithmetic is a planning example, not a statement that every three-property operator needs Business. Review your actual booking overlap and the current pricing page.
Free is €0, Premium €5/month and Business €20/month. Selecting a paid plan during signup does not activate it: setup and paid checkout are separate steps. Standard payment fees, provider fees and deposit-capture rules must be considered separately; do not calculate deposit costs by applying an ordinary payment headline without checking the actual flow.
Connect the register to PayRequest without duplicating work
Use PayRequest Security Deposits for dedicated authorization links, confirmed deposit information and supported capture or release actions. Use your existing register to assign inspections and staff responsibilities. Keep the same booking reference visible on both sides so that a teammate can reconcile a record quickly.
The vacation rental deposit page is the relevant product starting point. Keep accommodation billing in your usual invoicing workflow and investigate an API integration only when the manual mapping creates enough work to justify it. Do not assume a generic booking or lock integration exists without checking its specific supported actions.
Before expanding the property portfolio, review one clean departure, one supported charge and one incomplete authorization across a staff handover. This is a proposed operational rehearsal, not a request to charge a real guest for testing. Confirm that each has the right booking, exact provider reference, next owner and final recorded outcome.
*Editorial method: original register, queue design, overlap calculation and fictional three-property scenario. Public documentation reviewed on 13 November 2026. AI assisted writing and illustration; no customer performance, live payment test or built-in portfolio dashboard is claimed.*


