How does Strong Customer Authentication affect hotel deposits and later balance payments in Ireland?
A deposit can succeed while the balance fails weeks later. For Irish hotel teams, the practical question is who starts each payment, what the guest agreed to and how reception should respond when the bank requests another check.
Authenticating a deposit does not automatically authorise every later charge. Strong Customer Authentication (SCA) normally applies to in-scope electronic payments initiated by the guest, unless an exemption applies. A later hotel-initiated charge may fall outside SCA when supported by an appropriately authenticated mandate and the correct transaction setup. Agree the balance collection method with your payment service provider (PSP), and provide a guest authentication route if collection fails.
Separate authentication from permission to charge
SCA uses independent checks from at least two categories: something the guest knows, possesses or is. For online cards, 3D Secure is a common authentication mechanism. The Central Bank of Ireland’s PSD2 FAQ explains the Irish framework under the second Payment Services Directive (PSD2).
Start by distinguishing these payment routes:
- Guest pays now: the guest submits the deposit or balance through an online checkout. The bank may require authentication.
- Hotel charges later: a merchant-initiated transaction (MIT) uses an agreed mandate without the guest actively triggering that payment. Saving a card alone is insufficient.
- Guest returns to pay: a later payment link starts another guest-initiated payment. The original deposit’s authentication is not a blanket approval.
Stripe’s SCA guide distinguishes MITs outside SCA’s scope from exemptions requested for eligible transactions. Confirm classification and authentication with your own PSP; these are not universal hotel exemptions.
Deposit-to-balance decision table
Hypothetical example: a Galway hotel sells a €600 stay, including all quoted charges. Its agreed terms require a 25% deposit now and the balance seven days before arrival. The deposit is €600 × 25% = €150; the balance is €600 − €150 = €450. Assume no amendments, extras or refunds.
| Stage and decision | Guest action | Hotel action | PSP and issuer checks |
|---|---|---|---|
| 1. First payment: €150 | Review the terms, submit payment and complete any bank challenge. | Show the total, deposit and balance due date. Verify payment success before recording €150 received. | Handle authentication and payment authorisation separately; return the transaction reference and payment status. |
| 2. Automatic balance agreed? | Explicitly agree to the hotel collecting the later €450. | Retain the accepted terms and consent record. Without a valid setup, choose the guest payment route in row 4. | Confirm the mandate authentication, stored-card setup and references needed for subsequent MITs. |
| 3. Valid MIT setup: collect €450 | No new checkout action unless further authentication is requested. | Check the unchanged balance and due date. Submit through the approved workflow, then inspect the result. | Process the correctly classified transaction. The issuer may still decline it; return a usable reason. |
| 4. No MIT setup: request €450 | Open the secure checkout and complete payment and any authentication. | Send a balance request through the approved payment system. Keep €450 outstanding until success is confirmed. | Process the guest-initiated payment and apply the required authentication. |
| 5. Authentication fails or is required | Retry through the secure guest flow, contact the bank or use another accepted payment method. | Check for an existing successful charge first. Pause duplicate collection attempts, contact the guest and track the unpaid amount. | Distinguish authentication requirements from other declines; provide the appropriate recovery route. |
| 6. Payment confirmed | Receive confirmation of the amount paid. | Match the successful transaction to the reservation. After both payments, €150 + €450 = €600 and the balance is €0. | Supply the payment reference and subsequent settlement reporting. |
This is a suggested operating procedure, not a real customer case or a prescribed deposit policy. Agree status labels and recovery actions with your provider.
A successful identity check is not proof that money was collected. Verify the payment result separately. A card guarantee, authorisation hold, captured payment and bank payout represent different stages; reception should not treat them as interchangeable.
Keep the agreement and the payment evidence
Before enabling automatic balances, ask your PSP and software supplier to approve the proposed journey. Use this operational checklist:
- Record the named hotel, reservation reference, agreed deposit, remaining amount or calculation method, and collection date.
- Retain the version of the payment terms the guest accepted, acceptance timestamp and permission for later collection.
- Identify where authorised staff can retrieve the provider’s card token, initial authentication result, mandate reference and subsequent transaction references.
- Assign an owner for failed collections and guest follow-up. Recheck the balance after amendments, refunds or payments made through another channel.
Stripe’s saved-payment documentation illustrates consent requirements and recovery when a later charge needs authentication. It is a provider example, not evidence of a particular RoomRaccoon integration.
If a charge fails, read the reason before retrying. An authentication request, insufficient funds and an expired card need different responses. Ask the PSP which retries are permitted and how to prevent a scheduled charge duplicating a payment the guest completes separately.
Test the complete journey in RoomRaccoon
RoomRaccoon’s integrated hotel payments page describes payment links for deposits and balances, automatic charging, prepayment plans and 3D Secure. Its property management system (PMS) provides access to booking payment statuses.
Ask which features are included in your Irish account, which require activation or another plan, and which PSP supports your setup. Demonstrate the €150 deposit, the €450 collection, an authentication failure and a changed reservation. Confirm where consent and payment evidence can be retrieved.
Bring your deposit terms and balance schedule to a walkthrough of the payment journey.
Book a demo for your propertyHotel payment authentication FAQs
Does every payment need a visible bank challenge?
No. Eligible exemptions and other authentication flows can avoid a visible challenge. The hotel should rely on the provider’s recorded outcome, not whether the guest remembers entering a code.
Can we authenticate a card without taking a deposit?
Some providers support card setup for future payments without an immediate charge. Stripe documents this approach. Ask whether your configured payment service supports it and how it records consent and authentication.
Does successful authentication prevent later declines?
No. A subsequent payment may still fail or require the guest to return. Stripe’s SCA implementation guidance explicitly describes this possibility. Keep a supported recovery route available.
What if the guest changes the stay?
Recalculate the balance and check the accepted payment agreement before collection. If the change falls outside it, obtain updated consent and ask the PSP whether fresh authentication or a new setup is needed.
Sources and checks
Checked 13 November 2026. Irish regulatory context, provider documentation and RoomRaccoon product information. The example and checklist are practical applications; provider-specific settings require confirmation.
