Payments are part of the stay: what should a glamping payment flow prove?

Treat each payment event as part of the stay.

The American Glamping Association article “RMS Pay launches in North America” was the discovery source. It presents payments as part of the booking and stay. UNIKOST uses that question as a research lead, then checks the functions against current RMS documentation and PCI Security Standards Council guidance. The interview's structure, images, endorsements and performance claims are not reproduced here.

Write the payment sequence beside the guest journey. A reservation may create a deposit, a later date may trigger the balance and an on-property activity may add a charge. Cancellation can stop future collections while leaving a refund decision for staff. A chargeback may appear after departure and reduce a later payout.

Choose a stable identifier that follows the transaction across these records. Staff should be able to begin with a reservation and reach the original payment, later refund and settlement batch without searching unrelated exports.

Define the policy before automating the charge.

Decide which rate or booking source uses a deposit, how the amount is calculated, when the balance is due and what changes for a late booking. Record who pays when an OTA, travel agent, company or guest sits between the property and the payment.

RMS documentation says schedules can use a fixed amount, a percentage, the first night or another rule. It also describes saved-card charges and pay-by-link requests for RMS Pay users, with manual fallback when card or contact data is unavailable. These functions do not approve the property's cancellation or no-show policy.

Test date, unit, rate and payer changes. RMS's advanced schedule documentation says future payments stop on cancellation while refunds remain manual, and unpaid payment links may need manual cancellation. Verify the same behavior in the version offered to the property.

Tokenize the card and document what remains in scope.

The PCI Security Standards Council defines tokenization as replacing the primary account number with a surrogate value. Its guidance says this may reduce cardholder-data exposure and simplify part of PCI DSS validation. It does not eliminate PCI DSS responsibility.

Ask who captures the card, where account data can appear, which systems receive only a token and what the property must validate. Employees should not paste card numbers into reservation notes, email or chat.

Gateway exit is an operating risk. RMS Pay's FAQ states that its payment tokens do not transfer between gateways. Upcoming guests may need to add a payment method again. Ask every candidate for a written migration path and identify how old refunds will remain available.

Preserve the original payment through a correction.

A refund should point back to the payment it changes. Record the amount, reason, approver, processor reference, folio entry and accounting date. Tell the guest what the property did without promising a bank posting time the property cannot control.

RMS Pay documents limits on blind refunds in stated legacy-gateway and POS cases. It also recommends refunding the original receipt instead of reversing it because a reversal can disturb the accounting date and settlement view. Ask every provider how an old-gateway refund and a partial refund appear in the folio, processor and payout report.

Match the payout, not only the guest folio.

For each payout, staff need the gross captured amount, refunds, chargebacks, fees, adjustments, net payout and a reference that appears on the bank statement. Decide whether reconciliation uses a batch, settlement date or another stable grouping.

RMS's settlement documentation describes grouping cleared transactions by batch ID. It also says refunds and chargebacks can create negative amounts in a later settlement period. The booking, accounting, settlement and bank-posting dates may differ.

Give one person the daily exception list. Pending payments, duplicate attempts, unmatched deposits, negative batches and chargebacks need a visible owner and response window.

Run the same evidence script for every candidate.

Use a test environment. Record timestamps, references, notifications and every manual step.

Add the selected rules, exception owners, gateway boundary and reconciliation process to the project brief. Keep the payment map beside the glamping operating stack. Use the opening-readiness guide to test permissions, notices, terminals and refunds before the first paid stay.