#QUE Refund Policy
This Refund Policy page explains the information a customer needs to locate the operative refund terms. It is not an approval of a refund, a statement of a universal cooling-off period, or a substitute for the agreement and jurisdiction that govern a transaction. No public number, deadline, eligibility rule, credit, cancellation treatment, or payment-provider behavior should be published until Product, Finance, Legal, and the payment owner approve a versioned source.
The responsible goal is clarity: tell a customer what to check, what information to preserve, which route is monitored, and what remains dependent on the agreement or provider.
#Find the operative terms
Explain how to identify the agreement and version that controls. The customer should check the order, invoice, plan, deployment, jurisdiction, effective date, and any negotiated terms. QUE does not treat this page as a substitute for a monitored conversation, a signed agreement, professional legal advice, or a product support decision. The reader should use the section to identify the relevant question, record the context, and choose the next responsible action.
A useful review asks who owns the decision, what evidence is available, which dependency can change the result, what information may be shared, and when the statement should be reviewed. If the answer is not known, the page says so. This is deliberate: uncertainty that is visible can be managed, while certainty that has not been earned can mislead a team.
Questions to carry forward: Which agreement applies and what effective date is shown?.
#Cancellation is not automatically a refund
Explain the distinction between stopping future service and reversing a charge. The outcome depends on the approved terms, timing, payment state, taxes, credits, and provider records. QUE does not treat this page as a substitute for a monitored conversation, a signed agreement, professional legal advice, or a product support decision. The reader should use the section to identify the relevant question, record the context, and choose the next responsible action.
A useful review asks who owns the decision, what evidence is available, which dependency can change the result, what information may be shared, and when the statement should be reviewed. If the answer is not known, the page says so. This is deliberate: uncertainty that is visible can be managed, while certainty that has not been earned can mislead a team.
Questions to carry forward: What was cancelled, when, and which charge is being questioned?.
#Eligibility review
Describe a fair intake for a refund question. A request may require account identity, invoice reference, transaction date, reason, plan, and evidence of authorization. QUE does not treat this page as a substitute for a monitored conversation, a signed agreement, professional legal advice, or a product support decision. The reader should use the section to identify the relevant question, record the context, and choose the next responsible action.
A useful review asks who owns the decision, what evidence is available, which dependency can change the result, what information may be shared, and when the statement should be reviewed. If the answer is not known, the page says so. This is deliberate: uncertainty that is visible can be managed, while certainty that has not been earned can mislead a team.
Questions to carry forward: Is the requester authorized and is the transaction identifiable?.
#Payment-provider boundaries
Explain that QUE may not control every payment action. Provider settlement, disputes, card-network processes, taxes, and bank timing can affect the result. QUE does not treat this page as a substitute for a monitored conversation, a signed agreement, professional legal advice, or a product support decision. The reader should use the section to identify the relevant question, record the context, and choose the next responsible action.
A useful review asks who owns the decision, what evidence is available, which dependency can change the result, what information may be shared, and when the statement should be reviewed. If the answer is not known, the page says so. This is deliberate: uncertainty that is visible can be managed, while certainty that has not been earned can mislead a team.
Questions to carry forward: Which action is owned by QUE, Finance, or the payment provider?.
#Self-hosted and separate services
Explain that deployment responsibility can change the commercial surface. Self-hosted software, third-party services, implementation work, and separate support arrangements may have different terms. QUE does not treat this page as a substitute for a monitored conversation, a signed agreement, professional legal advice, or a product support decision. The reader should use the section to identify the relevant question, record the context, and choose the next responsible action.
A useful review asks who owns the decision, what evidence is available, which dependency can change the result, what information may be shared, and when the statement should be reviewed. If the answer is not known, the page says so. This is deliberate: uncertainty that is visible can be managed, while certainty that has not been earned can mislead a team.
Questions to carry forward: Which component or service is the subject of the request?.
#Credits and adjustments
Explain that a credit is not the same as a cash refund. Any credit, replacement, or adjustment must be approved and recorded under the applicable terms. QUE does not treat this page as a substitute for a monitored conversation, a signed agreement, professional legal advice, or a product support decision. The reader should use the section to identify the relevant question, record the context, and choose the next responsible action.
A useful review asks who owns the decision, what evidence is available, which dependency can change the result, what information may be shared, and when the statement should be reviewed. If the answer is not known, the page says so. This is deliberate: uncertainty that is visible can be managed, while certainty that has not been earned can mislead a team.
Questions to carry forward: What remedy was offered, under which authority, and with what expiry?.
#Evidence to retain
Give customers a safe recordkeeping checklist. Preserve invoices, confirmation messages, cancellation records, agreement versions, and relevant correspondence without sending secrets or private customer data. QUE does not treat this page as a substitute for a monitored conversation, a signed agreement, professional legal advice, or a product support decision. The reader should use the section to identify the relevant question, record the context, and choose the next responsible action.
A useful review asks who owns the decision, what evidence is available, which dependency can change the result, what information may be shared, and when the statement should be reviewed. If the answer is not known, the page says so. This is deliberate: uncertainty that is visible can be managed, while certainty that has not been earned can mislead a team.
Questions to carry forward: What evidence supports the request without exposing unrelated personal data?.
#Request route and states
Describe received, validating, under review, approved, declined, provider-pending, and closed states. The interface must not imply that a request was approved merely because a form was submitted. QUE does not treat this page as a substitute for a monitored conversation, a signed agreement, professional legal advice, or a product support decision. The reader should use the section to identify the relevant question, record the context, and choose the next responsible action.
A useful review asks who owns the decision, what evidence is available, which dependency can change the result, what information may be shared, and when the statement should be reviewed. If the answer is not known, the page says so. This is deliberate: uncertainty that is visible can be managed, while certainty that has not been earned can mislead a team.
Questions to carry forward: Which state is current and what is the next monitored action?.
#Timing language
Explain why exact timing requires approved operational inputs. Do not invent response, settlement, or bank-posting guarantees. Use the current approved service language. QUE does not treat this page as a substitute for a monitored conversation, a signed agreement, professional legal advice, or a product support decision. The reader should use the section to identify the relevant question, record the context, and choose the next responsible action.
A useful review asks who owns the decision, what evidence is available, which dependency can change the result, what information may be shared, and when the statement should be reviewed. If the answer is not known, the page says so. This is deliberate: uncertainty that is visible can be managed, while certainty that has not been earned can mislead a team.
Questions to carry forward: Who controls the next step and what dependency may affect timing?.
#Taxes and jurisdiction
Explain that tax treatment is not universal. Applicable taxes, invoices, exemptions, consumer rules, and jurisdictional rights require Legal and Finance review. QUE does not treat this page as a substitute for a monitored conversation, a signed agreement, professional legal advice, or a product support decision. The reader should use the section to identify the relevant question, record the context, and choose the next responsible action.
A useful review asks who owns the decision, what evidence is available, which dependency can change the result, what information may be shared, and when the statement should be reviewed. If the answer is not known, the page says so. This is deliberate: uncertainty that is visible can be managed, while certainty that has not been earned can mislead a team.
Questions to carry forward: Which jurisdiction and transaction document apply?.
#Fraud and account security
Explain why a refund channel must verify authorization. Do not share account details or payment information through an unverified route. Escalate suspicious activity to the approved security path. QUE does not treat this page as a substitute for a monitored conversation, a signed agreement, professional legal advice, or a product support decision. The reader should use the section to identify the relevant question, record the context, and choose the next responsible action.
A useful review asks who owns the decision, what evidence is available, which dependency can change the result, what information may be shared, and when the statement should be reviewed. If the answer is not known, the page says so. This is deliberate: uncertainty that is visible can be managed, while certainty that has not been earned can mislead a team.
Questions to carry forward: How is identity verified without exposing sensitive payment data?.
#Accessibility and plain language
Explain that policy decisions must be understandable. Use headings, definitions, keyboard access, contrast, text equivalents, and reduced-motion equivalence for the request experience. QUE does not treat this page as a substitute for a monitored conversation, a signed agreement, professional legal advice, or a product support decision. The reader should use the section to identify the relevant question, record the context, and choose the next responsible action.
A useful review asks who owns the decision, what evidence is available, which dependency can change the result, what information may be shared, and when the statement should be reviewed. If the answer is not known, the page says so. This is deliberate: uncertainty that is visible can be managed, while certainty that has not been earned can mislead a team.
Questions to carry forward: Can a customer understand the decision path without relying on color or animation?.
#Refund FAQ
#Are refunds guaranteed?
No universal guarantee should be stated here. Eligibility depends on the operative agreement, approved policy, transaction, jurisdiction, and review.
#Does cancellation automatically reverse a charge?
Not necessarily. Cancellation and refund are separate decisions.
#Where should a request go?
Use the monitored route identified in the operative agreement or /contact when that is the approved public path.
#What should I send?
Send only the minimum information needed to identify the transaction. Never send passwords, tokens, or full payment-card data.
#Who approves a refund?
The responsible commercial and finance process approves it under the applicable terms; a page submission alone is not approval.
#Legal and operational review gate
This draft remains legal-review until Product, Finance, Legal, payment ownership, jurisdiction, effective date, cancellation language, refund eligibility, processing language, and request routing are approved.
#Invoice-first review
Start with the invoice or transaction record, not an assumption about the plan. Confirm the entity, purchaser, service, period, currency, taxes, payment status, and agreement version. This prevents a refund conversation from mixing unrelated charges or accounts.
This section is designed to be used during a real review, not skimmed as promotional filler. Start with the smallest decision that must be made, name the person who can make it, and record the evidence that would change the decision. Then separate current product behavior from deployment configuration, provider behavior, organizational policy, and future direction. If a dependency is unavailable, the page should show the unavailable state and the safe fallback rather than implying that a best-effort attempt completed. A useful record includes the date, version, environment, owner, source, and next review date. It should not include credentials, payment-card data, private customer records, or unnecessary personal information. This approach helps the reader move from a broad question to a responsible next action while preserving tenant boundaries, consent, and auditability. The review should also ask: what transaction, agreement, authority, dependency, and evidence determine the next state?. If the answer depends on a signed agreement, a jurisdiction, an account state, or an approved provider inventory, link to that source instead of filling the gap with confident language. If the page is later updated, preserve the previous version and explain what changed. Readers deserve a stable way to understand whether the new text changes their decision, their responsibility, or only the presentation.
#Duplicate charge concern
A duplicate-looking charge may reflect a renewal, authorization, adjustment, separate workspace, tax, or provider presentation. The review should reconcile identifiers before promising a reversal. The customer should be told what evidence is needed and what is still being checked.
This section is designed to be used during a real review, not skimmed as promotional filler. Start with the smallest decision that must be made, name the person who can make it, and record the evidence that would change the decision. Then separate current product behavior from deployment configuration, provider behavior, organizational policy, and future direction. If a dependency is unavailable, the page should show the unavailable state and the safe fallback rather than implying that a best-effort attempt completed. A useful record includes the date, version, environment, owner, source, and next review date. It should not include credentials, payment-card data, private customer records, or unnecessary personal information. This approach helps the reader move from a broad question to a responsible next action while preserving tenant boundaries, consent, and auditability. The review should also ask: what transaction, agreement, authority, dependency, and evidence determine the next state?. If the answer depends on a signed agreement, a jurisdiction, an account state, or an approved provider inventory, link to that source instead of filling the gap with confident language. If the page is later updated, preserve the previous version and explain what changed. Readers deserve a stable way to understand whether the new text changes their decision, their responsibility, or only the presentation.
#Failed payment and partial service
A failed payment can create an account state that is different from a refund. The page should distinguish payment retry, account suspension, service access, provider settlement, and a dispute. Each state needs its own owner and record.
This section is designed to be used during a real review, not skimmed as promotional filler. Start with the smallest decision that must be made, name the person who can make it, and record the evidence that would change the decision. Then separate current product behavior from deployment configuration, provider behavior, organizational policy, and future direction. If a dependency is unavailable, the page should show the unavailable state and the safe fallback rather than implying that a best-effort attempt completed. A useful record includes the date, version, environment, owner, source, and next review date. It should not include credentials, payment-card data, private customer records, or unnecessary personal information. This approach helps the reader move from a broad question to a responsible next action while preserving tenant boundaries, consent, and auditability. The review should also ask: what transaction, agreement, authority, dependency, and evidence determine the next state?. If the answer depends on a signed agreement, a jurisdiction, an account state, or an approved provider inventory, link to that source instead of filling the gap with confident language. If the page is later updated, preserve the previous version and explain what changed. Readers deserve a stable way to understand whether the new text changes their decision, their responsibility, or only the presentation.
#Cancellation timing
Cancellation timing can affect future renewal, current access, credits, and eligibility. The applicable terms control. A page should not use a countdown, scarcity, or emotional pressure to influence a cancellation decision.
This section is designed to be used during a real review, not skimmed as promotional filler. Start with the smallest decision that must be made, name the person who can make it, and record the evidence that would change the decision. Then separate current product behavior from deployment configuration, provider behavior, organizational policy, and future direction. If a dependency is unavailable, the page should show the unavailable state and the safe fallback rather than implying that a best-effort attempt completed. A useful record includes the date, version, environment, owner, source, and next review date. It should not include credentials, payment-card data, private customer records, or unnecessary personal information. This approach helps the reader move from a broad question to a responsible next action while preserving tenant boundaries, consent, and auditability. The review should also ask: what transaction, agreement, authority, dependency, and evidence determine the next state?. If the answer depends on a signed agreement, a jurisdiction, an account state, or an approved provider inventory, link to that source instead of filling the gap with confident language. If the page is later updated, preserve the previous version and explain what changed. Readers deserve a stable way to understand whether the new text changes their decision, their responsibility, or only the presentation.
#Implementation work
Implementation, migration, advisory, or custom work may have terms separate from recurring product access. The policy should identify that possibility without publishing a rule that has not been approved for the actual commercial model.
This section is designed to be used during a real review, not skimmed as promotional filler. Start with the smallest decision that must be made, name the person who can make it, and record the evidence that would change the decision. Then separate current product behavior from deployment configuration, provider behavior, organizational policy, and future direction. If a dependency is unavailable, the page should show the unavailable state and the safe fallback rather than implying that a best-effort attempt completed. A useful record includes the date, version, environment, owner, source, and next review date. It should not include credentials, payment-card data, private customer records, or unnecessary personal information. This approach helps the reader move from a broad question to a responsible next action while preserving tenant boundaries, consent, and auditability. The review should also ask: what transaction, agreement, authority, dependency, and evidence determine the next state?. If the answer depends on a signed agreement, a jurisdiction, an account state, or an approved provider inventory, link to that source instead of filling the gap with confident language. If the page is later updated, preserve the previous version and explain what changed. Readers deserve a stable way to understand whether the new text changes their decision, their responsibility, or only the presentation.
#Provider dispute path
A card-network dispute or bank reversal is not the same as a direct refund request. The customer should be directed to the appropriate route and warned not to share full payment credentials. Finance and the payment owner determine the safe handling.
This section is designed to be used during a real review, not skimmed as promotional filler. Start with the smallest decision that must be made, name the person who can make it, and record the evidence that would change the decision. Then separate current product behavior from deployment configuration, provider behavior, organizational policy, and future direction. If a dependency is unavailable, the page should show the unavailable state and the safe fallback rather than implying that a best-effort attempt completed. A useful record includes the date, version, environment, owner, source, and next review date. It should not include credentials, payment-card data, private customer records, or unnecessary personal information. This approach helps the reader move from a broad question to a responsible next action while preserving tenant boundaries, consent, and auditability. The review should also ask: what transaction, agreement, authority, dependency, and evidence determine the next state?. If the answer depends on a signed agreement, a jurisdiction, an account state, or an approved provider inventory, link to that source instead of filling the gap with confident language. If the page is later updated, preserve the previous version and explain what changed. Readers deserve a stable way to understand whether the new text changes their decision, their responsibility, or only the presentation.
#Unauthorized transaction
An unauthorized transaction requires account and payment security handling. The public page should not ask for secrets or complete card numbers. It should provide the approved reporting route and preserve enough context for triage.
This section is designed to be used during a real review, not skimmed as promotional filler. Start with the smallest decision that must be made, name the person who can make it, and record the evidence that would change the decision. Then separate current product behavior from deployment configuration, provider behavior, organizational policy, and future direction. If a dependency is unavailable, the page should show the unavailable state and the safe fallback rather than implying that a best-effort attempt completed. A useful record includes the date, version, environment, owner, source, and next review date. It should not include credentials, payment-card data, private customer records, or unnecessary personal information. This approach helps the reader move from a broad question to a responsible next action while preserving tenant boundaries, consent, and auditability. The review should also ask: what transaction, agreement, authority, dependency, and evidence determine the next state?. If the answer depends on a signed agreement, a jurisdiction, an account state, or an approved provider inventory, link to that source instead of filling the gap with confident language. If the page is later updated, preserve the previous version and explain what changed. Readers deserve a stable way to understand whether the new text changes their decision, their responsibility, or only the presentation.
#Tax and exemption correction
Tax correction may require a valid exemption record, jurisdiction, invoice, and timing review. It may result in a corrected document rather than a refund. Finance and Legal must approve the language before publication.
This section is designed to be used during a real review, not skimmed as promotional filler. Start with the smallest decision that must be made, name the person who can make it, and record the evidence that would change the decision. Then separate current product behavior from deployment configuration, provider behavior, organizational policy, and future direction. If a dependency is unavailable, the page should show the unavailable state and the safe fallback rather than implying that a best-effort attempt completed. A useful record includes the date, version, environment, owner, source, and next review date. It should not include credentials, payment-card data, private customer records, or unnecessary personal information. This approach helps the reader move from a broad question to a responsible next action while preserving tenant boundaries, consent, and auditability. The review should also ask: what transaction, agreement, authority, dependency, and evidence determine the next state?. If the answer depends on a signed agreement, a jurisdiction, an account state, or an approved provider inventory, link to that source instead of filling the gap with confident language. If the page is later updated, preserve the previous version and explain what changed. Readers deserve a stable way to understand whether the new text changes their decision, their responsibility, or only the presentation.
#Credit versus refund
A credit can affect a future invoice while a refund can affect a payment instrument. The difference should be explicit, including any expiry, transferability, or accounting treatment that is actually approved.
This section is designed to be used during a real review, not skimmed as promotional filler. Start with the smallest decision that must be made, name the person who can make it, and record the evidence that would change the decision. Then separate current product behavior from deployment configuration, provider behavior, organizational policy, and future direction. If a dependency is unavailable, the page should show the unavailable state and the safe fallback rather than implying that a best-effort attempt completed. A useful record includes the date, version, environment, owner, source, and next review date. It should not include credentials, payment-card data, private customer records, or unnecessary personal information. This approach helps the reader move from a broad question to a responsible next action while preserving tenant boundaries, consent, and auditability. The review should also ask: what transaction, agreement, authority, dependency, and evidence determine the next state?. If the answer depends on a signed agreement, a jurisdiction, an account state, or an approved provider inventory, link to that source instead of filling the gap with confident language. If the page is later updated, preserve the previous version and explain what changed. Readers deserve a stable way to understand whether the new text changes their decision, their responsibility, or only the presentation.
#Decision communication
A decision should state whether it is approved, declined, pending evidence, pending provider action, or outside the current route. It should provide a reason at the appropriate level without exposing internal fraud signals or another person’s information.
This section is designed to be used during a real review, not skimmed as promotional filler. Start with the smallest decision that must be made, name the person who can make it, and record the evidence that would change the decision. Then separate current product behavior from deployment configuration, provider behavior, organizational policy, and future direction. If a dependency is unavailable, the page should show the unavailable state and the safe fallback rather than implying that a best-effort attempt completed. A useful record includes the date, version, environment, owner, source, and next review date. It should not include credentials, payment-card data, private customer records, or unnecessary personal information. This approach helps the reader move from a broad question to a responsible next action while preserving tenant boundaries, consent, and auditability. The review should also ask: what transaction, agreement, authority, dependency, and evidence determine the next state?. If the answer depends on a signed agreement, a jurisdiction, an account state, or an approved provider inventory, link to that source instead of filling the gap with confident language. If the page is later updated, preserve the previous version and explain what changed. Readers deserve a stable way to understand whether the new text changes their decision, their responsibility, or only the presentation.
#Appeal or reconsideration
If an appeal exists, the page should state the route, decision owner, new evidence allowed, and whether the review is final. If no appeal process is approved, do not invent one as a customer-friendly promise.
This section is designed to be used during a real review, not skimmed as promotional filler. Start with the smallest decision that must be made, name the person who can make it, and record the evidence that would change the decision. Then separate current product behavior from deployment configuration, provider behavior, organizational policy, and future direction. If a dependency is unavailable, the page should show the unavailable state and the safe fallback rather than implying that a best-effort attempt completed. A useful record includes the date, version, environment, owner, source, and next review date. It should not include credentials, payment-card data, private customer records, or unnecessary personal information. This approach helps the reader move from a broad question to a responsible next action while preserving tenant boundaries, consent, and auditability. The review should also ask: what transaction, agreement, authority, dependency, and evidence determine the next state?. If the answer depends on a signed agreement, a jurisdiction, an account state, or an approved provider inventory, link to that source instead of filling the gap with confident language. If the page is later updated, preserve the previous version and explain what changed. Readers deserve a stable way to understand whether the new text changes their decision, their responsibility, or only the presentation.
#Self-hosted economics
Self-hosted operators may incur infrastructure, provider, backup, observability, and support costs outside a product refund. The page should distinguish a product transaction from operating costs and avoid claiming that a refund reverses every dependent expense.
This section is designed to be used during a real review, not skimmed as promotional filler. Start with the smallest decision that must be made, name the person who can make it, and record the evidence that would change the decision. Then separate current product behavior from deployment configuration, provider behavior, organizational policy, and future direction. If a dependency is unavailable, the page should show the unavailable state and the safe fallback rather than implying that a best-effort attempt completed. A useful record includes the date, version, environment, owner, source, and next review date. It should not include credentials, payment-card data, private customer records, or unnecessary personal information. This approach helps the reader move from a broad question to a responsible next action while preserving tenant boundaries, consent, and auditability. The review should also ask: what transaction, agreement, authority, dependency, and evidence determine the next state?. If the answer depends on a signed agreement, a jurisdiction, an account state, or an approved provider inventory, link to that source instead of filling the gap with confident language. If the page is later updated, preserve the previous version and explain what changed. Readers deserve a stable way to understand whether the new text changes their decision, their responsibility, or only the presentation.
#Accessibility in policy decisions
Refund requests must remain understandable with keyboard access, clear labels, text error states, sufficient contrast, screen-reader semantics, and reduced-motion equivalence. A visual success animation cannot be the only confirmation.
This section is designed to be used during a real review, not skimmed as promotional filler. Start with the smallest decision that must be made, name the person who can make it, and record the evidence that would change the decision. Then separate current product behavior from deployment configuration, provider behavior, organizational policy, and future direction. If a dependency is unavailable, the page should show the unavailable state and the safe fallback rather than implying that a best-effort attempt completed. A useful record includes the date, version, environment, owner, source, and next review date. It should not include credentials, payment-card data, private customer records, or unnecessary personal information. This approach helps the reader move from a broad question to a responsible next action while preserving tenant boundaries, consent, and auditability. The review should also ask: what transaction, agreement, authority, dependency, and evidence determine the next state?. If the answer depends on a signed agreement, a jurisdiction, an account state, or an approved provider inventory, link to that source instead of filling the gap with confident language. If the page is later updated, preserve the previous version and explain what changed. Readers deserve a stable way to understand whether the new text changes their decision, their responsibility, or only the presentation.
#Refund maintenance
Finance owns commercial truth, Legal owns policy language, Product verifies the product route, Support owns monitored intake, and Security reviews suspicious activity paths. Each published version needs effective date, source, reviewer, and rollback plan.
This section is designed to be used during a real review, not skimmed as promotional filler. Start with the smallest decision that must be made, name the person who can make it, and record the evidence that would change the decision. Then separate current product behavior from deployment configuration, provider behavior, organizational policy, and future direction. If a dependency is unavailable, the page should show the unavailable state and the safe fallback rather than implying that a best-effort attempt completed. A useful record includes the date, version, environment, owner, source, and next review date. It should not include credentials, payment-card data, private customer records, or unnecessary personal information. This approach helps the reader move from a broad question to a responsible next action while preserving tenant boundaries, consent, and auditability. The review should also ask: what transaction, agreement, authority, dependency, and evidence determine the next state?. If the answer depends on a signed agreement, a jurisdiction, an account state, or an approved provider inventory, link to that source instead of filling the gap with confident language. If the page is later updated, preserve the previous version and explain what changed. Readers deserve a stable way to understand whether the new text changes their decision, their responsibility, or only the presentation.