Flash Gen · Refund Policy · v1.0 · effective 21 July 2026
| Field | Value |
| Operator | ARIES ACCESSIBILITY LTD |
| Company number | 15588986 |
| Registered office | 20 Wenlock Road, London, England, N1 7GU |
| Trading name / brand | Flash Gen |
| Website | https://flash-gen.com |
| Contact email | info@flash-gen.com |
| Support / complaints | info@flash-gen.com |
| Governing law | England and Wales |
| Document version | v1.0 |
| Effective date | 21 July 2026 |
| Important: Digital Content and Tokens are generally non-refundable after delivery or consumption, but this does not affect statutory rights or remedies for non-delivery, technical defects, duplicate or unauthorised charges, or a Verified Platform Failure that produces no usable output. |
1. Introduction and scope
1.1 The controlling rule is as follows: This Policy applies to one-off purchases of Token Packs, pre-generated image Content and generation services. It explains commercial refund rules, statutory remedies, evidence requirements, decision times and interaction with card disputes.
1.2 For introduction and scope, support compares the order, payment status, Token ledger, job result, output access and communications. The evidence is used to distinguish non-delivery, defect, user error, platform failure and disputed use.
1.3 Mandatory consumer, privacy and payment rights continue to apply to introduction and scope; this Policy cannot be used to waive a protection that the law makes non-excludable.
2. Company details and contact
2.1 For the Flash Gen service, Refund requests are handled by ARIES ACCESSIBILITY LTD through info@flash-gen.com. The request should be sent from the Account email and include the order and generation-job references.
2.2 The remedy for company details and contact is selected to correct the verified problem without producing duplicate value. Re-delivery, Token restoration or price reduction may be more direct than a cash refund, depending on the legal remedy required.
2.3 A user may ask support to review a material outcome concerning company details and contact. Review can confirm the result, correct an error, narrow a restriction or identify the proper statutory process.
3. General position on digital-content refunds
3.1 This section allocates responsibility clearly. Once Tokens are credited, Content is made available or a generation job produces usable output, the purchase is normally final because digital supply has begun. Exceptions remain available where law or this Policy requires a remedy.
3.2 A decision concerning general position on digital-content refunds states the principal evidence, outcome and next step. Material new information may justify reopening the case rather than requiring a separate complaint.
4. Transactions that may qualify
4.1 The Account and transaction outcome follows this position: A remedy may apply for non-delivery, incorrect Token credit, duplicate billing, an unauthorised transaction, corrupted or inaccessible purchased Content, a material description mismatch, or a Verified Platform Failure producing no usable output.
4.2 Where transactions that may qualify depends on a payment provider or issuer, Flash Gen records the instruction date and reference. The provider or issuer controls when a released hold or refund becomes visible to the user.
4.3 Reasonable verification may be required for transactions that may qualify, especially where value, Account control or sensitive data is involved. Verification is proportionate to the risk and information requested.
5. Transactions normally not eligible
5.1 To keep the Service predictable, Refunds are normally unavailable for change of mind after immediate supply consent, dissatisfaction with subjective style, unused Tokens after voluntary closure, prompts that breach policy, user-device incompatibility, third-party rights concerns created by the user, or completed jobs that produced usable output.
5.2 Partial failure under transactions normally not eligible may justify a proportionate Token adjustment or price reduction if that is fair and meets the applicable statutory standard. A full refund is used where the whole transaction should be unwound.
5.3 The treatment of transactions normally not eligible is recorded so that support, billing and enforcement remain consistent. A corrected error is reflected in the Account or transaction history.
6. Timing of requests
6.1 The practical and contractual position is this: Users should report payment errors or non-delivery promptly and preferably within 14 days. Statutory limitation periods and card-scheme rights are not reduced by this operational request period.
6.2 Security review for timing of requests may temporarily restrict the Account or affected Tokens to prevent further loss. The restriction is lifted or narrowed when control and transaction facts are established.
7. Information we may request
7.1 In operational terms, The review may require Account email, order reference, amount, currency, payment date, last four digits or method identifier, Token ledger screenshot, job identifier, prompt time, error message, output file and steps already attempted.
7.2 A user relying on information we may request should preserve the order, amount, currency, job identifier, error and output status. Missing information can lengthen a discretionary review but does not extinguish a provable mandatory right.
7.3 No delay in enforcing information we may request is a permanent waiver. A later response remains available where the underlying breach, error or risk continues.
8. Investigation process and service standards
8.1 Requests are acknowledged within two business days. A substantive decision is targeted within five business days, or up to ten business days where payment-provider, security, job-log or rights investigation is reasonably necessary.
8.2 If investigation process and service standards also becomes a card dispute, the merchant process and scheme process may run in parallel. Communications and fulfilment records can be supplied through the payment chain while cardholder rights remain intact.
8.3 If part of the rule on investigation process and service standards is unenforceable, it is adjusted only to the minimum extent necessary and the remaining provisions continue.
Refund stages
| Stage | Focus | Indicative timing | Output |
| 1. Intake | Identify Account, order, issue and requested remedy | Acknowledgement within 2 business days | Case reference and any information request |
| 2. Verification | Check payment, Token ledger, job, output and security evidence | Normally within 5 business days | Verified facts and provisional classification |
| 3. Extended investigation | Provider, fraud, rights or technical review where needed | Up to 10 business days | Reasoned decision or progress update |
| 4. Remedy | Apply Token restoration, re-delivery, price reduction or refund | Promptly after approval | Ledger correction and confirmation |
| 5. Funds settlement | Return approved funds to original method | Typically 5-10 business days after processing | Issuer credit, subject to bank timing |
9. Types of outcome
9.1 The controlling rule is as follows: Outcomes may include explanation, technical correction, Token restoration, re-delivery, replacement access, partial price reduction, full refund, refusal with reasons, or referral for additional security verification.
9.2 For types of outcome, support compares the order, payment status, Token ledger, job result, output access and communications. The evidence is used to distinguish non-delivery, defect, user error, platform failure and disputed use.
10. Delivery failure and technical defect
10.1 For the Flash Gen service, Where payment succeeded but Tokens were not credited, the first remedy is correction of the ledger. Where a Verified Platform Failure consumed Tokens and produced no usable output, affected Tokens are restored automatically or after validation.
10.2 The remedy for delivery failure and technical defect is selected to correct the verified problem without producing duplicate value. Re-delivery, Token restoration or price reduction may be more direct than a cash refund, depending on the legal remedy required.
10.3 Records supporting delivery failure and technical defect are retained only for the applicable business, legal and evidential period and are protected under the Privacy Policy.
11. Duplicate, incorrect or misapplied charges
11.1 This section allocates responsibility clearly. A confirmed duplicate or incorrect charge is refunded or corrected. Where a payment is pending rather than captured, the operator may ask the payment provider to release or allow the authorisation to expire instead of issuing a refund.
11.2 A decision concerning duplicate, incorrect or misapplied charges states the principal evidence, outcome and next step. Material new information may justify reopening the case rather than requiring a separate complaint.
11.3 A business Account may allocate internal roles for duplicate, incorrect or misapplied charges, but the registered Account holder remains responsible for authorised access and accurate instructions.
12. Unauthorised transactions and fraud
12.1 The Account and transaction outcome follows this position: Users must notify their card issuer and Flash Gen promptly, secure the Account and provide relevant details. Access may be restricted while the operator preserves evidence and prevents further loss.
12.2 Where unauthorised transactions and fraud depends on a payment provider or issuer, Flash Gen records the instruction date and reference. The provider or issuer controls when a released hold or refund becomes visible to the user.
13. Relationship with chargebacks and disputes
13.1 To keep the Service predictable, Users are encouraged to contact Flash Gen before raising a chargeback so a resolvable issue can be corrected quickly. This does not waive any cardholder right; once a scheme dispute is opened, evidence and communications may be supplied through the payment chain.
13.2 Partial failure under relationship with chargebacks and disputes may justify a proportionate Token adjustment or price reduction if that is fair and meets the applicable statutory standard. A full refund is used where the whole transaction should be unwound.
13.3 Users should raise concerns about relationship with chargebacks and disputes promptly and preserve relevant confirmations, errors and communications so the issue can be resolved on reliable evidence.
14. Effect of a refund on Tokens, Content and Accounts
14.1 The practical and contractual position is this: A granted refund reverses the corresponding Token credit or deducts the refunded balance. Related outputs and licences may be withdrawn to prevent double recovery, and a negative balance may restrict further use until resolved.
14.2 Security review for effect of a refund on tokens, content and accounts may temporarily restrict the Account or affected Tokens to prevent further loss. The restriction is lifted or narrowed when control and transaction facts are established.
14.3 Any discretionary accommodation for effect of a refund on tokens, content and accounts is assessed consistently but does not create an automatic entitlement for materially different circumstances.
15. Taxes, fees, currency and processing
15.1 In operational terms, Refunds are made to the original payment method in the original transaction currency. Bank conversion, issuer fees or exchange-rate movements are outside the operator’s control; the operator refunds the amount it actually received where law permits.
15.2 A user relying on taxes, fees, currency and processing should preserve the order, amount, currency, job identifier, error and output status. Missing information can lengthen a discretionary review but does not extinguish a provable mandatory right.
16. Cancellation and statutory rights
16.1 Consumers may have a 14-day cancellation right for distance contracts. For immediately supplied digital content, that right may be lost only after express prior consent to immediate supply and acknowledgement of the resulting loss of cancellation rights.
16.2 If cancellation and statutory rights also becomes a card dispute, the merchant process and scheme process may run in parallel. Communications and fulfilment records can be supplied through the payment chain while cardholder rights remain intact.
16.3 The user remains responsible for downstream use connected with cancellation and statutory rights, including context, disclosures, third-party rights and compliance after an output is downloaded.
17. Age and payment authority
17.1 The controlling rule is as follows: Purchasers must be at least 18 and authorised to use the payment method. A claim that a purchase was made by another household member is investigated against Account, device and payment evidence and does not automatically establish unauthorised use.
17.2 For age and payment authority, support compares the order, payment status, Token ledger, job result, output access and communications. The evidence is used to distinguish non-delivery, defect, user error, platform failure and disputed use.
17.3 A restriction concerning age and payment authority can remain in place while a payment, safety or rights investigation is active and is reviewed when material new evidence becomes available.
18. Abuse and repetitive claims
18.1 For the Flash Gen service, Fraudulent, contradictory or repetitive claims may be consolidated, refused or escalated for verification. No anti-abuse control is used to obstruct a genuine statutory or card-scheme remedy.
18.2 The remedy for abuse and repetitive claims is selected to correct the verified problem without producing duplicate value. Re-delivery, Token restoration or price reduction may be more direct than a cash refund, depending on the legal remedy required.
19. Changes
19.1 This section allocates responsibility clearly. Changes apply prospectively and do not remove accrued statutory rights or an approved remedy. The version and effective date identify the applicable publication.
19.2 A decision concerning changes states the principal evidence, outcome and next step. Material new information may justify reopening the case rather than requiring a separate complaint.
19.3 The operator will not impose a new price or recurring charge merely because changes requires verification, correction or support.
20. Governing law, contact and escalation
20.1 The Account and transaction outcome follows this position: This Policy is governed by the law of England and Wales while preserving mandatory protections available to consumers elsewhere. Complaints may be escalated by replying to the decision and identifying the contested finding and requested remedy.
20.2 Where governing law, contact and escalation depends on a payment provider or issuer, Flash Gen records the instruction date and reference. The provider or issuer controls when a released hold or refund becomes visible to the user.
20.3 Communications about governing law, contact and escalation are sent to the Account email or another verified contact, and users must keep that route secure and current.
Operational Review Flow
The review follows a traceable sequence designed to resolve genuine issues quickly while preserving payment and fulfilment evidence.
| Scenario / step | Practical rule |
| 1. Submit | Email the Account address, order reference, issue, job reference and requested remedy. |
| 2. Acknowledge | Flash Gen targets acknowledgement within two business days and requests only information needed to decide the case. |
| 3. Verify | Payment, Token, job, output and security evidence are compared. |
| 4. Decide | A decision is targeted within five business days, or ten business days for a reasonably necessary extended review. |
| 5. Apply remedy | Correct the ledger, restore Tokens, re-deliver, reduce price or process refund as appropriate. |
| 6. Escalate | Reply to the decision with the disputed finding; card-scheme and statutory rights remain available. |
Flash Gen · Refund Policy · v1.0 · effective 21 July 2026 · Published on the website; subject to update; the current published version governs.
