Hotel Payments Architecture: Multi-Currency Checkout, Deposits and Refunds for Gulf and Singapore Properties

TL;DR: A hotel payments stack has to do four jobs well: take a deposit without scaring the guest, hold funds during the stay, settle the final bill in a currency the guest understands, and refund cleanly when plans change. In the Gulf and Singapore each job has local twists: dirham and Singapore dollar settlement, tax and fee lines that must appear correctly on folios, QR-first payment habits in Singapore, and card-scheme rules on currency conversion. This guide walks through the architecture choices (tokenisation, authorisation strategy, multi-currency ledgering, refund workflows) and the questions to put to any vendor or build partner. Nothing here is legal advice; confirm regulatory points with your acquirer and advisers.

Why hotel payments are harder than retail checkout

A shop takes a payment once. A hotel takes a payment, then another, then adjusts the first, then maybe reverses it.

Consider one booking. The guest pays a deposit weeks ahead. On arrival the front desk places a hold on a card for incidentals. During the stay the minibar, spa and restaurant add charges. At checkout the final bill is settled, the hold is released, and a week later the guest disputes a line or asks for a refund on a cancelled add-on. Every one of those events touches the property management system (PMS), the payment gateway, the acquirer, the accounting ledger and often a channel manager or online travel agency (OTA) feed.

For properties in the UAE and Singapore, add three complications. First, a large share of guests are paying in a currency that is not the one you settle in. Second, tax and fee lines on a folio are not optional decoration; they have to be right. Third, regulators in both markets treat payment services as licensed activity, which shapes who you can sign up with and what they must do for you.

If you are still deciding how guests book in the first place, our piece on building, buying or going hybrid on a direct booking engine for UAE, Singapore and UK hotels covers the front half of the journey. This article picks up at the moment money moves.

The four payment moments you need to design for

1. The deposit or prepayment

Deposits protect revenue against no-shows, but they also create the first friction point. Decide early whether you take a deposit as a captured payment, as an authorisation only, or not at all for flexible rates. Each has a different refund path.

A captured deposit is simple to reason about and creates a refund obligation if the guest cancels within terms. An authorisation-only approach avoids moving money but depends on the hold surviving until check-in, which is a problem for long lead times (more on hold lifetimes below). Many properties therefore take a captured deposit for non-refundable or semi-flexible rates and store the card securely for the balance.

Whatever you choose, the booking engine and the PMS must agree on what was taken. Mismatches between the two are the root of most "we charged the guest twice" stories.

2. The stay-time hold

At check-in the front desk typically places a hold for the expected stay plus incidentals. Two practical points matter for architecture.

Authorisations expire, and the lifetime varies. One hospitality payments provider's help guide notes that validity depends on the card scheme and sometimes the merchant category code, and gives indicative figures: Visa from around five days for standard transactions up to thirty days for lodging-type pre-authorisations, American Express typically seven days, and Diners seven to thirty days with lodging generally at the longer end. The same guide says Adyen generally expires pre-authorisation requests automatically after 28 days. Treat those as a vendor's summary, not a scheme rulebook, and ask your acquirer for the figures that apply to your merchant category. The design consequence is the same either way: your system should track hold expiry dates and either refresh the hold or flag the folio before it lapses on a long stay.

Holds also need topping up. A hospitality payments vendor summarising scheme rules describes a model in which the first hold can cover the estimated stay plus a margin for incidentals, and where Mastercard lodging rules require a new, added hold when charges go over the first one. The exact thresholds are scheme- and region-specific, so the lesson for architects is to build incremental authorisation as a first-class operation in your PMS-to-gateway integration, not an afterthought handled by the front desk with a second swipe.

3. Final settlement at checkout

Checkout is where most currency decisions surface. The guest sees a folio in the property's base currency, may be offered a choice to pay in their card's billing currency, and expects a receipt that matches. Done well, this is invisible. Done badly, it is the source of chargebacks and one-star reviews.

4. Refunds, adjustments and disputes

Refunds sound easy until you ask which transaction they reverse, in which currency, at which exchange rate, and whether the tax lines unwind proportionally. We give this its own section below.

Multi-currency checkout: three models, honestly compared

There are three common ways to handle a guest whose card is not in your settlement currency.

Dynamic currency conversion

DCC lets an international customer pay in their home currency. In the in-person flow described by one hotel payments vendor, the terminal reads the card's billing currency and, if it differs from the local one, prompts the guest to choose between the local currency and their own. If they accept, the conversion is applied and the receipt shows it; if they decline, the transaction continues in the local currency.

The same vendor's documentation states the rules plainly: according to card scheme regulations, the guest must be given the choice to accept DCC or decline it, must be made aware of the cost of the conversion, and cannot have the choice forced on them. It also warns of fines and loss of DCC privileges for non-compliance. The worked example on that page applies a markup that is shared between the hotel, the technology provider and the payment processor. Markup levels are commercial terms and vary by provider, so ask for them in writing.

For your architecture, this means DCC is not just a toggle. The choice screen, the disclosure wording, the receipt format and the audit log of what the guest selected all need to be built or verified. If you use a build approach, keep the conversion quote and the guest's explicit selection together as a single stored record against the transaction. When a dispute arrives you will want to show exactly what was offered.

Multi-currency pricing in the booking engine

If most of your online guests come from a few source markets, publishing prices in those currencies can improve conversion and avoid a surprise at checkout. The trade-off is that your finance team now holds exposure between the booking date and settlement. Decide who owns that risk, and whether the gateway locks the rate at booking or at capture. A deposit taken in one currency and a balance in another can leave a small residual that never nets to zero; plan for how your ledger treats that.

Tokenisation and PCI scope: architecture first, compliance second

Cards on file are essential for hotels (balance collection, incidentals, no-show fees), but storing card numbers in a PMS database is a liability.

Tokenisation replaces the card number with a token that is useless outside your payment provider. Adyen's hotel guide describes two flavours: proxy tokenisation, where payment details in a reservation are tokenised before they reach the PMS (reducing the PMS's PCI scope), and network tokenisation, where the card network itself issues the token. Its summary is that tokenisation makes PCI compliance easier, more affordable and sustainable, which is a more careful claim than "tokenisation removes you from PCI". You still have obligations; they are smaller and more tractable.

In practice, a sound design has these properties:

• Card data enters through hosted fields or a provider-hosted page, never through your own form fields on a server you control.
• The PMS, channel manager and CRM store tokens, never primary account numbers.
• Tokens are scoped by merchant and, where possible, by property, so that a leak from one system is not usable elsewhere.
• Logs are scrubbed. This is the one that catches teams out, because a verbose integration log is where card data most often leaks.

For the wider picture of how payment systems sit inside the rest of the hotel stack, see our guide to cybersecurity architecture for hotel tech stacks, protecting PMS and payment systems from integration risk. If you want a deeper treatment of the controls, our piece on data security architecture for fintech, covering PCI DSS and related regimes goes further than a hotel-specific article can.

The Gulf: what to design for in the UAE

Licensing and who you can contract with

The UAE Central Bank issued its Retail Payment Services and Card Schemes Regulations on 6 June 2021, according to a summary from the law firm Al Tamimi. The summary lists merchant acquiring among nine regulated retail payment service categories, notes that card schemes can be licensed, and says providers have obligations on safeguarding funds in transit, transparency of terms, liability for unauthorised transactions and refunds, and protection of personal data. That summary is dated 2021, so check for later amendments with your legal adviser.

What this means for a hotel is simple. Your acquirer or payment service provider should be able to tell you its licensing status, and your contract should be clear about settlement timing, refund handling and liability for fraudulent transactions. Do not assume that a global gateway's terms are identical in the UAE.

Taxes and fees on the folio

Folio design is part of payments architecture, because the charge that hits the card must match what the guest sees itemised. A consumer-facing property guide reports that UAE hotel charges include 5% VAT, alongside municipality fees and service charges, and that Dubai applies a flat nightly Tourism Dirham fee (the same guide gives a range of AED 7 to 20 per night for Dubai in a comparison table, without citing an official source). Those are consumer-blog figures, not government publications, and rates and structures change, so confirm current rules with the relevant authorities and your tax adviser before configuring anything.

The architectural point stands regardless of the figures. Build tax and fee lines as configurable rules, scoped by property and date, rather than hard-coded percentages. When rules change, you want to update a configuration table, not redeploy a PMS integration. The same guide notes that tourism fees are not refundable through a departure refund system, which matters for your refund logic: a partial refund of a stay may not unwind every line proportionally.

Guest mix and currency

Gulf properties often see a wide spread of guest nationalities. That raises the importance of a clear DCC policy, localised receipts and a refund path that handles currencies the guest never used directly. It also raises data-handling questions, since personal data in booking and payment records may fall under the UAE's data protection rules. Have your counsel confirm which apply to your operation.

Singapore: QR-first habits and clear licensing lines

What guests expect to pay with

Stripe's guide to payments in Singapore says credit and debit cards are the prevailing method for many Singaporeans, with contactless and online card payments both significant, and lists QR codes such as PayNow among popular consumer methods alongside digital wallets and bank transfers. For a hotel, that suggests supporting cards first but not treating QR as an afterthought, particularly for restaurant, spa and event payments on property.

The Monetary Authority of Singapore describes SGQR as a way to avoid the fragmentation caused by many proprietary payment QR codes at one merchant. Its page for merchant acquirers says SGQR membership is open to licensed financial institutions providing merchant acquisition under the Payment Services Act 2019, exempted providers (including banks), and public authorities. If a vendor offers you an SGQR label, it is reasonable to ask which category they fall under.

Regulation of providers

Stripe's overview says the Payment Services Act regulates payment systems and service providers in Singapore and requires certain providers to safeguard customer money; it also notes MAS anti-money-laundering guidelines for payment service providers. As with the UAE, the practical advice is to confirm your provider's licensing status and read the settlement and refund clauses carefully.

Tax and service charge lines

Singapore hotels commonly present a service charge and a goods and services tax line on the bill. We have not verified current rates for this article, so we will not quote them. Configure them as rule-driven lines, as above, and have your tax adviser sign off on how they appear on invoices and refunds.

Designing refunds that do not break your books

Refunds are where payments architecture earns or loses its keep. A few principles help.

Refund against the original transaction. Most gateways let you refund to the original card up to the captured amount. Store the gateway reference against each folio line so a refund can find its source. Refunds to a different card or method are an exception that should require approval.

Keep currency explicit. If the original payment went through DCC in the guest's currency, the refund is processed in that currency. A refund quoted in the property's base currency may not match what appears on the guest's statement. Show both on the refund record.

Separate cancellation logic from refund logic. The rate plan decides what is owed; the payment layer decides how to return it. Keep those as two services so a policy change does not require touching payment code.

Unwind tax lines deliberately. When a stay is partly refunded, decide per line whether tax and fees reverse proportionally, in full, or not at all, and encode the rule. Given that some local fees are not refundable, a blanket proportional rule will sometimes be wrong.

Release holds explicitly. Do not rely on holds expiring on their own after checkout. One vendor guide says holds should usually be released soon after checkout when there are no extra charges; make the release an automated step triggered by folio closure so a guest does not see funds locked for days.

Log everything. Each refund needs who, when, why, which original payment, which currency and which rate. This is what your finance team and your acquirer will ask for in a dispute.

Reconciliation: the part nobody budgets for

Every payment moment above produces a record in at least two systems. Reconciliation is the process of proving they agree. Settlement files from your acquirer arrive net of fees, sometimes in a different currency from the booking, sometimes batched by day, sometimes by terminal. Matching them to folio lines manually does not scale past a handful of rooms.

Plan for automated matching from the start: a canonical transaction ID that travels from booking engine to PMS to gateway to ledger, tolerance rules for small FX or rounding differences, and an exceptions queue for the rest. Our article on reconciliation automation for payment platforms covers the patterns in detail, and they apply to hotels with only minor adjustment.

Restaurants and spas add volume and a different data shape. If your outlets run on a separate point-of-sale system, make sure room-charge postings and direct card payments both land in the same reconciliation pipeline. Our guide to restaurant and F&B management software integrating POS, inventory and reservations discusses how those systems connect.

Build, buy or integrate? A decision guide

Most properties should not build a payment gateway. The question is how much of the payments orchestration layer around it you build.

Buy or configure when: you operate one or a few properties, your PMS already integrates with a gateway that supports your acquirer in the UAE or Singapore, and your needs fit standard folio and refund flows.

Integrate when: you run a group with multiple PMS or booking engines and need a single view of payments, or you need to route different properties to different acquirers by market. An orchestration layer that sits between your systems and several gateways gives you consistent tokens, a unified refund API and one reconciliation feed.

Build when: your guest journey includes things off-the-shelf tools handle poorly, such as multi-property packages, loyalty payments, split settlement with partners, or bespoke deposit rules. Even then, you still buy the gateway and the acquiring; you build the logic around them.

If the tech stack behind this is ageing, the question may be broader than payments. Our article on cloud-native property management platforms and migrating from on-premise legacy systems looks at the larger migration, and the payments design is usually a good forcing function for it.

A vendor and build-partner checklist

Ask each candidate the following, and write down the answers.

1. Which entity is the merchant acquirer for my property, and what is its licensing status in the UAE or Singapore?
2. Which currencies can I settle in, and what is the settlement schedule for each?
3. Is DCC supported, and how is the guest's choice captured, displayed and stored?
4. How are incremental authorisations and hold expiries handled for long stays?
5. How do tokens work across my PMS, booking engine and CRM? Can I move to another provider and keep my stored cards?
6. What does a refund look like for a DCC transaction? In which currency, at which rate?
7. How does your system report tax and fee lines, and how are they configured when rules change?
8. What does the settlement file look like, and does it carry the identifiers I need for automated reconciliation?
9. Where is payment and personal data stored and processed, and what contractual commitments do you make about it?
10. What is your incident process if card data is exposed?

A vendor who answers all ten crisply is rare and worth keeping.

Common mistakes

• Treating DCC as a revenue switch and neglecting the disclosure and choice requirements.
• Hard-coding tax rates or fee amounts into integration code.
• Letting each channel (website, OTA, front desk) create its own payment record with no shared ID.
• Forgetting to release holds, then fielding calls from guests wondering where their money is.
• Storing card data in logs, email attachments or spreadsheets "just until the guest arrives".
• Assuming the refund currency matches the folio currency.

How Syslabs approaches this

At Syslabs we build custom software for hospitality and other sectors, including booking, integration and reporting layers around the systems a property already runs. For payments, the work is usually less about the gateway and more about the glue: API integration between booking engine, PMS and payment providers, tokenisation boundaries, folio and refund logic, and reconciliation feeds. If that is the part of your stack that needs attention, our API development and integration service and hospitality solutions pages outline what we do, and the booking engine and website kit shows one of the building blocks. Scope and cost depend on your systems and markets, so we scope that on a consultation rather than quoting from a page.

Conclusion

Good hotel payments design is mostly about respecting the lifecycle: a deposit, a hold, a settlement and, sometimes, a refund, each recorded once and reconciled automatically. In the Gulf and Singapore, the extras are currency choice done transparently, tax and fee lines driven by configuration, and a clear view of who is licensed to move your money. Get those right and the guest barely notices; get them wrong and finance, front desk and guests all do.

Book a conversation

If you are planning a payments redesign for UAE or Singapore properties, we are happy to talk through your current stack and what to change first. Book a meeting with Syslabs; the booking page shows times in your own time zone.

Sources

• Al Tamimi & Co., "Retail Payment Services and Card Schemes Regulation" (2021): https://www.tamimi.com/law-update-articles/retail-payment-services-and-card-schemes-regulation
• Adyen, "PCI compliance and tokenization for hotels": https://www.adyen.com/en_AE/knowledge-hub/pci-compliance-and-tokenization-for-hotels
• SmartHotel help guide, "Dynamic currency conversion": https://helpguide.smarthotel.nl/en/dcc
• SmartHotel help guide, "How long does an authorization last": https://helpguide.smarthotel.nl/en/how-long-does-an-authorization-last
• ChargeAutomation, "Hotel incidental hold": https://chargeautomation.com/hotel-incidental-hold-pre-authorization/
• Monetary Authority of Singapore, SGQR for merchant acquirers: https://www.mas.gov.sg/development/e-payments/sgqr/for-merchant-acquirers
• Stripe, "Payments in Singapore": https://stripe.com/en-fr/resources/more/payments-in-singapore
• Property Finder, "Tourism dirham fee": https://www.propertyfinder.ae/blog/tourism-dirham-fee/