Flash Gen · Digital Product Fulfilment 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: Fulfilment is digital: Token Packs are delivered when the purchased Tokens are credited to your Account, and generated images are delivered when the completed file is made available in your Account or through a secure download route. No physical goods are shipped. |
1. Scope and relationship with other policies
1.1 The controlling rule is as follows: This Policy explains delivery of Token Packs, pre-generated Content and Generated Output. Payment rules appear in the Payment Policy; remedies appear in the Refund Policy; Account closure appears in the Cancellation Policy.
1.2 For scope and relationship with other policies, the order, payment confirmation, Token entry, job timestamp, output status and access event are examined in sequence. This identifies the exact point at which fulfilment completed or failed.
1.3 Mandatory consumer, privacy and payment rights continue to apply to scope and relationship with other policies; this Policy cannot be used to waive a protection that the law makes non-excludable.
2. Meaning of digital product and fulfilment
2.1 For the Flash Gen service, A digital product includes a Token Pack, licensed image file, Generated Output or access entitlement. Fulfilment means creating the corresponding Account credit or making the purchased file accessible through the delivery interface.
2.2 A timestamp relevant to meaning of digital product and fulfilment is strong evidence but is assessed with credible display, access and error information. A file-created event alone does not settle a genuine report that the entitlement could not be used.
2.3 A user may ask support to review a material outcome concerning meaning of digital product and fulfilment. Review can confirm the result, correct an error, narrow a restriction or identify the proper statutory process.
3. General fulfilment model
3.1 This section allocates responsibility clearly. Payment confirmation triggers entitlement creation. Token Packs update the Token ledger; pre-generated Content is added to downloads or licensed access; a generation request enters a processing workflow and consumes the displayed Token amount.
3.2 Where general fulfilment model can be corrected without unwinding the purchase, Flash Gen may re-credit Tokens, restore Account visibility or issue a fresh secure link. This is correction or re-delivery of the same entitlement.
4. When fulfilment is complete
4.1 The Account and transaction outcome follows this position: A Token Pack is complete when the Account ledger records the credit. Pre-generated Content is complete when an accessible file or secure link is provided. Generated Output is complete when the job status is completed and a usable file is available.
4.2 A safety block affecting when fulfilment is complete is not a platform failure merely because no image is produced. Token treatment follows the displayed job rule and is corrected if the block itself was erroneous.
4.3 Reasonable verification may be required for when fulfilment is complete, especially where value, Account control or sensitive data is involved. Verification is proportionate to the risk and information requested.
5. Typical timeframes
5.1 To keep the Service predictable, Token crediting and pre-generated downloads are normally immediate or near-immediate after confirmed payment. Generated Output may be asynchronous and depends on queue, complexity, model load, safety checks and file preparation.
5.2 Service-system time governs the sequence for typical timeframes and may differ slightly from a user device. Support focuses on payment confirmation, entitlement creation, processing and availability rather than device-clock differences.
5.3 The treatment of typical timeframes is recorded so that support, billing and enforcement remain consistent. A corrected error is reflected in the Account or transaction history.
6. Preconditions for delivery
6.1 The practical and contractual position is this: The Account must be active, payment confirmed, checkout verification completed and requested activity lawful. Accurate Account contact information and a supported browser or device are required for reliable access.
6.2 If preconditions for delivery remains unresolved after reasonable troubleshooting, the case moves to the Refund Policy. The available outcome depends on whether the issue is non-delivery, defect, verified platform failure or user-side access.
7. No physical shipping and no stored value
7.1 In operational terms, Flash Gen does not ship physical products. Tokens are service credits rather than stored value and cannot be delivered to a bank, wallet, card, external platform or another user.
7.2 Manual review of no physical shipping and no stored value is limited to fraud, sanctions, security, prohibited content or unusual activity. It does not convert the order into recurring billing or create a new charge.
7.3 No delay in enforcing no physical shipping and no stored value is a permanent waiver. A later response remains available where the underlying breach, error or risk continues.
8. Delayed, pending or failed fulfilment
8.1 A pending order may await payment confirmation or risk review; a pending job may await capacity. If a Verified Platform Failure consumes Tokens and produces no usable output, affected Tokens are restored.
8.2 A user reporting delayed, pending or failed fulfilment should avoid duplicate orders and preserve the order, job, timestamp, error and screenshot. That evidence allows support to correct the right entitlement quickly.
8.3 If part of the rule on delayed, pending or failed fulfilment is unenforceable, it is adjusted only to the minimum extent necessary and the remaining provisions continue.
Fulfilment scenarios
| Scenario | Typical treatment | Likely evidence | Next step |
| Payment confirmed; Tokens absent | Reconcile order and credit ledger | Payment status and Token ledger | Support correction or refund if correction fails |
| Job pending in queue | Allow processing or investigate abnormal delay | Queue and model timestamps | Status update; Token restoration if failure |
| Verified Platform Failure; no usable output | Restore consumed Tokens | Error code, job result and output record | Retry at user choice |
| Output completed but not visible locally | Troubleshoot Account, browser and sync | Completion and access logs | Re-deliver link or correct interface issue |
| Duplicate purchase | Verify separate captures and entitlements | Order and provider records | Correct under Refund Policy |
| Safety-blocked prohibited prompt | Do not generate prohibited output | Prompt and safety decision | Revise lawful prompt; Token treatment follows displayed rule |
9. User-side display, sync or access issues
9.1 The controlling rule is as follows: Users should refresh the Account, sign out and back in, check filters and supported formats, disable conflicting extensions and verify connectivity. A local display issue does not by itself mean the server-side entitlement was not delivered.
9.2 For user-side display, sync or access issues, the order, payment confirmation, Token entry, job timestamp, output status and access event are examined in sequence. This identifies the exact point at which fulfilment completed or failed.
10. Manual review and risk controls
10.1 For the Flash Gen service, Orders or jobs may enter manual review for fraud, sanctions, account compromise, prohibited content or unusual activity. Review is limited to the risk and is not used to create undisclosed recurring billing.
10.2 A timestamp relevant to manual review and risk controls is strong evidence but is assessed with credible display, access and error information. A file-created event alone does not settle a genuine report that the entitlement could not be used.
10.3 Records supporting manual review and risk controls are retained only for the applicable business, legal and evidential period and are protected under the Privacy Policy.
11. Evidence and fulfilment records
11.1 This section allocates responsibility clearly. Flash Gen may rely on order status, payment confirmation, Token ledger, job timestamps, model status, error code, output creation, access and download logs, support history and user acknowledgements.
11.2 Where evidence and fulfilment records can be corrected without unwinding the purchase, Flash Gen may re-credit Tokens, restore Account visibility or issue a fresh secure link. This is correction or re-delivery of the same entitlement.
11.3 A business Account may allocate internal roles for evidence and fulfilment records, but the registered Account holder remains responsible for authorised access and accurate instructions.
12. Incorrect Account, duplicate and user-error scenarios
12.1 The Account and transaction outcome follows this position: Purchases made into the wrong Account are not automatically transferable because account identity and fraud controls must be preserved. Duplicate orders are investigated under the Refund Policy; incorrect prompts or settings are normally user responsibility.
12.2 A safety block affecting incorrect account, duplicate and user-error scenarios is not a platform failure merely because no image is produced. Token treatment follows the displayed job rule and is corrected if the block itself was erroneous.
13. Relationship to refunds, cancellations and chargebacks
13.1 To keep the Service predictable, Non-delivery and technical defects are reviewed before cash refund where correction or Token restoration provides the required remedy. Closure does not erase fulfilment evidence, and a chargeback may be answered with delivery and consent records.
13.2 Service-system time governs the sequence for relationship to refunds, cancellations and chargebacks and may differ slightly from a user device. Support focuses on payment confirmation, entitlement creation, processing and availability rather than device-clock differences.
13.3 Users should raise concerns about relationship to refunds, cancellations and chargebacks promptly and preserve relevant confirmations, errors and communications so the issue can be resolved on reliable evidence.
14. Support process
14.1 The practical and contractual position is this: Support requests should identify the order, Account, job, expected delivery, actual status, time and troubleshooting attempted. Acknowledgement is targeted within two business days.
14.2 If support process remains unresolved after reasonable troubleshooting, the case moves to the Refund Policy. The available outcome depends on whether the issue is non-delivery, defect, verified platform failure or user-side access.
14.3 Any discretionary accommodation for support process is assessed consistently but does not create an automatic entitlement for materially different circumstances.
15. Service changes, maintenance and force majeure
15.1 In operational terms, Maintenance or events outside reasonable control may delay delivery. Flash Gen will restore service, preserve paid entitlements and provide a fair remedy where delay becomes material or performance is impossible.
15.2 Manual review of service changes, maintenance and force majeure is limited to fraud, sanctions, security, prohibited content or unusual activity. It does not convert the order into recurring billing or create a new charge.
16. Children, age and authorised purchases
16.1 Only users aged 18 or over may purchase or submit generation jobs. Business administrators remain responsible for access granted to staff and for ensuring purchasing authority.
16.2 A user reporting children, age and authorised purchases should avoid duplicate orders and preserve the order, job, timestamp, error and screenshot. That evidence allows support to correct the right entitlement quickly.
16.3 The user remains responsible for downstream use connected with children, age and authorised purchases, including context, disclosures, third-party rights and compliance after an output is downloaded.
17. Governing law and statutory rights
17.1 The controlling rule is as follows: This Policy is governed by the law of England and Wales and does not replace mandatory rights for digital content that is defective, misdescribed or not supplied with reasonable care and skill.
17.2 For governing law and statutory rights, the order, payment confirmation, Token entry, job timestamp, output status and access event are examined in sequence. This identifies the exact point at which fulfilment completed or failed.
17.3 A restriction concerning governing law and statutory rights can remain in place while a payment, safety or rights investigation is active and is reviewed when material new evidence becomes available.
18. Updates
18.1 For the Flash Gen service, Updates apply to future fulfilment workflows and do not retrospectively alter the delivery evidence or price attached to a completed order.
18.2 A timestamp relevant to updates is strong evidence but is assessed with credible display, access and error information. A file-created event alone does not settle a genuine report that the entitlement could not be used.
19. Contact
19.1 This section allocates responsibility clearly. Report non-delivery to info@flash-gen.com from the Account email and include the order and job references.
19.2 Where contact can be corrected without unwinding the purchase, Flash Gen may re-credit Tokens, restore Account visibility or issue a fresh secure link. This is correction or re-delivery of the same entitlement.
19.3 The operator will not impose a new price or recurring charge merely because contact requires verification, correction or support.
What users should do before reporting non-delivery
Complete these checks before reporting non-delivery. They reduce duplicate payment attempts and allow support to isolate the failure quickly.
| Scenario / step | Practical rule |
| Check payment status | Confirm the order is paid rather than pending, declined or reversed. |
| Check the right Account | Sign in with the email used at checkout and refresh the Token ledger or downloads view. |
| Check job status | Record whether the job is queued, processing, completed, safety-blocked or failed. |
| Troubleshoot locally | Refresh, sign out and in, test a supported browser, check extensions and confirm connectivity. |
| Preserve evidence | Keep the order, job reference, timestamp, error message and screenshot. |
| Contact support | Send the evidence from the Account email; avoid opening duplicate jobs or repeated payments while the case is reviewed. |
Fulfilment controls and evidence
AS.1 Fulfilment timestamps use service-system time and may differ slightly from a user device. The relevant sequence is payment confirmation, entitlement creation, job processing and output availability.
AS.2 A safety-blocked job is not a platform failure merely because no image is produced. Token treatment follows the rule displayed for the job and the Acceptable Use Policy, subject to correction of an erroneous block.
AS.3 Support may provide a fresh download link or restore Account visibility without recreating the underlying output. This is re-delivery of the same entitlement, not a new purchase.
Flash Gen · Digital Product Fulfilment Policy · v1.0 · effective 21 July 2026 · Published on the website; subject to update; the current published version governs.
