Payment Processing Software for Short-Term Rentals: A Guide
When a booking comes through Airbnb, Booking.com or Vrbo, the platform is the merchant of record. It screens the guest, collects the money, handles the refund when plans change, and deals with the card network if the charge is disputed.
Take a booking on your own website and that role transfers to you. Your business name appears on the guest's statement, the funds arrive in your account, and the chargeback risk, refund handling and data-security obligations arrive with them.
So choosing payment processing software for short-term rentals is less about the headline percentage than about three questions: who carries the risk at each step, how deposits and holds behave between booking and check-out, and what your fees actually average across a season of real bookings rather than a sample transaction.
What Changes When You Become the Merchant of Record
Merchant of record is the party the card networks hold responsible for a transaction. On the OTAs that is the platform. On your own site it is your business — the entity that signed the merchant agreement with the processor or acquiring bank.
Four obligations move to you at that moment:
Disputes. A guest can ask their card issuer to reverse a charge. Your terms, your messages and your check-in records are the evidence the decision rests on.
Refunds and cancellations. Your cancellation policy stops being a platform setting and becomes a commercial term you must apply consistently, because inconsistency is what guests dispute.
Payout timing. How quickly money reaches your bank varies by processor, country, transaction type, account history and any reserve terms on your account. Some pay on a fixed schedule, some delay for new accounts, some hold part of the balance. Read your own agreement instead of assuming a standard number.
Data security. PCI DSS applies to any business that accepts card data, whatever its size.
That is the trade-off at the centre of OTA versus direct booking: you keep the commission and the guest relationship, and you take on administrative work the platform used to absorb.
The Core Payment Stack for Vacation Rental Owners
Most owners and small managers do not need a high-risk merchant account with terminals and complex underwriting. They need a gateway with hosted checkout, tokenisation for later charges, and a clear disputes process. Four routes come up most often.
Stripe
Stripe is widely used by independent booking engines and hospitality software, commonly because its tools are well documented, it supports many local payment methods, and its tokenisation makes stored-card and off-session charges straightforward. If a booking engine includes a gateway out of the box, it is often this one.
The trade-off: you remain the merchant. The processor, not you, sets the account terms, and reserves or payout holds can be applied to new accounts taking large card-not-present payments. That is how merchant underwriting works generally rather than a quirk of one vendor, which is why you read the reserve and chargeback sections before your first peak season.
PayPal and Braintree
PayPal's value is recognition: some international guests would rather pay a brand they know than enter card details on a small website. Braintree, its card gateway, can keep card payments on your page with the PayPal wallet offered alongside.
Two things to check before relying on it. Which PayPal product you use determines how the payment is treated — booking, goods purchase or personal transfer — and each carries different terms and refund mechanics, so read the current user agreement for your own country rather than repeating what other hosts say. And because a wallet flow often redirects the guest away from your site, keep a card option on the same page if you offer one.
Square
Square is built around card-present payments and is a strong fit for balances taken at a reception desk, a market stall or over a counter; its online invoices and virtual terminal work for deposits. For any provider whose core product is card-present, ask directly how it prices and limits card-not-present bookings taken months before the stay and in four figures. Ask about advance card-not-present volume, reserve policy, and what documentation is expected in a dispute, and get the answers in writing.
Stripe Connect inside a booking engine
Rather than wiring a gateway into your own site, most hosts reach payments through booking software. With a Connect-style setup, you link your own processor account to the booking engine, which then handles the checkout form, the balance schedule and the receipts. You keep the merchant relationship: the account is yours, payouts go to your bank, disputes are yours to answer. The trade-off is that the booking engine is not a buffer — the evidence, the deadline and the funds at stake are still yours — and you depend on a third party for how the checkout behaves, so test it yourself in more than one currency before sending it traffic.
Security Deposits, Holds and Card-on-File
Damage deposits are where direct booking most often goes wrong, because the tool hosts reach for first — a long hold placed at booking — rarely fits how bookings work.
Holds versus charges
Charge and refund. Take the deposit as a normal payment and refund it after your inspection. Simple, and the amount is visible, but the guest's money genuinely leaves their account, and a cardholder billed in another currency may get back slightly more or less than they paid depending on the rate applied at refund. Say so in your terms.
Authorisation without capture. The guest's available credit is reduced, but no money moves unless you capture. It costs the guest nothing if there is no damage. Its weakness is time.
Why hold windows are not uniform
How long an authorisation stays open, and whether it can be extended, is not one number. It depends on the card network's rules for that transaction type, the issuing bank, and what your processor and acquirer will support for your merchant category and account. Hotel-style agreements are not the same as standard e-commerce accounts, and providers differ in what they allow. Some merchants hold across a stay; others find the hold lapses and the funds release to the guest.
Do not build a deposit policy on a hold you have not tested. Place a test hold, note the date, check shortly after the expected stay whether it was still capturable, and if it was not, use card-on-file instead.
Card-on-file, done properly
Tell the guest at checkout that the card will be stored for damage or incidentals, and get an affirmative opt-in — not a pre-ticked box.
Save the token, not the card number; the token lives in the processor's vault.
Trigger the hold or charge close to arrival rather than months ahead, so there is something left to capture.
Release or refund on a stated schedule after inspection, and tell the guest when it happens.
For the guest-facing side of that flow, see vacation rental online booking.
SCA, 3D Secure and European Bookings
If you take payments from cardholders in the UK or the EEA, Strong Customer Authentication applies. It requires multi-factor authentication for most electronic payments, and in practice the guest is challenged through 3D Secure — a code in their banking app, a biometric check or a one-time passcode — during checkout.
What authentication does and does not cover
An authenticated transaction is designed to move fraud liability to the card issuer, so a later claim that the card was used fraudulently is much harder to charge back. Authentication does not cover the "not as described" or cancelled-trip dispute; that still comes down to your terms and your evidence.
On-session and off-session charges
On-session: the guest is on your site and can authenticate there and then. This is the booking payment, and it is where consent for later charges is established.
Off-session: you charge the stored card later, when the guest is not present — a balance before arrival, or a damage charge after departure. To avoid routine declines, the original payment must be flagged as a merchant-initiated transaction tied to the guest's mandate. Your processor configures this; confirm it is enabled before you rely on it.
How to Compare Real Effective Fees
Headline rates are quoted for a card-not-present transaction on a domestic consumer card, in your own currency, at a stated volume. Real bookings are messier. Work in your own currency — a £2,000, €2,300 or $2,600 weekly stay behaves the same way.
What moves your effective rate — total fees divided by total value collected — is the mix of cards you accept:
| Transaction type | What usually adds to the fee | What to verify with your processor |
|---|---|---|
| Consumer card issued in your own country | Interchange for the card's tier, plus scheme and processor margin | Whether the quoted rate covers standard cards only |
| Card issued in another country or region | A cross-border assessment, sometimes a different interchange tier | Whether your quoted rate already includes cross-border fees |
| Payment in a currency other than the card's | A conversion margin on top of the payment fee | Who converts, at what margin, and who bears it |
| Premium, rewards or commercial card | A higher interchange tier that quoted rates often exclude | Whether commercial cards are priced differently on your account |
| Refunds and disputes | Refund fees where they apply, plus a dispute fee | What a chargeback costs whether you win or lose |
Then measure rather than estimate. The test is repeatable:
Export your settled transactions for one quarter, with gross amount and fees charged.
Divide total fees by total gross volume. That is your effective rate.
If your processor reports the card's country of issue, split the total into domestic and foreign-issued cards and repeat for each group.
Repeat next quarter and compare. Pass means the effective rate is stable and still clearly below the commission you would have paid had the same booking come through a channel that charges one.
If the figure drifts, the cause is usually mix — more international cards, more premium cards, more refunds — rather than a rate change, and your statement shows which. For the wider setup, see the direct booking playbook.
PCI Compliance for Independent Hosts
PCI DSS applies to every business that accepts card data; low volumes do not exempt you. They do allow a lighter compliance route, provided your setup is built the right way.
The danger of manual card handling
The riskiest habit in this industry is handling card details by hand. A card number taken by email, read over the phone into a notebook, sent through a messaging app, written on a paper registration form or kept in a spreadsheet sits somewhere with no encryption, no access control and no audit trail. Your inbox provider, your laptop and your backups are all in scope the moment that data lands there, and the loss is not just financial — it is a guest whose card was exposed because you were helpful. Never store the security code, even on paper, and never ask a guest to send card details through a channel you would not send your own through. If a guest offers, reply with a payment link instead; it takes a minute and removes the problem entirely. If you have already stored card data anywhere, delete it and ask your processor to re-vault the cards that matter.
Hosted fields and hosted checkout
Modern gateways let the card number be typed into an iframe served by the processor, or on the processor's own checkout page. The data goes into their vault and your site receives a token. Because card data never touches your server, you are usually eligible for the shortest self-assessment questionnaire (SAQ A); confirm eligibility with your processor and acquirer, since the questionnaire you file depends on how the integration is built.
Common Mistakes Hosts Make When Processing Payments
Booking without recorded terms. A dispute is decided on evidence: the policy the guest agreed to, the dates, the messages. If consent is not captured at checkout, you start from behind.
Refunding outside the gateway. Refund to the card that paid, through the same processor. A bank transfer leaves the original charge open to a chargeback.
Assuming a reserve cannot happen. Processors may apply a rolling reserve to new accounts or to unusually large card-not-present volume. The percentage, duration and trigger are set out in your merchant agreement — ask before signing, and model cash flow as if it applies for the first season.
An unrecognisable statement descriptor. If the name on the guest's statement is a company they have never dealt with, they may dispute a charge they made themselves. Match the descriptor to the name guests booked under and send a clear confirmation immediately; a good reservation confirmation does most of that work.
Timing deposits badly. A hold placed months before arrival may expire before it is needed, leaving nothing to capture at check-out.
Never testing the flow. Run a real transaction on your own site in more than one currency, refund it, and inspect the emails and the statement descriptor that result.
Choosing a Setup You Can Live With
The right answer is usually the least interesting one: a gateway account in your own name, connected to a booking system you control, with tokenisation for balance and damage charges, hosted fields for PCI, and a written record of how disputes are handled. Before committing, ask any provider these questions and keep the answers:
Whose name is on the merchant agreement, and who is liable for a chargeback?
What is the payout schedule, and what changes it?
Is there a reserve policy, and what triggers it?
Do you support merchant-initiated transactions, and how do I enable them?
What does a chargeback cost, win or lose?
Which self-assessment questionnaire applies to this integration?
If you are choosing the booking layer too, Rentabble builds direct-booking websites for holiday rentals that connect to a gateway account you own, keeping the merchant relationship and payout schedule with you; check the current integration and terms directly with them.
What to Do First
Start with the account, not the website. Open a gateway account in your business name, read the reserve and dispute sections, and run one test transaction end to end. That single test teaches you more about payout timing and your statement descriptor than any comparison table.
Then settle the deposit method. Decide whether you need a hold or a stored card, test your choice against a real stay length, and write the consent wording into your terms. Fees come last: once a quarter of statements shows your mix of domestic, foreign and premium cards, you can calculate an effective rate you can defend and compare it honestly with the commission you would otherwise pay.
