Refund Policy

1. Scope of this policy

This Refund Policy applies to paid Drecha purchases recorded in the product ledger, including balance purchases and direct feature purchases where refund requests are currently supported. It should be read together with the Drecha Terms and Conditions. By making a purchase, you agree to this refund framework.

Drecha does not currently use an automatic “refund whole account wallet” flow. Refund handling is attached to individual recorded purchases. The app evaluates refund eligibility at purchase level, not as an unrestricted right to withdraw account value.

2. Which purchases can be requested

Current in-product refund flow is limited to paid purchase records that are still inside the refund window and are not already blocked by an open refund request. In technical terms, the purchase must be recorded as paid, must have a positive paid amount, and must not be a test purchase, grant, or prior refund payout entry.

Drecha currently uses a 14-day refund window for supported purchases. The app calculates that window from the purchase processing time stored on the purchase record. When that window expires, the purchase is no longer requestable through the product flow.

3. Current request scope is full purchase only

Current Drecha refund flow does not support customer-selected partial refund amounts. Refund requests are tied to whole eligible purchase records. In practice, you request a refund for a specific purchase row, and the app reserves that purchase amount according to the rules below.

For ordinary balance purchases, the purchase must still be fully backed by the workspace’s currently refundable paid balance at request time. If that purchase amount has already been consumed by feature charges or other refundable-balance reductions, the app will reject a full refund request for that purchase.

4. What happens when you submit a request

When a refund request is submitted, Drecha does not send money automatically. The request first enters a reserved state. That means the requested amount is held out of refundable balance calculations while the request waits for review.

For ordinary balance purchases, that reservation immediately reduces the amount that the workspace can still treat as refundable paid balance. For feature purchases, the request is still attached to the purchase, but the feature purchase keeps counting toward access while the request remains reserved.

5. Current refund statuses

Current product flow uses five request states: reserved, approved, refunded, denied, and canceled.

Reserved means request was submitted and is still waiting for review. Workspace owner may cancel only while request remains reserved. Approved means Drecha accepted request in principle, but payout is not yet marked complete. Refunded means manual payout was completed and recorded in the product. Denied means request was rejected. Canceled means workspace owner canceled a still-reserved request.

6. Approved does not mean paid out yet

Current Drecha flow separates approval from payout completion. When an admin approves a request, the request stays reserved until the payout is actually handled and the request is marked as refunded. Approval alone does not release the reservation and does not mean money already moved.

This is important because Drecha currently tracks refund completion as an explicit later step. Refund handling is therefore an operational review-and-complete flow, not an instant self-serve auto-refund inside the app.

7. Balance purchases and feature purchases behave differently

For ordinary balance purchases, marking a request as refunded records a negative refund payout entry in the Drecha purchase ledger. That payout does not restore spendable balance. It records that the reserved amount has now been handled as a refund.

For feature purchases, submitting or approving a request does not remove access immediately. A feature purchase stops counting toward access only after the request reaches refunded. If another non-refunded purchase still covers the relevant period, access may continue even after one purchase is refunded.

8. What is not refundable

The following are not eligible for ordinary in-product refund handling unless we explicitly agree otherwise in writing: test purchases, grants, promotional credits, manual admin crediting, prior refund payout entries, already-refunded purchases, and purchases outside the refund window.

We may also deny requests where the paid purchase has already been consumed under current product rules, where fraud or abuse is suspected, where a payment dispute or chargeback is already open, or where legal or payment-processing restrictions prevent the requested outcome.

9. How to request a refund

Use refund actions inside Drecha purchase history or refund area. Current flow is purchase-based. If you request from a specific purchase row, Drecha evaluates that exact purchase. If you use general refund action, Drecha currently selects an eligible purchase record under the same rules rather than opening a custom amount field.

Submitting a request does not guarantee approval. Each request is still reviewed against purchase status, refund window, available unused paid balance where relevant, feature coverage effects, and fraud or compliance constraints. You may cancel only while request remains in reserved state. After approval, request is no longer self-cancelable through the current product flow.

10. Manual payout handling

Current Drecha implementation does not promise an automatic refund back through a payment provider at request submission time. Refund completion is recorded only when Drecha marks request as refunded after operational handling. Depending on payment method and operational constraints, payout may be processed manually or through the original provider outside the customer-facing Drecha UI.

Because product currently separates request state from payout completion, you should not assume that a submitted or approved request has already returned funds until it is actually finalized as refunded.

11. Changes to this policy

We may update this Refund Policy as the product evolves, as refund mechanics change, or as legal requirements change. When we do, we may revise this page and update the “last updated” date. The version in effect at the time of purchase and refund handling may affect how a request is reviewed, subject to applicable law.