REFUND POLICY

1.1. This Policy defines:

• grounds for considering a refund;
• how to submit a refund request;
• information required to identify the payment;
• cases where a refund may be granted;
• cases where a refund may be denied;
• specifics of refunds for fiat and digital-asset payments.

1.3. Each refund request is decided taking into account:

• payment fact;
• access provision fact;
• scope and nature of service use;
• nature of the reported issue;
• information provided by the user;
• results of the Contractor’s internal review;
• this Policy and other service documents.

3.1. A request may be accepted for consideration if the refund relates to:

• objective technical inability to use the service as intended;
• access not confirmed or not reflected after a correctly completed payment;
• a material technical issue not resolved within a reasonable time;
• erroneous or duplicate payment confirmed during review;
• other exceptional circumstances the Contractor deems sufficient for a refund review.

3.2. Objective technical inability means, among others:

• access was not provided after confirmed payment;
• service infrastructure prevents using paid access as intended;
• the issue is confirmed and is not caused by the user, device, network, ISP, unsupported app, or other external factors.

4.1. Refund requests must be sent through official Contractor support channels:

• email: support@credovpn.ru;
• Telegram: @credovpnsupportbot;
• other official channels listed on credovpn.ru.

4.2. The refund request should include, as applicable:

• payment date;
• approximate payment time;
• amount;
• currency;
• payment method;
• plan name or paid period;
• reason for the request;
• payment proof;
• payment ID, invoice or order number, receipt, transaction hash, screenshot, or other identifiers.

4.3. For digital-asset payments, the user should additionally provide:

• asset type;
• network used;
• destination address if needed for verification;
• transaction hash;
• other data required to verify the transfer.

4.4. If the user does not provide enough data to identify the payment or verify the circumstances, the Contractor may:

• request additional information;
• suspend review until it is received;
• deny a refund if payment or circumstances cannot be confirmed.

5.1. After receiving a request, the Contractor may conduct an internal review, including:

• payment verification;
• access issuance verification;
• plan activation verification;
• service usage verification;
• subscription status verification;
• support ticket verification;
• technical logs for the website, bot, payment interface, and infrastructure as needed;
• analysis of materials provided by the user.

5.2. The Contractor may request clarifications, including:

• additional screenshots;
• description of steps taken;
• device, app, network, and error details;
• confirmation that the supported WireGuard app is used;
• payer identity confirmation if needed to prevent fraud or mistaken refunds.

6.1. A full or partial refund may be approved if the review finds, among others:

• payment confirmed but access was not actually provided;
• duplicate erroneous payment confirmed;
• material technical issue on the service side preventing intended use;
• wrong period or plan charged, or an error by the payment or internal system;
• other sufficient, documented circumstances recognized by the Contractor.

6.2. A full or partial refund may be made if the Contractor finds that:

• the service was not fully provided;
• the issue was temporary or partial;
• access was provided but a confirmed error existed in specific service parameters;
• part of the amount should be withheld due to actual access provided, costs, and fees.

7.1. The Contractor may fully or partially deny a refund if it is found that:

• access was provided and actually used;
• the issue was caused by user action, inaction, settings, or hardware;
• the user used an unsupported app instead of WireGuard;
• the issue was caused by device, OS, local network, ISP, corporate policy, antivirus, firewall, traffic filtering, or other external factors;
• the user entered wrong data, used the wrong network for digital assets, wrong address, wrong amount, or similar errors;
• the user did not provide information required for review;
• the request was filed after the stated deadline;
• abuse, bad-faith trial use, repeated unjustified requests, fraud, or attempts to obtain access and refund simultaneously;
• the user breached the Public Offer, Terms of Service, or other binding documents;
• access was limited or terminated for breach of use terms.

7.2. A refund may also be denied if the user relies only on circumstances unrelated to access quality, including:

• change of personal plans;
• no further need for the service;
• subjective dissatisfaction without a confirmed technical issue;
• misunderstanding of setup despite provided instructions and supported connection method.

9.1. If approved, refunds are made by a method the Contractor considers reasonable and technically feasible, including:

• refund to the same payment instrument;
• refund through the same payment service;
• refund to an alternative account agreed with the user if the original method is impossible;
• refund in the same digital asset if payment was in digital assets.

10.1. For digital-asset payments, including USDT, the user understands and accepts that:

• blockchain networks may charge fees;
• refunds may require additional review;
• asset rates may change;
• refunds may not be instant;
• refunds may involve extra costs.

10.2. If a refund is approved, the Contractor may:

• refund in the same digital asset;
• refund an amount equivalent to what the Contractor actually received;
• withhold network, intermediary, and crypto-processing fees and other actual costs;
• use another reasonable refund mechanism agreed with the user.

10.3. The Contractor is not liable for:

• user errors in wallet or network selection;
• blockchain delays;
• third-party fees;
• exchange-rate changes between payment and refund decision dates.

12.1. The Contractor may decide on a partial refund if:

• access was provided and partially used;
• part of the paid period was actually available;
• the issue was limited or temporary;
• part of the amount should be withheld for actual costs, fees, network charges, or confirmed service already rendered.

13.1. Additional review may be conducted if there are signs of:

• repeated unjustified demands;
• payment data inconsistencies;
• multiple accounts used to obtain trials;
• attempts to obtain a refund after actual use;
• payer impersonation or other abuse;
• payment disputes while continuing to use the service.

13.2. If abuse is suspected, the Contractor may:

• request more information;
• deny the refund;
• restrict access;
• suspend new service provision;
• take other reasonable steps to protect legitimate interests.