Refund Policy

The refund policy is the document that sets out the operator’s stance on the return of monies paid by a subscriber to the operator under the OffshorePress service. The policy is published in plain editorial English in preference to the boilerplate register that the commercial-hosting industry has gravitated toward, on the view that a subscriber who is asked to part with money in advance of a service being rendered should be able to read the conditions under which the money will or will not be returned. The substantive content of the policy — the satisfaction window, the per-payment-method mechanics, the restocking deductions, and the cash-mail-in non-refundability rule — is binding on the operator and forms an integral part of the contractual terms set out at /legal/tos.

The drafting posture of this policy is conservative. The operator’s view is that the refund mechanics for a hosting service paid in cryptocurrency or in cash sit at an awkward intersection: the subscriber expects the same first-invoice satisfaction window that the commercial-hosting industry generally extends, but the underlying payment rails do not natively support the chargeback or reversal mechanics that the credit-card industry takes for granted. The policy below sets out the operator’s working answer to that intersection. Counsel review will confirm whether the drafting is sustainable as a matter of consumer-protection law in the operator’s filing jurisdiction or whether the operator should adjust the mechanics — particularly the cash-mail-in non-refundability rule — before commercial launch.

1. The seven-day first-invoice satisfaction window

The operator extends a seven-day, no-questions satisfaction window on the first invoice paid by a subscriber for a given service. The window opens on the date the operator marks the invoice as paid and runs for seven calendar days inclusive of the opening date. A subscriber who, within the window, decides that the service is not what the subscriber expected may request a refund of the first invoice and the operator will, subject to the per-payment-method mechanics in section 3 below and the restocking deduction in section 4 below, refund the invoice value in the original payment instrument.

1.1 Scope of the window

The seven-day window applies once per subscriber per service category. A subscriber who has previously held an account on the OffshorePress service in the relevant category and has previously exercised or had the opportunity to exercise the satisfaction window may not exercise the window a second time on a fresh signup in the same category; the operator’s view is that the satisfaction window is an opportunity to evaluate a service the subscriber has not previously seen, not a recurring instrument the subscriber may invoke at the start of every billing relationship. The category enumeration follows the product structure on the website: VPS, dedicated, email.

The seven-day window applies only to the first invoice paid by the subscriber for a given service. It does not apply to renewal invoices, to top-up invoices, to add-on invoices, or to any other invoice the operator issues to a subscriber whose first invoice has either been refunded or has expired its satisfaction window without a refund being requested. The renewal-invoice posture is set out in section 2 below.

1.2 The “no questions” character of the window

The operator does not require the subscriber to state a reason for the refund request inside the seven-day window. A subscriber who emails the operator at the contact form at /contact within the window stating only that the subscriber wishes to exercise the satisfaction window in respect of the relevant invoice has discharged the entirety of what the operator requires from the subscriber. The operator may, in the operator’s response, ask the subscriber whether the subscriber would like to share the reason for the request — both because the operator is genuinely interested in the answer and because the answer informs the operator’s product roadmap — but a subscriber who declines to answer the question loses no rights under this policy.

The “no questions” character of the window is a deliberate departure from the commercial-hosting industry’s general practice of requiring the subscriber to articulate a reason and then declining a meaningful subset of refund requests on the basis that the articulated reason does not meet the operator’s threshold. The operator’s view is that a subscriber whose threat model leads the subscriber to OffshorePress is a subscriber who values the operator’s not requiring an explanation; the satisfaction window is the moment in the contractual relationship where that valuation is most relevant.

2. Renewal invoices and beyond

The operator does not refund renewal invoices on a no-questions basis. A subscriber whose service has renewed and who wishes to terminate the renewal may do so under the cancellation procedure set out at /legal/tos section 9 and will retain access to the service through the end of the renewal period for which the invoice was paid. The operator does not pro-rate refunds on a mid-cycle cancellation; the renewal-invoice value is the subscriber’s commitment to the cycle.

The exception is a renewal invoice paid in error — for instance, where the subscriber had set out to cancel the service before the renewal but the cancellation request did not reach the operator before the renewal-invoice generation date because of a service-side fault on the operator’s part. A subscriber who can demonstrate, on the balance of the operator’s customer-support records, that the cancellation request preceded the renewal-invoice generation date and that the operator’s failure to action the request on time is the reason the renewal invoice was generated, has the renewal invoice refunded under the per-payment-method mechanics in section 3 below.

A renewal invoice paid for a service the operator subsequently suspends or terminates under the contractual terms or the acceptable use policy is not refundable. The remedy for an erroneous suspension or termination is the credit-and-restoration mechanic at /legal/tos section 8.1.3, not a refund under this policy.

3. Per-payment-method refund mechanics

The mechanics of the refund depend on the payment instrument the subscriber used for the original invoice. The four payment routes the operator accepts are documented on /payments; the refund mechanics for each are set out below.

3.1 Monero (XMR)

A refund of an invoice paid in Monero is paid in Monero to a subscriber-supplied subaddress. The subscriber emails the operator the Monero subaddress to which the refund is to be paid and the operator initiates the refund transaction from the operator’s self-hosted Monero node within five business days of confirming the refund. The refund value in Monero is computed against the USD-equivalent of the original invoice on the date the refund is computed, using the median of three reference rates (Kraken, Bitfinex, the operator’s own node-internal CoinGecko snapshot) as the conversion source. The conversion-time methodology is set out in section 5 below.

The subscriber bears the network-transaction-fee cost of the refund, which the operator deducts from the refunded amount. The Monero network fee at the time of writing is a fraction of one US cent and the deduction is, in practice, a rounding artefact rather than a material reduction.

3.2 Bitcoin Lightning (BTC-LN)

A refund of an invoice paid via Bitcoin Lightning is paid to a subscriber-supplied Lightning invoice. The subscriber emails the operator a Lightning invoice with a memo identifying the refund and a payable amount in satoshis equal to the refund value computed under section 5 below; the operator settles the invoice from the operator’s self-hosted node within three business days. Lightning’s atomic-routing semantics make the refund either complete or undone — the subscriber either receives the full refund value or the operator’s payment fails and the operator retries with the subscriber.

A subscriber who cannot supply a Lightning invoice with sufficient inbound liquidity may request a fallback to on-chain Bitcoin under section 3.3 below. The fallback adds the on-chain network-transaction-fee cost to the deduction; the operator does not double-charge the subscriber for the fee that the original Lightning rail had avoided.

3.3 Bitcoin (on-chain)

A refund of an invoice paid in on-chain Bitcoin is paid to a subscriber-supplied receiving address from the operator’s self-hosted BTCPay Server. The operator initiates the refund transaction within five business days of confirming the refund. The subscriber bears the on-chain network-transaction-fee cost of the refund, which the operator deducts from the refunded amount.

The operator broadcasts the refund transaction at the prevailing fee rate for confirmation within the next six on-chain blocks (approximately one hour) and does not commit to a specific fee rate. A subscriber who requires a faster confirmation may request the operator’s accelerated-fee posture; the operator will, at its discretion and against the additional fee cost, broadcast at a rate intended for next-block confirmation.

3.4 Cash mail-in (non-refundable)

The operator does not refund invoices paid by cash mail-in. The cash-mail-in route is documented on /payments/cash-mail-in as the lowest-metadata payment route the operator offers; the operator’s posture is that the route is honest about the trade-offs involved, and one of those trade-offs is that the operator does not undertake the inverse mechanic of mailing banknotes back to a subscriber.

The operator’s reasoning is two-fold. First, the inverse mechanic is operationally fragile: a sealed envelope containing cash sent through a postal service is, on average, vulnerable to loss or theft in transit; the operator is not willing to assume that risk on the subscriber’s behalf in a refund posture. Second, the reverse direction would require the operator either to retain the subscriber’s mailing address (which contradicts the operator’s broader minimisation posture on subscriber data) or to accept a fresh mailing address from the subscriber as part of the refund request (which the operator considers a signal-degrading interaction with what should be an exit conversation).

A subscriber who wishes to retain the option of a satisfaction-window refund should select Monero, Bitcoin Lightning, or on-chain Bitcoin as the payment instrument for the first invoice. The cash-mail-in route is best suited to subscribers whose threat model is incompatible with any of the cryptocurrency rails and who are prepared to accept the non-refundability rule as the consequence of the trade-off. The route’s non-refundability is restated on /payments/cash-mail-in and on the checkout confirmation; a subscriber who proceeds with cash mail-in is taken to have read both surfacings and to have accepted the rule.

A subscriber whose cash-mail-in payment is mis-applied to the wrong account on the operator’s side — for instance, where the operator’s intake operator credits the payment to the wrong subscriber’s account — has the operator’s intake-correction mechanic available rather than a refund. The intake-correction mechanic moves the payment to the correct account; it does not refund the cash.

4. Restocking deductions

The operator deducts a restocking fee from a refunded invoice in respect of the operational cost of the provisioning, the carrier-circuit allocation, and the subscriber-onboarding work the operator has performed before the refund request reached the operator. The restocking fee structure is tiered and is set out below.

Tier	Restocking fee	Applies to
Standard	$5 USD-equivalent per service	Standard-tier VPS plans (VPS-1 through VPS-4), entry dedicated machines (DS-LITE), standard email plans (Mail-1 through Mail-4)
Pro	$15 USD-equivalent per service	Higher-specification VPS (VPS-8 through VPS-16), Pro dedicated machines (DS-PRO, DS-BEAST), unlimited email (Mail-Unlimited)

The placeholder caveat: the precise tier composition and the precise restocking-fee values are pending counsel review. The values above are the operator’s working numbers and reflect the operator’s estimate of the marginal cost of an aborted onboarding; counsel review will confirm whether the values are sustainable as a matter of consumer-protection law in the operator’s filing jurisdiction or whether the operator should adjust the values — including, potentially, to zero — before commercial launch.

The restocking fee is denominated in USD and is converted to the refunded payment instrument’s unit at the same conversion-time rate the operator applies to the refund value itself, per section 5 below. The fee is deducted from the refund before the network-transaction-fee deduction, so a subscriber whose first invoice was $30 USD-equivalent on a standard-tier service receives a refund of $25 USD-equivalent (less the cryptocurrency network fee).

5. Conversion-time methodology

A refund of an invoice paid in cryptocurrency is computed in USD-equivalent and converted to the cryptocurrency at the conversion-time rate. The conversion-time rate is the median of three reference rates sampled at the moment the operator computes the refund: the spot rate at Kraken, the spot rate at Bitfinex, and the operator’s own self-hosted CoinGecko snapshot. The median of the three is the operator’s working rate; a subscriber who disputes the rate may request the operator’s per-refund snapshot record, which the operator retains for ninety days from the refund date.

The conversion-time methodology is asymmetric in the subscriber’s favour for short-window refunds: a subscriber whose original invoice was paid on a date when the cryptocurrency was lower against USD than at the refund-computation date receives a refund of fewer cryptocurrency units than the original invoice; a subscriber whose original invoice was paid when the cryptocurrency was higher against USD receives more units. The operator’s view is that the USD-equivalent benchmark is the honest reference for a refund of a service whose price-list is denominated in USD; the alternative benchmark — refunding the same number of units the subscriber paid — would systematically advantage one side or the other depending on the cryptocurrency’s drift over the seven-day window, and the operator considers the USD-equivalent benchmark the fairer compromise.

The conversion-time methodology does not apply to the cash-mail-in route, which is not refunded under this policy.

6. Refund processing time

The operator processes a refund within five business days of confirming the refund (three business days for the Lightning route). The five-business-day window covers the operator’s internal confirmation, the operator’s instruction to the relevant payment node to initiate the transaction, and the broadcast of the transaction to the underlying network. The window does not cover the network’s confirmation time, which the subscriber’s wallet observes independently of the operator.

A subscriber whose refund has not been initiated within the relevant window may escalate the matter to the contact form at /contact for review. The operator’s review will identify whether the delay is operational (in which case the operator will expedite the initiation) or substantive (in which case the operator will explain the operator’s substantive concern and the subscriber may continue to pursue the matter under section 7 below).

7. Disputes

A subscriber who disagrees with the operator’s response to a refund request may escalate the matter to the contact form at /contact for review by the operator’s senior operations officer. The escalation review is conducted on the documentary record — the original invoice, the refund request, the operator’s initial response, and any supporting material the subscriber wishes to submit — and the operator’s senior officer issues a written decision within ten business days of receipt.

A subscriber who disagrees with the senior officer’s decision may pursue the matter in accordance with the dispute-resolution and governing-law provisions of the contractual terms at /legal/tos sections 13 and 14. The operator’s review under this section is not a precondition for the subscriber’s pursuit of the matter under those provisions; a subscriber who prefers to skip the operator’s review may proceed directly to the contractual dispute-resolution mechanic.

8. Modifications

The operator may modify this policy at any time by publishing a revised version. The revised version takes effect on the effective-from date stated in its frontmatter; the operator will, where reasonably practicable, give notice of a material modification to existing subscribers by email at least thirty days before the effective-from date. A revised policy applies to refund requests submitted on or after its effective-from date; a refund request submitted before the effective-from date is processed under the policy that was in force on the date of submission.

A subscriber who disagrees with a material modification to this policy may exercise the contractual termination right at /legal/tos section 9 and is, in the satisfaction-window context only, treated as having exercised the satisfaction window in respect of any first invoice on which the window has not already expired.

9. Operator contact

Refund requests, refund-status enquiries, and questions about this policy are routed to the contact form at /contact. The mailbox is monitored by the operator’s small team and is the same mailbox that handles general legal correspondence under section 1 of the legal hub at /legal; a subscriber who is uncertain whether the question is properly a refund question or a contractual question may safely send the question to the contact form at /contact and the operator will route the question internally.