Payment Terms

These Payment Terms apply when a Guest pays for a Qembara Booking and when a Host receives or becomes entitled to a Payout. Additional provider terms may apply to a specific payment or payout method if clearly disclosed before that method is used. Mandatory law always prevails.

For transaction facts, the confirmed Listing and Booking Confirmation prevail. The Cancellation and Refund Policy determines cancellation and refund entitlement; the Standard Experience Contract Terms determine the Guest-Host service contract; these Payment Terms govern payment mechanics; the Guest Terms and Host Terms govern each user's separate relationship with Qembara. A payment-provider rule cannot silently reduce a Guest remedy or Host entitlement already granted by a higher-priority mandatory rule or transaction-specific commitment.

Qembara may use one or more appropriately authorised payment service providers. The provider may process card or alternative-payment credentials, perform verification and settlement, and impose scheme or network rules. Qembara will identify material third-party terms where required. Qembara does not claim to be a bank, stored-value facility, remittance business or regulated payment institution unless the applicable launch structure and law support that statement.

1.1 Acceptance and transaction versioning

A Guest accepts these Payment Terms through the affirmative checkout acceptance applicable to a Booking. A Host accepts them through Host onboarding or another expressly recorded Platform acceptance. Where additional provider terms require separate acceptance, Qembara will present them before the relevant payment or payout method is used. Qembara will retain the Payment Terms and provider-term version identifiers applicable to each transaction, together with the acceptance date/time and reasonably available audit evidence.

A later version will not retroactively reduce an accrued payment, Payout or refund right for a confirmed Booking unless mandatory law requires the change or the affected user expressly agrees through an authorised workflow.

Before the final payment action, Qembara will show the Total Price, each material price component, transaction currency, applicable cancellation setting and exact payment timing. The final action will clearly communicate that the Guest is creating an obligation to pay; optional purchases will not be pre-selected.

By confirming payment, the Booking Guest authorises Qembara and its designated payment provider to authorise and collect the amounts expressly shown at checkout using the selected Payment Method. This authorisation covers the confirmed Booking and any later amount the Guest separately accepts through a Qembara change or payment workflow. It does not create an unlimited authority to charge unrelated or disputed amounts.

Qembara will not charge a disputed damage claim solely because a Host requests it. A damage amount requires the Guest's separate authorisation or another lawful contractual basis after the disclosed claim process. Qembara will provide notice before any later charge that relies on an existing contractual mandate.

3.1 Payment method verification and security

Qembara or its payment provider may verify a Payment Method through authentication, a temporary authorisation, a nominal verification transaction, billing-data checks or another proportionate method permitted by law and payment-scheme rules. Temporary authorisations are not final charges and will be released or reversed according to the relevant provider or issuer process.

Guests must provide accurate payment information and use a Payment Method they are authorised to use. Qembara may request additional authentication, decline a Payment Method or require a different method where reasonably necessary for security, fraud prevention, sanctions or legal compliance.

3.2 Timing, Booking Requests and failed collection

A Booking Request may remain Pending while the Host accepts it and any required payment authorisation is obtained. Qembara may authorise the Payment Method before confirmation and capture after Host acceptance, or collect at another time if that timing is prominently disclosed before the Guest submits the Booking Request.

If a Booking Request is rejected, expires or cannot be confirmed, Qembara will promptly void or release any uncaptured authorisation and refund any amount already captured that is not lawfully due. The Guest's bank or payment provider may take additional time to display a released hold.

If a payment required for confirmation fails, the Booking is not confirmed unless Qembara expressly states otherwise. If an already-confirmed Booking has a later scheduled payment and collection fails, Qembara will notify the Guest, provide a reasonable cure route where operationally available, and may cancel only under the payment schedule and cancellation consequences disclosed when that schedule was selected.

Qembara will display the Total Price before payment and will not add a mandatory Booking charge after confirmation unless law requires it or the Guest expressly accepts a Booking change. A Host must not collect again an amount already collected through Qembara.

Qembara or the legally responsible party will provide the receipt, invoice or tax document required by applicable law. A receipt must not misstate the Host Amount as Qembara's own Experience revenue where Qembara is acting only as collection agent.

The Booking Confirmation records the transaction currency and the component amounts accepted at checkout. If Qembara offers a currency conversion, the Guest will see the converted amount and material conversion information before payment. If the Guest's Payment Method uses a different billing currency, the issuer or payment provider may apply its own exchange rate or fee.

Host Payouts may be offered only in supported payout currencies. If a Payout requires conversion, the Host will be shown the applicable conversion basis and any Qembara/provider charge before selecting or confirming that payout arrangement, where required.

A Guest-requested Booking change becomes binding only after the Host accepts it where required, the Guest is shown any price difference, and the Guest expressly accepts and pays any increase through the Platform. If the price decreases, Qembara will refund the difference under these Payment Terms and issue an updated Booking Confirmation.

A Host may not impose a new mandatory amount after confirmation. Optional additional services may be purchased only through an authorised Qembara workflow or another method expressly permitted and disclosed by Qembara. Off-platform payment requests that are not a disclosed exception may be treated as a safety, fraud or circumvention concern.

Where Qembara offers instalments or pay-later functionality, the checkout must state the amount, currency and due date of every scheduled payment, any additional fee, the Payment Method to be charged and the consequence of a failed instalment. Qembara will not launch such functionality merely by relying on this clause.

A Host must have a valid, supported Payout Method and provide accurate identity, business, beneficial-owner, bank and tax information reasonably required by Qembara, its payment provider or law. Qembara may hold a Payout while required verification is incomplete. Information will be handled under the Privacy Policy and applicable provider terms.

The Host is responsible for the accuracy of payout instructions it submits. Qembara will use reasonable controls for changes to sensitive payout details and may apply a security delay or additional verification after a material change where proportionate to fraud risk.

A Payout is conditional on successful Guest collection and is calculated from the Host Amount after authorised deductions. Qembara's settlement obligation after valid collection is separate from the Guest's discharged payment obligation. Valid payment of the Host Amount through Qembara or a Qembara-designated collection channel fully discharges the Guest's corresponding payment obligation to the Host. After valid receipt, the Host may not pursue the Guest merely because Qembara or its provider later fails to remit. The Guest becomes liable again only to the extent a reversal was caused or authorised by that Guest, or applicable law expressly permits recovery. A Host-caused reversal or delivery dispute may be allocated to the Host under these Payment Terms.

Subject to successful Guest collection and any lawful, proportionate hold, Qembara will ordinarily initiate the Host Payout by the end of the business day after the scheduled Experience starts. 'Initiate' means Qembara has released the Payout into the applicable payout process; it does not mean the Host has received cleared funds. Timing is measured in the local time at the Experience location unless the Host dashboard expressly states another operational cut-off. Any different schedule for a defined Host risk category must be proportionate, disclosed before it applies and consistent with applicable law.

Provider or bank settlement after Qembara initiates a Payout may take longer. The Host dashboard should distinguish 'scheduled', 'held', 'initiated', 'paid', 'failed/rejected' and 'adjusted' states so that initiation is not described as receipt.

Qembara may delay or withhold only the amount reasonably necessary for an evidenced refund, chargeback, fraud, safety, sanctions, tax, identity, legal, payment-provider or account risk. Qembara will release undisputed funds when they are no longer reasonably needed for that exposure and, where legally permitted, provide the Host a reason and status.

Qembara may use a proportionate rolling or transaction-specific reserve only if the Host was told the basis, calculation, duration/review basis and release conditions. A reserve must not be used to disguise an indefinite withholding of undisputed funds.

If a Payout fails or is rejected, Qembara will notify the Host through the account or registered contact route and provide a reasonable opportunity to correct the Payout Method. Reprocessing may be subject to provider rules and any lawfully disclosed third-party fee.

Refund entitlement is determined by the Cancellation and Refund Policy and mandatory law. These Payment Terms govern how an approved monetary refund is processed. Once Qembara determines that a Guest refund qualifies, Qembara will pay that refund without waiting to recover any Host-funded portion.

A full refund means 100% of the monetary amounts actually charged through Qembara for the affected Experience. This includes the Host Amount, associated Qembara Guest Service Fee, taxes and Experience-specific extras or third-party charges included in the Qembara checkout. An unrecoverable supplier, acquiring or payment-processing cost does not reduce a qualifying Guest-facing full refund.

A monetary refund is returned to the original Payment Method where reasonably possible. If that method cannot receive the refund, Qembara will use another lawful method after appropriate verification. Credit or rebooking does not replace money unless the Guest affirmatively chooses it after being told the monetary amount otherwise due.

Qembara will initiate an approved monetary refund within 2 business days after the cancellation is recorded or Qembara determines that the refund is due. 'Initiate' means Qembara has submitted the refund into the applicable payment process; the Guest's bank, wallet, card network or provider may take additional time to post it.

Bank, wallet, card-network or payment-provider posting time begins after initiation and may vary. Qembara will show an available status or reference number and a reasonable expected range where the provider supplies one. A settlement delay does not convert an approved monetary refund into credit.

Qembara uses the hybrid allocation already stated in the Host Terms and Cancellation and Refund Policy. The Host ordinarily funds the Host-side portion of a refund caused by Host cancellation, non-performance, a Host-responsible Material Issue, inaccurate Listing, Host breach or acts of Host personnel or suppliers. Qembara ordinarily funds its Guest Service Fee refund and a refund caused solely by its own Platform, payment-processing or support failure. Where both contributed, the internal burden is allocated reasonably by contribution and evidence.

Qembara may recover a properly allocated Host-funded amount by withholding an unpaid Payout, applying an agreed reserve, offsetting a future Payout, creating a negative Host balance or requesting direct repayment. Each adjustment must identify the Booking, reason, component amounts and calculation. Qembara will not reduce the Guest's approved refund because Host recovery is incomplete.

A Guest may have statutory or payment-scheme rights to dispute a transaction with an issuer or payment provider. Nothing here prevents a right that cannot lawfully be excluded. However, a Guest must not intentionally obtain duplicate recovery for the same amount through both a Qembara refund and a chargeback or other payment dispute.

A chargeback does not automatically prove Host fault. Qembara will allocate each economic component using the reason code, evidence of payment and delivery, the Cancellation and Refund Policy, responsibility for the disputed event, applicable law and payment-scheme rules. The disputed Host Amount may be allocated to the Host only to the extent supported by that assessment. Qembara ordinarily bears reversal of its Guest Service Fee unless Host conduct caused the dispute. A processor or card-scheme dispute fee may be allocated to the Host only under an expressly disclosed, reasonable rule and only where the Host is responsible for the dispute. A dispute caused by Qembara's processing error is not shifted to the Host merely because it relates to a Host Booking.

The Host must reasonably cooperate with evidence requests. Qembara may provisionally withhold the disputed Host Amount while a chargeback is open, but must distinguish a provisional hold from a final allocation and release any amount no longer reasonably exposed. Qembara will reconcile any prior or simultaneous Guest refund so the Guest does not receive duplicate recovery for the same component. Reversal after a Host Payout may be recovered only under section 11 and the final allocation must remain auditable at Booking/component level.

Qembara will take reasonable steps to correct payment-processing errors it identifies. A correction may include releasing an authorisation, refunding or collecting a shortfall with lawful authority, correcting a Host statement, or reversing a duplicate or erroneous Payout. Qembara will provide a reasonably intelligible transaction record.

If a Host receives a duplicate or erroneous Payout, the Host must notify Qembara and return the amount that was not due. Qembara may recover that amount using the authorised recovery methods in section 11 after notice. If a Guest is charged twice for the same amount, Qembara will promptly investigate and reverse the duplicate charge where confirmed.

Hosts remain responsible for identifying, registering for, reporting and paying taxes applicable to them or their Experiences except where law requires Qembara or a payment provider to collect, withhold, report or remit. Hosts must provide accurate tax information and required invoices or supporting records.

Qembara may collect, withhold, report or remit taxes when legally required and may provide information to tax or governmental authorities as required by law. Qembara will not describe a tax deduction as a Qembara fee. Where required, the Host statement or Guest receipt will identify the relevant tax treatment.

Guests and Hosts must not use Qembara payments for fraud, money laundering, sanctions evasion, unlawful transactions, cash advancement, artificial circular payments, unauthorised card use, misleading refund claims or other prohibited financial activity.

A Host must not request an undisclosed mandatory fee or ask a Guest to move a Booking payment off Qembara primarily to avoid Qembara's charges, records or safeguards. A limited offline amount is permitted only if Qembara expressly allows that category, the amount and recipient are prominently disclosed before checkout, and the collection method is lawful. Optional extras must follow the approved Qembara workflow where available.

Qembara or its payment provider may conduct proportionate identity, account-ownership, fraud, sanctions, restricted-transaction and other payment-compliance checks where required or reasonably permitted for lawful payment operations. A payment, Payout or Booking may be delayed, declined, restricted or cancelled when required by law, a competent authority, payment-scheme rules or an evidenced material risk.

Where legally permitted, Qembara will explain a material payment restriction at an appropriate level and provide a route to correct inaccurate information. Qembara may act urgently without advance notice where notice would undermine fraud prevention, safety, a lawful investigation or a legal restriction.

After Host account termination, Qembara will provide a final statement and release any undisputed Payout balance after authorised deductions and expiry of a lawful reserve or hold. Termination does not erase accrued refund, chargeback, fee, tax, negative-balance or correction obligations.

If Qembara cannot deliver a Payout because the Host does not maintain a valid Payout Method or does not respond to reasonable contact attempts, Qembara will handle the balance under applicable unclaimed-property, safeguarding, escheat or other law. These Terms do not authorise Qembara to keep a Host's undisputed balance merely because time has passed.

Payment and payout functionality depends on banks, card networks, wallets, processors and other third parties. Qembara does not guarantee that every Payment Method or Payout Method is available in every market. Qembara may add or remove methods for legal, security or operational reasons, but will not retroactively change the financial entitlement for a confirmed Booking solely because a method is withdrawn.

A third-party provider may impose its own transaction, bank-receipt or currency-conversion fee where lawful. Qembara will disclose a fee it controls before the user commits to it. A fee imposed independently by a user's bank or issuer may appear separately and is outside Qembara's control, subject to mandatory law.

Qembara will retain transaction records reasonably necessary to administer Bookings, payments, refunds, Payouts, chargebacks, tax duties, complaints and legal obligations in accordance with the Privacy Policy and applicable retention requirements. Users should review receipts and Host statements promptly and report an apparent error without unreasonable delay.

A payment complaint should identify the Booking reference, transaction, amount, date, requested outcome and relevant evidence. Do not send full card numbers, passwords, security codes or sensitive identity documents through ordinary email unless Qembara has specifically provided a secure route.

Qembara may update these Payment Terms prospectively for legal, regulatory, security, provider or product changes. A material change that increases an existing user's obligations or reduces rights will be notified before it takes effect where required. The version accepted or otherwise lawfully applicable to a confirmed Booking will be retained with the Booking record; Qembara will not use a later version to retroactively worsen a confirmed Booking's payment or refund position.

These Payment Terms do not exclude a payment-service, consumer, card-scheme, chargeback, refund or other right that applicable law does not permit the parties to exclude. Governing law and dispute provisions must be read with the Guest Terms or Host Terms applicable to the relevant user relationship and any mandatory forum or provider-specific regulatory route.