How to Book a Hotel with Crypto in 2026

No major hotel booking site accepts cryptocurrency directly. Booking.com, Agoda, Expedia, Hotels.com and Trip.com all take ordinary cards, which means a card you fund with crypto books a hotel perfectly well. That part is straightforward and every article on this topic gets it right.

Here is the part almost none of them mention, and it is the thing that actually decides whether your booking survives.

A hotel reservation is not necessarily a payment. On a prepaid rate, the site charges your card the moment you confirm. On a "reserve now, pay at the property" rate -- which is the default on a large share of hotel inventory -- nothing is charged at booking at all. Your card is checked for validity, and the real charge lands at a front desk, weeks later, from an entirely different merchant. If you use a card you top up rather than one drawing on a bank balance, those are two completely different products, and the booking screen barely distinguishes them.

We can show you how real that split is, because we can see it in our own data. In the year to 9 September 2026, hotel spending on SolCard cards divided almost exactly in half: 945 distinct cards where a booking site collected the payment, and 819 distinct cards where the property billed directly -- across 1,694 different hotel names. Close to half the money never touches a booking site's payment system at all. And on Booking.com's pay-at-property reservations we can see the card check itself: a zero-amount authorization, which succeeds on our cards and moves no money.

This guide covers what each booking platform publishes about card payments, how pay-now and pay-later rates differ mechanically, what a year of real hotel spending on crypto-funded cards looks like, and -- honestly -- the one situation at a hotel where a virtual card is the wrong instrument.

Booking.com publishes this in its own developer documentation, in plainer language than anything on the consumer site. Every rate on the platform carries one of four payment timings:

Source: Booking.com's payments timings documentation, which also notes that pay_at_the_property "may include prepayment instalments before arrival, depending on policy".

Booking.com's guest-facing FAQ says the same thing far more tersely. Asked when payment is taken, its answer is: "It's up to the property and depends on your payment policy."

That single sentence is the whole problem. The search results page shows you a nightly rate and a total. It does not show you which of those four mechanisms you are about to enter. You have to open the rate and read the payment terms, and most people do not.

If nothing is charged, something still happens. Booking.com describes it directly:

And separately, on pre-authorization:

Two different mechanisms, and the distinction matters for a load-then-spend card. A validity check confirms the card exists and is live. A pre-authorization additionally reserves an amount against your available balance -- money you still have, but cannot spend elsewhere until it is released.

Marriott's own credit card policy page states the equivalent for direct bookings:

And, for the arrival itself:

That is the shape of the whole category. The card at booking secures the reservation. The card at check-in pays for it.

If you fund a card by topping it up, the booking date and the charge date are different problems. A prepaid rate is easy: fund the card, book, done. A pay-at-property rate books today and bills in three weeks. A card that was funded for the booking and then spent down on everything else is an empty card at the front desk.

Nothing about this is hostile to a crypto-funded card. It just moves the deadline, exactly the way Airbnb's split payments and Reserve Now Pay Later do. The fix is the same: note the charge date at checkout, and fund against that date rather than the booking date. A top-up settles in seconds. A cancelled reservation does not un-cancel.

Everything above is documented policy. This section is ours: anonymised, aggregated SolCard card transaction data covering settled consumer purchases in the 365 days to 9 September 2026.

The most useful thing in our own data is not a price. It is what Booking.com does to a card at reservation time on a pay-at-the-property booking: it asks whether the card is real, without taking any money.

A $0 authorization is a card check with no money attached. The issuer is asked "is this card real and live?" and answers without reserving anything. It succeeds on our cards, 74 times across 36 of them, and the separately-typed verification transactions succeed another 68 times across 19.

That is the mechanism most competing pages miss entirely. On a pay-at-the-property reservation, what the booking site does to your card is not a payment. It is a question. The payment happens later, somewhere else, under a different merchant name -- and that is the whole reason the next two findings matter.

Widening from Booking.com to all lodging, pre-authorization holds are visible as their own transaction state: 584 transactions sitting in an authorized state across 255 distinct cards (money reserved, not yet captured), and 126 Void releases across 84 cards (holds let go without ever being charged).

The practical consequence for anyone topping up a card is that a held amount is not a spendable amount, and the gap between hold and release is set by the property and your issuer, not by you. Keep a buffer.

This is the second finding, and it reframes the whole question of "which booking site works."

Direct-at-property is spread across 1,694 distinct merchant descriptors -- individual hotels, resorts, hostels and chain properties, each billing under its own name. Booking-site volume concentrates into a handful.

So close to half of hotel spending on these cards never touches a booking site's payment system at all. Which means "does Booking.com accept my card" answers only half the question. The other half is "does the property accept my card", and the property is a different merchant with different terms every single time.

One caveat on the top row: it includes Trip.com, whose descriptors cover flights and stays without distinguishing them, so read it as travel bookings weighted toward lodging rather than as lodging alone. The property-direct row is unaffected. More on that below.

These families are matched independently by descriptor, so the rows are not a clean partition of the two totals above -- treat them as relative scale, not as an arithmetic breakdown. Booking.com leads on breadth of cardholders.

One caveat we should state rather than bury: the Trip.com row is not a hotel figure. Trip.com sells flights as well as rooms, and its card descriptors do not distinguish the two -- they all read TRIP.COM with a city, whether the purchase was a seat or a stay. We checked; no split is available. So that row, and its contribution to the booking-site total above, includes an unknown share of air travel. Booking.com is separable because its flight bookings bill under distinct descriptors and those are excluded here. Read Trip.com as travel spend on an OTA that happens to sell rooms, not as a verified hotel-only number.

Of the 819 cards that paid a property directly, 165 did so through Apple Pay descriptors -- 680 transactions. That is roughly one in five cards, tapping a phone at a hotel rather than typing a card number into a booking form.

Apple Pay and Google Pay are Platinum-only on SolCard; the Virtual tier supports neither. If a phone tap at a check-in desk is part of how you plan to travel, that fact alone decides your tier -- we cover the setup in our guide to using Apple Pay with a crypto card.

The two entities bill differently, and the string on your statement is how you tell them apart.

Both Booking.com forms carry Amsterdam and a Netherlands country code, because that is where the billing entity sits -- not where you stayed. If you see a hotel's own name and city, the property took the money and the OTA was only ever the shop window.

This matters for reconciliation. A zero or near-zero line from HOTEL AT BOOKING.COM weeks before your trip is the card check; a four-figure line from a property name on check-out day is the stay. They belong to the same reservation and look nothing alike. Neither descriptor reveals your room, your dates, or who you travelled with -- a statement shows a merchant, not an itinerary.

Excluding card checks and settlement-correction rows (settled lodging charges of $2 or more):

Roughly four in ten lodging charges are under $100 -- one-night stays, hostels, deposits, and the property-side balance on a partly-prepaid rate. But 18% sit at $700 or more, and 7% clear $1,500. Those are the ones that make tier choice a real decision rather than a preference. The distribution skews smaller than the equivalent Airbnb one, which makes sense: a hotel booking is often a night or two, an Airbnb booking is often a week. For the wider picture of how travel compares to everything else people put on these cards, see our breakdown of what crypto card users actually buy.

We checked each platform's own published pages rather than repeating what other articles claim. The results are uneven, and we are going to be straight about where the gaps are.

Booking.com is the most explicit. Its guest FAQ states: "To make a reservation via Booking.com all hotels accept: Mastercard, Visa", and adds that "Some hotels also accept other credit cards for the actual payment of your stay; these cards are indicated during the booking process." It also notes that "Properties usually accept payment for a stay with a different card or cash" -- the card that holds the reservation and the card that pays for it do not have to be the same card. That is a genuinely useful degree of freedom almost nobody writes about.

Trip.com publishes the longest accepted list of the group. Its own payment-methods explainer states it accepts "major card providers, including Visa, JCB, MasterCard, UnionPay, American Express, Discover, and Diners Club International", alongside PayPal, Google Pay, Apple Pay, gift cards and Trip Coins.

Agoda, Expedia and Hotels.com do publish payment help, but their guest-facing help centres are rendered client-side and did not serve retrievable text when we checked on 9 September 2026. We are not going to quote a policy we could not read. What we can say is that all three sell both prepaid and pay-at-property rates -- Agoda brands its "Pay at hotel", the Expedia group "Pay Later" -- and that both behave the way the Booking.com timings table describes.

On prepaid and virtual cards specifically, none of these platforms publishes a guest-facing policy. Search Booking.com's partner documentation for "virtual card" and you get pages about virtual credit cards -- but read them and they are about how properties get paid by Booking.com, not what card a guest may use. Those are opposite ends of the transaction. Anyone quoting you a definitive rule about guest prepaid cards is quoting something the sites never wrote.

Rather than fill that gap with a guess, we will offer evidence: 7,322 settled lodging purchases in the year to 9 September 2026, on cards funded with crypto, split roughly evenly between OTA-collected and paid-at-the-property. That is not a policy claim. It is a large sample of payments that went through.

This is the section most pages selling you a crypto card leave out, so here it is plainly. Hotels routinely ask for a card at check-in to cover incidentals -- room service, minibar, parking, damage. Marriott states it directly: "You will be asked for your credit/debit card when you check in." That request is usually satisfied by handing a card across the desk.

SolCard's cards are virtual. There is no plastic to hand over. Where a front desk insists on physically presenting the card that will cover incidentals, a virtual card is the wrong instrument for that specific step, and we are not going to pretend otherwise.

What actually works around it, in practice:

• Add the card to Apple Pay or Google Pay on Platinum, and tap the phone at the desk. Our data says 165 cards already pay properties this way, and a contactless terminal does not care that there is no plastic.
• Book a prepaid rate. If the room is already paid, the check-in card is only covering incidentals -- a much smaller ask, and Booking.com notes that properties usually accept a different card or cash.
• Ask the property before you travel. Incidentals policy is set per property, not per booking site. It is a two-line email that converts an unknown into a known.
• Keep a live balance through check-out, because a hold needs something to land on and a released hold takes days to clear back.

Note what we are not claiming. We hold no data on why any individual payment behaves the way it does, and we will not invent any. What we have shown is that holds happen on these cards and get released. Whether a specific desk in a specific country will accept a phone tap for an incidentals deposit is a question for that desk.

Hotels are cross-border by definition, which makes FX matter more here than on a domestic subscription. Booking sites let you display prices in your own currency while the property prices the room in its local one -- that convenience is a conversion, and it has a rate. Then, separately, if the currency charged to your card differs from your card's billing currency, your issuer converts again on its own margin. Where the site offers it, pay in the property's currency to remove one of the two conversions; then care about your card's FX rate, because that is the layer you actually choose.

SolCard issues cards you top up with SOL, USDC or USDT across nine or more networks -- Solana, Ethereum, Base, BSC, Arbitrum, Polygon and Avalanche among them -- and the balance converts to fiat at the point of sale. A booking site sees a standard card payment on a network it already lists.

The top-up fee decides it on this merchant, not the cap. A 5% top-up on a $700 stay is $35, on a single trip -- three and a half times the one-time issuance fee. Lodging is high-ticket, and a percentage fee on the way in scales with the ticket in a way it simply does not for a $12 subscription. Apple Pay is the second difference, and a fifth of the cards that paid a property directly used a wallet -- a Platinum-only flow. The $5,000 cap is the third: a single $1,500 stay fits comfortably, but a two-week trip with the hotel, the transport and the food on one card starts to press against it.

Honest limitations, stated plainly:

• Neither tier ships as a physical card. For the incidentals step at a front desk, that is a real constraint -- see the section above.
• Virtual requires no identity verification; Platinum does. If the no-verification tier is why you are here, you are accepting the 5% top-up, the $5,000 cap and no wallet support as the price of it. On high-ticket travel that is an expensive trade.
• Neither tier is a credit product. You spend what you have loaded, which is exactly why the pay-at-property timing above matters so much here.
• A card does not override a platform's or a property's own country and currency rules. It changes what funds the payment, not where the payment is deemed to come from.

1. Get the card and top it up. Fund with SOL, USDC or USDT on whichever supported network is cheapest at the time. Our general guide to paying with crypto covers the mechanics.
2. Read the rate's payment terms before you compare prices. Prepaid, pay-later and pay-at-property rates for the same room are different products, and the price gap between them is often smaller than the difference in what your card has to do.
3. Fund against the charge date, not the booking date. On a prepaid rate those are the same day. On a pay-at-property rate they can be two months apart.
4. Load more than the room rate. Resort fees, city tax and breakfast are frequently excluded from the headline number and collected at the property.
5. Add the card at checkout, or on Platinum add it to Apple Pay or Google Pay first and select the wallet.
6. Screenshot the payment schedule -- the one screen showing the amount, currency and date of every charge at once.
7. Top up again before check-in. Even on a prepaid rate, expect the desk to want a card for incidentals, and expect a hold rather than a charge.
8. Keep a buffer through check-out. Releases take days, and held money is not spendable until they clear.

If you are arranging the rest of the trip on the same card, see our guides to booking flights with crypto and paying for Airbnb with crypto. Hotels sit inside our wider travel merchant guide, alongside the platform-specific pages for Booking.com and Agoda.

Not directly at any major booking site or hotel chain -- Booking.com, Agoda, Expedia, Hotels.com and Trip.com have no cryptocurrency option at checkout. The working route is a card funded with crypto that converts to fiat before the merchant is charged, so the booking site processes an ordinary card payment. Booking.com's own FAQ states that "all hotels accept: Mastercard, Visa" for making a reservation, which is exactly what a crypto-funded card presents as. In the year to 9 September 2026 we recorded 3,868 purchases billed directly by a property across 819 distinct cards, and 3,454 collected by a booking site across 945 cards -- a near-even split, with the booking-site side including some Trip.com volume that mixes flights and stays.

No. Booking.com has no crypto payment option -- no Bitcoin, no stablecoins, no wallet connection. It accepts Mastercard and Visa on every property, and per its FAQ "some hotels also accept other credit cards for the actual payment of your stay; these cards are indicated during the booking process." A card funded with crypto works because Booking.com never sees the crypto; it sees a card authorization.

Because it was a card check, not a payment. Booking.com describes it as contacting your card company "to confirm that the card you are using is valid", and on a pay-at-the-property rate the actual charge happens at check-in. In our own data we recorded 74 successful zero-amount authorizations across 36 cards and 68 successful verification-typed transactions across 19 more -- the card being tested, with no money attached. A zero or near-zero Booking.com line on your statement means the stay has not been paid for yet.

Separately, a small line can also be a settlement correction: when the final settled amount differs slightly from what was authorized, the provider posts the difference as its own row, labelled as a corrected settlement amount. That is an accounting adjustment on a charge you already made, not a new one.

It is which entity charges you and when. Booking.com's own developer documentation lists four timings on its inventory: charged at booking time, charged before the free cancellation period ends, charged at check-in, or charged at vehicle collection for car rentals. On a prepaid rate the booking site takes the money immediately. On a pay-at-the-property rate the site takes nothing and the hotel bills you weeks later under its own merchant name. For a card you top up manually, that difference is the whole planning problem -- the money has to be on the card on the charge date, not the booking date.

Frequently, yes. Booking.com defines a pre-authorization as "a temporary hold on an amount to ensure your card is valid and has sufficient funds", and Marriott states that "you will be asked for your credit/debit card when you check in." Across our lodging cohort we see 584 transactions in an authorized state across 255 distinct cards, and 126 void releases across 84 cards -- holds placed, and holds released. A held amount is reserved and not spendable until it clears, and the clearing time is set by the property and your issuer, so keep a buffer on the card through check-out.

This is the one place we will not tell you it always works. SolCard issues virtual cards, so there is no plastic to hand across a desk, and some properties will insist on physically presenting a card for the incidentals hold. What works in practice is adding the card to Apple Pay or Google Pay on the Platinum tier and tapping the phone -- 165 of the 819 cards that paid a property directly in our data did exactly that, across 680 transactions. Booking a prepaid rate also shrinks the problem, since the desk is then only covering incidentals, and Booking.com notes properties usually accept a different card or cash. Incidentals policy is set per property, so ask before you travel.

None of the major platforms publishes a guest-facing policy on prepaid or virtual cards. Booking.com's documentation about virtual credit cards is partner-facing -- it explains how properties get paid by Booking.com, not what card a guest may use, which is the opposite end of the transaction. Articles quoting a definitive rule are filling in a gap the platforms left blank. What we can offer instead of a policy claim is a large sample of settled payments: 3,454 booking-site-collected travel purchases across 945 distinct cards, and 3,868 property-direct lodging purchases across 819 cards, in the 365 days to 9 September 2026.

In our data the volume concentrates on Booking.com (1,696 transactions across 595 cards), followed by hotel chains billed direct (565 across 202), Agoda (433 across 100) and Expedia (228 across 120). Trip.com carries more volume still (1,084 across 255 cards), but its statement descriptors are the same for flights and stays, so we cannot present that as a hotel figure. Trip.com does publish the widest accepted-network list -- Visa, JCB, Mastercard, UnionPay, American Express, Discover and Diners Club International, plus PayPal, Apple Pay and Google Pay. The more useful selector is not the platform anyway, it is the rate type: a prepaid rate on any of them is the simplest flow for a card you top up manually.

Excluding card checks and settlement-correction rows, 39% of settled lodging charges were under $100, 24% fell between $100 and $299, 19% between $300 and $699, 11% between $700 and $1,499, and 7% were $1,500 or more. The large share under $100 reflects single nights, hostels, deposits and property-side balances on partly-prepaid rates. The 18% above $700 is where the 5% top-up fee on the Virtual tier becomes a real cost -- $35 or more on one trip -- and where the 0% top-up tier pays for itself immediately.

Two shapes, and the difference tells you who took the money. When Booking.com collects, you see BKG*HOTEL AT BOOKING.C Amsterdam NHNL or HOTEL AT BOOKING.COM Amsterdam NLD -- the Amsterdam reference is Booking.com's billing entity, not where you stayed. When the property collects, you see the hotel's own name and city; across our data that accounted for 1,694 distinct merchant descriptors. Two lines for one trip -- a tiny one weeks early and a large one on check-out day -- means the first was the card check and the second was the stay. Neither descriptor reveals your room, your dates, or who you travelled with.

Not on the Virtual tier, which requires none. The trade is that Virtual is Mastercard only, carries a 5% top-up fee and a $5,000 monthly cap, and supports neither Apple Pay nor Google Pay -- and that last point matters more on hotels than on most categories, because tapping a phone is the practical workaround for a front desk asking for a physical card. Platinum requires identity verification and gives you Visa or Mastercard, 0% top-up, no monthly cap, 0-1.5% FX, and both wallets. Neither tier charges an annual fee, and both charge $0.30 per transaction.