Original guide

Cloud hosting deals print a monthly price. Five billing rules decide the real bill

Answer first: The deal pages publish a monthly rate, a billing term and an upfront total, and nothing about how the money is actually collected. On the cloud hosting page the words PayPal, installment, currency and card appear zero times. On the pricing page the word payment appears once, and it describes an ecommerce plan's own store checkout rather than how the customer pays the provider. The provider meanwhile publishes 46 regional brands with different payment methods and different currencies, states that an account's currency is fixed at registration and that support cannot override it, publishes an installment option on only 4 of those 46 brands, charges the whole term upfront, and does not allow renewal periods to be stacked. A missed payment is not a suspension with a grace period: it puts the plan into Expired status for 30 days, and reactivating it restores website files and databases but not email accounts or their data.

Published: 2026-10-03 00:06

What this guide adds

Every figure and quotation on this page is taken from the pages listed under Sources, read on 3 October 2026. The counts of how often a word appears on the two deal pages, the count of regional brands, the number of brands publishing installments and the number listing crypto payments are derived by this site from those pages' own text. The per-brand payment methods, the currency rule, the installment terms, the upfront-charge rule, the non-stackable renewal rule and the 30-day expired-plan window are quoted from the provider's published pages. Where arithmetic is used it is labelled as derived in the sentence that uses it. Anything the provider does not publish is reported as unstated, never estimated.

What the deal pages print about paying, counted

The starting point is a word count, because it is the cleanest way to show what the deal pages leave out. On the cloud hosting page, the strings PayPal, installment, currency and card each appear zero times. On the pricing page, the same four strings appear zero times, and the word payment appears once.

That single mention is not about paying the provider at all. It sits inside the description of the ecommerce plan and reads that the plans include inventory management, multiple payment methods and 0% transaction fees. It is a feature of the store a customer might build on the hosting, not a statement about how the hosting is bought.

What the pages do print about money is the price and its boundaries. The pricing page carries the line Prices are listed without VAT in its footer. The cloud hosting page goes further and states that the price displayed is the monthly rate excluding applicable taxes, and that the total price for the plan to be paid upfront at checkout includes the monthly rate multiplied by the number of months in the plan, along with any applicable taxes.

So the deal page is precise about the size of the number and silent about the pipe it travels through. Which methods are accepted, in which currency, whether the amount can be split, when the money leaves the account and what happens if it does not are all answered somewhere else.

The payment rail is chosen by region, not by the plan

The provider's own payment-methods page opens by saying that the available payment methods and currency options vary depending on the brand where the services are purchased, and names Hostinger Global, Hostinger India and Hostinger France as examples. The page then lists the methods brand by brand. Counting the brand entries on that page gives 46.

Those 46 entries are not 46 variations on one list. Card networks differ: the global brand lists Visa, MasterCard, Amex, Discover, JCB, DinersClub and Maestro, while the Mexican brand lists Visa, MasterCard, Amex and Carnet, and the Brazilian brand adds Elo, HiperCard, Aura and Mercado Libre. Wallets differ too. Of the 46 brands, 41 list PayPal and 22 list Apple Pay. The global brand lists PayPal, Apple Pay, Google Pay and AliPay as its wallets.

The most widely repeated line on the page is crypto. 39 of the 46 brands carry the phrase Crypto payments. That is a derived count from the page's own entries, and it is worth stating plainly because a buyer comparing two deals will not find it on either deal page.

Two further rules sit in the notes at the top of the same page. Funds already in the Hostinger balance are automatically applied as a discount to the next invoice. And adding an eligible payment method to the account is what allows the services to renew automatically, which means the payment rail and the auto-renewal behaviour are the same decision.

The currency is decided once, at registration, and cannot be changed

This is the rule with the longest shadow. The provider states that it is not possible to change the currency of an existing Hostinger account, and that to use a different currency a customer must create a new Hostinger account using a different email address on the specific local brand website that supports that currency.

A dedicated support page explains why. The account currency is determined by the specific regional brand selected during initial registration, and that setting is permanent and cannot be altered once the account is created. Each regional brand operates as an independent legal and financial entity with its own localized pricing, tax structures and payment processors, so the currency cannot be changed or transferred to another regional billing system afterwards. The page is explicit that this is not a policy a human can waive: the currency is fixed at account creation and tied to the regional brand's billing system, and support agents cannot override the limitation.

The page offers four example mappings: the global brand bills in United States dollars, the Indian brand in Indian rupees, the Brazilian brand in Brazilian reals and the French brand in euros, and notes that the provider offers more than 40 regional locations. Local payment methods follow the same boundary. UPI is named as available on the Indian brand and PIX on the Brazilian brand, and the page warns that if a specific local payment method is unavailable after choosing the respective location, it may not be currently supported.

The practical consequence is that the currency is part of the purchase, not a display setting. A buyer who registers on one brand and later wants to be billed in another currency has one documented route: open a second account with a different email. The same page notes that if the old account holds active services it cannot be deleted, that domain names can be moved to the new account, and that other services can be refunded if eligible or else kept until they expire with auto-renewal disabled.

Installments exist on 4 of the 46 brands, and are hidden by default

Splitting the payment is possible, but only on a small slice of the map. Of the 46 brand entries on the payment-methods page, 4 publish an installment line: Argentina, Brazil, Colombia and Mexico. The installments page confirms the boundary from the other direction, stating that installment payments are available across several LATAM brands for purchases made with a credit card, and that the option is only available on the brands listed. PIX, Boleto and debit cards do not support installments, only credit cards do.

The published ceilings differ by brand: up to 12 months in Argentina and Brazil, up to 36 months in Colombia, and 3, 6, 9 or 12 months in Mexico. Every one of those four entries adds that availability and interest rates can depend on the buyer's bank.

The option is also not offered by default. The provider states that the installment option is not shown by default at checkout, and that a saved credit card must be deleted first, under the billing and payment-methods area of the dashboard, because the system otherwise defaults to charging the card in full. Automatic renewal must also be switched off, under the subscriptions area. Only then does choosing the other-payment-methods route at checkout and entering card details reveal the installment choices.

Two further conditions matter. Once a payment has been completed in full as a single charge it cannot be converted to installments afterwards, although support can open a request to reissue the invoice. And on interest the page is careful: the price shown on a plan page in the form of a monthly multiple reflects the provider's base charge split across that many months before any fees, the provider itself does not charge interest, and the buyer's financial institution may add interest on top, which is why the final per-installment amount can be slightly higher at checkout.

The monthly rate is not the amount charged

Three separate published statements say the headline figure is not the number that hits the card.

First, the upfront rule. The provider states that the full amount for the selected subscription period is charged upfront, and that longer billing cycles usually provide a lower average monthly price. The monthly figure is a division, not a schedule.

Second, the deal page's own caveat, already quoted above: the total to be paid upfront at checkout includes the monthly rate multiplied by the number of months, along with any applicable taxes, and the price displayed excludes those taxes.

Third, a support page written specifically for the mismatch. It lists the reasons a payment may reflect a different amount on the payment method than the cart or invoice showed, and the first reason it gives is paying in installments, where the financial institution's interest is added.

The dashboard invoice and the card statement are therefore two different documents by design. The provider's own installments page states that the dashboard invoice always shows the base price of the service, without the interest added by the financial institution, while the card invoice reflects the amount charged by the bank. The final amount, including all fees, is shown at checkout before the purchase is confirmed.

Renewal periods cannot be stacked, and only the first term carries the deal

Two rules decide the shape of the second payment. The provider states that subscriptions are paid upfront for the selected billing cycle, that renewing early extends the service from the current expiration date, and that renewal periods cannot be stacked beyond the next billing term, so multiple renewals cannot be combined into one accumulated period.

The available periods are published per product: one month, 12 months, 24 months or 48 months for web hosting, cloud hosting and business email; one month, 12 months or 24 months for KVM VPS hosting; one month for legacy OpenVZ VPS hosting; and one month or 12 months for Agency hosting. Domains have a minimum renewal period of one year, with some extensions allowing multi-year renewal up to two or three years depending on the registry.

The second rule is the one that decides the price of that second term. On the billing-cycle page the provider states plainly that all billing cycles after initial purchase are billed at regular rate. The promotional rate is a first-term rate. The same page also notes that switching from a monthly to a yearly hosting plan does not qualify for a free domain, and that when the billing cycle is changed as part of a hosting upgrade only the current billing period or 12 months can be selected. If a renewal invoice has already been issued it must be paid before the billing period can be modified, and if the service is manually renewed before its scheduled renewal date only the current billing cycle can be used.

One further restriction is easy to miss because it is about a legacy product: OpenVZ VPS plans support monthly billing only and cannot be changed.

What a missed payment actually does to the site and the mailboxes

The deal pages sell the purchase. The expired-plan page describes the failure, and its boundaries are narrower than a buyer might assume.

A plan that expires because of a missed payment shows an Expired status, and the provider states that it can be reactivated directly from the dashboard home page within 30 days of the expiration date. Renewing restores the websites, and the page confirms that websites created with the provider's AI builder are included in that restoration. Restoration typically takes between 30 minutes and a few hours, depending on the total size of the websites.

Email is the exception. The same page states that email accounts and their data are not included in this restoration process. A buyer whose deal bundles free mailboxes per website, and who lets a payment slip, should read that sentence twice: the websites come back and the mail does not.

There is also a closing door inside the 30 days. The option to download the most recent backup of files and databases is available only while the hosting plan is in Expired status, which lasts for 30 days following the expiration date. Once a hosting plan is fully cancelled after that 30-day window, backups are no longer available and the option no longer appears in the dashboard. The backup itself covers files and databases for HTML and PHP-based websites and does not include emails.

The practical reading is that the only published safety net is a 30-day window with a website-only restore. There is no published grace period before the Expired status begins, no published late-payment fee and no published guarantee that a mailbox can be recovered at all.

The comparison this leaves open

Putting the printed deal beside the published rail produces a small set of derived ratios and a larger set of blanks. The ratios are arithmetic on the counts above and are labelled as such.

Installments are published on 4 of 46 brands, or about 8.7%. Crypto payments appear on 39 of 46, or about 84.8%. PayPal appears on 41 of 46, or about 89.1%.

The reactivation window can be set against the term being sold. On the cloud hosting page the top plan is sold on a 48-month term. Taking four calendar years with one leap day as about 1,461 days, a 30-day reactivation window is roughly 2.05% of the term. A buyer is committing to a period about 49 times longer than the window in which a missed payment can be undone without losing the mailboxes.

The blanks are as important. The provider does not publish a per-plan payment-method list, so a buyer cannot know from the deal page whether the card in their wallet is accepted on the brand they are looking at. It does not publish whether installment options exist for the global dollar brand, and the four brands that do publish them are all regional. It does not publish a grace period between a failed charge and the Expired status. It does not publish the renewal price that will apply at the end of the term, only the rate that applies now and a statement that later cycles bill at regular rate. And it does not publish what happens to mailbox data after the 30-day window closes, beyond the statement that email is excluded from the restore.

None of that makes the deal dishonest. It does mean the deal page answers a narrower question than the one a buyer is asking. The page answers what the hosting costs. It does not answer what paying for it involves, and the difference only becomes visible on the second charge.

Sources and method

Ten provider-published pages were read for this article on 3 October 2026: the pricing page, the cloud hosting page, and eight support articles covering payment methods, installments, the billing cycle, renewal periods and advance payment, the permanent account currency, reactivating an expired plan, being charged a different amount, and managing payment methods. All ten returned HTTP 200 and all are permitted by the provider's robots.txt.

The word counts in the first section were produced by searching the served text of the two deal pages for each string. The brand count of 46 and the counts of 39 crypto, 41 PayPal, 22 Apple Pay and 4 installments were produced by counting the brand entries on the payment-methods page and checking which of them carry each line. No benchmark site was fetched for this article, and no figure here is estimated.

One limitation should be stated. The per-brand lists and the availability of a given local payment method change over time; the provider's own page carries an updated date, and the deal pages carry none. A buyer should treat the deal page's price as the part that is stable and the payment rail as the part that must be re-checked at checkout.