Hotel payments with Mews or Stripe: Fees, deposits, and capture

A reliable payment process needs more than a checkout. This guide explores three approaches using Mews and Stripe and explains how hotels can manage payment deadlines, outstanding guest balances, refunds, and daily reconciliation.

A confirmed booking is not the same as secured revenue. A saved card is not a prepayment. Even a successfully captured card payment can be disputed later. Planning hotel payments therefore involves more than choosing a checkout provider: Which amounts are due when, how long does a hold remain valid, and who responds when a payment fails?

For hotels, the main approaches include integrated PMS payments, a custom website with an embedded payment interface, and a separate payment integration. Mews Payments and Stripe illustrate different implementations. The right choice depends on the required workflows, confirmed system compatibility, contractual terms, and responsibility for ongoing operations.

1. Define the payment policy first

Before selecting technology, each relevant booking type needs a clear policy: payment at booking, an initial prepayment followed by the balance, or payments during the stay. Cancellation terms, extras, and any security deposit belong in that policy. A nonrefundable rate, a flexible weekend booking, and a corporate stay lasting several months should not automatically follow the same payment process.

A useful policy answers five questions:

• Amount: What has been paid, what is on hold, and what remains outstanding?
• Timing: When is payment due, when is collection attempted, and when is it checked?
• Agreement: Which payment and cancellation terms has the guest accepted?
• Exception: What happens after a decline, an expiring hold, or a change to the stay?
• Responsibility: Who decides what to do, and by when, if the automated process cannot resolve the issue?

This is an operational design decision. Software can execute the rules a property defines; it does not decide how much outstanding debt the hotel is willing to carry.

2. Separate authorization, capture, and payout

A card payment involves four distinct stages:

1. Authorization: The card issuer approves the amount and reserves available funds or credit.
2. Capture: The merchant requests collection of the authorized amount. The hold becomes a payment to be collected.
3. Settlement: The payment is processed and the funds become available in the payment provider's balance.
4. Payout: Available funds are sent to the hotel's bank account.

Stripe explains authorization and capture as separate steps. Settlement timing and the payout schedule also differ: daily payouts do not automatically make funds available sooner. Cash planning must account for actual receipts, fees, refunds, and any funds withheld.

3. Use precise terms for prepayments, holds, and deposits

A prepayment is collected before the stay. A preauthorization reserves an amount temporarily. A saved card enables a later payment attempt without securing that amount in advance. Staff and guests should be able to distinguish these states.

A security deposit describes an agreed purpose, not a specific payment mechanism. Depending on the permitted arrangement, it may take the form of a card hold or a collected payment. Its amount, the grounds for a charge, and its release or refund must be clearly defined. The room bill and security for potential damage should therefore be separate items in the workflow.

Escrow is a different arrangement again. Stripe explicitly states that it does not provide escrow services or escrow accounts. Delaying a Connect payout does not turn a payment into escrow. A property that needs funds held in genuine escrow must assess an appropriate legal and technical solution.

4. Three payment architectures for hotels

Integrated payment workflows in Mews

Mews Payments connects online and terminal payments, payment links, settlement, and reporting with the PMS. Mews is the commercial point of contact; processors such as Stripe or Adyen handle processing, depending on configuration and region. Prerequisites include Mews Operations and completed merchant onboarding, including business and bank account verification.

Payment policies support fixed amounts or percentages and timing around confirmation, arrival, and departure. A policy can trigger a charge or a preauthorization. For properties whose workflows fit these options, this is a sensible starting point: check what can be configured before commissioning custom development.

A custom website using Mews Payments Checkout

A custom website does not automatically require a separate payment stack. Mews Payments Checkout can be embedded in an application using its JavaScript SDK. It collects payments or saves payment methods with consent, handling card collection, 3D Secure, and recording the result in Mews.

This approach can combine a custom guest interface with payment processing closely connected to the PMS. It is worth considering when the website needs more design flexibility while payment operations should remain in Mews. Booking logic, permissions, and matching each payment to the correct guest still require careful implementation.

A separate workflow using Stripe

A separate Stripe integration requires confirmed compatibility with the PMS or booking system and contractual permission. It is not an interchangeable alternative for every Mews customer. Within that framework, it provides direct control over payment logic. The hotel does not have to develop its own card form: Stripe Checkout offers hosted and embedded interfaces, while more customized components require more maintenance.

That additional flexibility is worthwhile when it meets a specific need. The project must also manage the connection between bookings, payment status, and the PMS. Responsibilities under each contract, payment data access, support, and payments that succeed in one system but are missing from another need explicit answers. A public API is not a completed hotel integration.

5. Every card hold has an expiration date

Stripe supports separate authorization and capture through Checkout and PaymentIntents. Manual capture initially places a hold. Collection must occur before its actual expiration; the card payment's capture_before field identifies that deadline. Not every payment method supports this flow. It cannot secure a booking made months in advance indefinitely.

Extended authorizations can allow up to 30 days when eligible. Card network, merchant category, and feature access matter. Stripe offers this feature on IC+ pricing; access on other pricing models requires confirmation. Mews also notes that a shorter processor deadline takes precedence for preauthorizations.

Incremental authorizations can increase the held amount before capture on eligible payments that remain completely uncaptured. They do not extend the original deadline and may be declined. Operations therefore need an assigned owner and a timely check, not simply a setting enabled once.

6. Limit outstanding balances during long stays

A useful operating principle is to decide how much service the hotel is willing to provide temporarily without successful collection. This limit is an internal risk decision, not a payment guarantee from the card provider.

Consider a hypothetical four-week stay. Under the accepted agreement, the first week is paid before arrival and subsequent weeks are paid in advance. A daily reconciliation identifies outstanding extras and failed payments. Any unpaid amount is addressed before the next service period. Separate security for extras is monitored under its own terms.

This example is not a standard recommendation for every booking. Approved credit limits and invoicing agreements may suit corporate customers. The key is to prevent extensions, additional guests, or expensive extras from silently exceeding the original risk limit. If another charge is declined, the property needs to contact the guest and document its decision under the contract and applicable rules. Unlimited additional charges are no substitute.

7. Saved cards need consent and a recovery process

For later charges, Stripe requires recorded consent for the intended use. This includes the purpose, timing or frequency, and how the amount will be determined. Permission to save a card does not automatically authorize arbitrary extra charges.

A SetupIntent prepares future payments but does not create a charge. Even a payment method configured for off_session use may require additional authentication later. The workflow must be able to bring the guest back to a secure confirmation step. This needs to be planned for balance payments and extensions in particular.

8. Include refunds, disputes, and reconciliation

With Stripe, an uncaptured authorization is canceled; an already successful payment is refunded. Insufficient available funds can leave a card refund pending. The original processing fees are not returned. The original payment method also determines the process for refunds in Mews. Guest communications should distinguish releasing a hold from refunding a payment.

A dispute can result in the payment amount and fees being debited again. The provider does not guarantee that a challenge will succeed. Booking terms, accepted charges, evidence of service, and communications should therefore be easy to retrieve. This will not prevent every dispute, but it supports effective handling.

In a custom integration, returning to a success page is insufficient evidence of payment. Stripe describes server-side status checks and webhooks for this purpose. Events can arrive repeatedly or out of order, so signatures and duplicate events must be handled correctly. Operations also need regular reconciliation between bookings, invoices, payments, refunds, and payouts, with a visible list of unresolved differences.

9. Compare fees as part of total cost

On November 10, 2026, Stripe's Swiss standard pricing lists online card payments at 2.9% plus CHF 0.30 for Swiss cards and 3.25% plus CHF 0.30 for international cards. Required currency conversion adds 2%. Other products and disputes can create additional costs; individually negotiated terms may differ.

With Mews, the property's agreed terms apply. Its IC++ model combines interchange, network, and Mews transaction fees. A published pricing example is not a quote for a particular hotel.

The comparison also needs setup, additional interfaces, terminals, refunds, failures, maintenance, and staff time. A separate solution is not necessarily cheaper because one visible fee looks lower. Existing PMS services should not be counted twice as new project costs.

10. Decide using a complete payment scenario

Before selecting a solution, have a representative flow demonstrated: booking with prepayment, a change to the stay, balance collection, a failed attempt, an authorized refund, and reconciliation with the payout. Add a long stay and an expiring preauthorization. Check who sees and resolves each exception.

Oprivia's perspective centers on clear responsibilities, evidence, and traceable exceptions. This guide describes architecture options to assess. It does not claim a production Oprivia integration with Mews or Stripe. The useful next step is a decision based on the specific property's workflows and total costs.