Flash Gen · Payment 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: Flash Gen sells one-off digital Content and Token Packs; there is no subscription or automatic renewal. The total price, currency and Token quantity are shown before payment, and refunds are returned to the original payment method when approved. |
1. Scope and purpose
1.1 The controlling rule is as follows: This Policy governs payment for Token Packs, pre-generated Content and related digital services. It explains checkout, authorisation, fraud controls, ledger crediting, payment failures, refunds and card disputes.
1.2 For scope and purpose, the checkout reference, amount, currency, authorisation result and Account entitlement are reconciled. Fulfilment pauses where the payment result is incomplete or conflicts with issuer information.
1.3 Mandatory consumer, privacy and payment rights continue to apply to scope and purpose; this Policy cannot be used to waive a protection that the law makes non-excludable.
2. Nature of transactions
2.1 For the Flash Gen service, Purchases are individual digital transactions. Tokens are closed-loop service credits, not money, electronic money, cryptocurrency, securities or stored value, and they cannot be transferred, redeemed or withdrawn.
2.2 Security controls affecting nature of transactions are risk-based and may use device, velocity, address, authentication and sanctions signals. A lawful payment can still require review where the available evidence is inconsistent.
2.3 A user may ask support to review a material outcome concerning nature of transactions. Review can confirm the result, correct an error, narrow a restriction or identify the proper statutory process.
3. Accepted payment methods
3.1 This section allocates responsibility clearly. Flash Gen accepts payment cards and any additional methods displayed at checkout. Availability may depend on location, currency, device, transaction value, risk checks and payment-provider support.
3.2 A user questioning accepted payment methods should provide the order date, amount, currency, Account email and limited method identifier. Full card numbers, card security codes and authentication codes must never be sent to support.
4. Billing currencies and pricing display
4.1 The Account and transaction outcome follows this position: Prices are displayed in pounds sterling by default, with another supported currency used only where shown before payment. The checkout confirms product, Token quantity, total price, tax treatment and billing currency before submission.
4.2 Where billing currencies and pricing display creates a pending issuer hold without capture, Flash Gen confirms whether it received funds. The issuer determines when an uncaptured authorisation expires or disappears.
4.3 Reasonable verification may be required for billing currencies and pricing display, especially where value, Account control or sensitive data is involved. Verification is proportionate to the risk and information requested.
5. Taxes and charges
5.1 To keep the Service predictable, Applicable taxes are included or separately identified before payment as required. Users are responsible for issuer, foreign-exchange, connectivity or third-party charges that are not imposed by Flash Gen.
5.2 Records for taxes and charges connect checkout consent with payment and digital fulfilment. They support reconciliation, customer service, refund decisions and responses to retrievals or chargebacks.
5.3 The treatment of taxes and charges is recorded so that support, billing and enforcement remain consistent. A corrected error is reflected in the Account or transaction history.
6. Authorisation and transaction completion
6.1 The practical and contractual position is this: Submitting payment authorises the payment service provider to request funds. An order is complete only when payment is confirmed and the corresponding digital entitlement is created; a pending authorisation is not final capture.
6.2 If authorisation and transaction completion is interrupted, the user should avoid repeated submissions until status is clear. Multiple retries can create separate authorisations even where only one order is ultimately completed.
Payment lifecycle
| Stage | What normally happens | Typical status | Key risk / control |
| Checkout | User reviews product, Token quantity, price, tax and currency | Ready for payment | Clear disclosure and user confirmation |
| Authorisation | Provider requests issuer approval and authentication | Authorised, declined or challenged | Strong customer authentication and fraud checks |
| Capture | Approved funds are captured for the order | Paid or pending | No fulfilment solely on an unconfirmed result |
| Entitlement | Content access or Tokens are credited | Fulfilled | Order-to-ledger reconciliation |
| Generation | Tokens are consumed for the selected job | Queued, processing, completed or failed | Job logs and automatic failure restoration |
| Aftercare | Support, correction, refund or dispute handling | Closed, refunded or disputed | Original-method refund and evidence preservation |
7. Use of third-party payment providers
7.1 In operational terms, Protected checkout fields are operated by a payment service provider. Flash Gen receives payment status, transaction reference, limited card metadata and fraud results but does not intend to store full card numbers or card security codes.
7.2 Business Accounts applying use of third-party payment providers should maintain purchasing authority and internal reconciliation. Staff misuse is addressed through Account controls without removing payment rights that apply under law.
7.3 No delay in enforcing use of third-party payment providers is a permanent waiver. A later response remains available where the underlying breach, error or risk continues.
8. Security, verification and fraud controls
8.1 Transactions may be subject to address checks, device analysis, velocity controls, sanctions screening, strong customer authentication and 3-D Secure verification. A lawful payment may be delayed or refused where risk cannot be resolved.
8.2 Flash Gen does not redirect security, verification and fraud controls to gift cards, cryptocurrency, person-to-person transfers or an unrelated merchant identity. Suspected payment impersonation should be reported immediately.
8.3 If part of the rule on security, verification and fraud controls is unenforceable, it is adjusted only to the minimum extent necessary and the remaining provisions continue.
9. User payment responsibilities
9.1 The controlling rule is as follows: Users must provide accurate billing information, use an authorised method, maintain sufficient funds, review the total and descriptor, protect Account credentials and report errors promptly.
9.2 For user payment responsibilities, the checkout reference, amount, currency, authorisation result and Account entitlement are reconciled. Fulfilment pauses where the payment result is incomplete or conflicts with issuer information.
10. Declined, failed or reversed payments
10.1 For the Flash Gen service, A decline may result from issuer rules, authentication failure, insufficient funds, regional restrictions or risk controls. A reversal may occur where an authorisation expires or the provider cannot complete capture.
10.2 Security controls affecting declined, failed or reversed payments are risk-based and may use device, velocity, address, authentication and sanctions signals. A lawful payment can still require review where the available evidence is inconsistent.
10.3 Records supporting declined, failed or reversed payments are retained only for the applicable business, legal and evidential period and are protected under the Privacy Policy.
11. Duplicate charges and technical errors
11.1 This section allocates responsibility clearly. Users should first distinguish a pending authorisation from a captured duplicate. Confirmed duplicate capture or misapplied payment is corrected under the Refund Policy without requiring a card dispute.
11.2 A user questioning duplicate charges and technical errors should provide the order date, amount, currency, Account email and limited method identifier. Full card numbers, card security codes and authentication codes must never be sent to support.
11.3 A business Account may allocate internal roles for duplicate charges and technical errors, but the registered Account holder remains responsible for authorised access and accurate instructions.
12. Unauthorised transactions and security reporting
12.1 The Account and transaction outcome follows this position: Suspected unauthorised payment must be reported to the issuer and info@flash-gen.com. Flash Gen may secure the Account, preserve logs, suspend Token consumption and cooperate with the payment chain.
12.2 Where unauthorised transactions and security reporting creates a pending issuer hold without capture, Flash Gen confirms whether it received funds. The issuer determines when an uncaptured authorisation expires or disappears.
13. Refunds and relationship to the Refund Policy
13.1 To keep the Service predictable, Eligibility, evidence and decision timing are set out in the Refund Policy. Approved refunds are routed to the original payment method and reverse the related Tokens or digital rights where necessary.
13.2 Records for refunds and relationship to the refund policy connect checkout consent with payment and digital fulfilment. They support reconciliation, customer service, refund decisions and responses to retrievals or chargebacks.
13.3 Users should raise concerns about refunds and relationship to the refund policy promptly and preserve relevant confirmations, errors and communications so the issue can be resolved on reliable evidence.
14. Chargebacks, retrievals and disputes
14.1 The practical and contractual position is this: Before opening a chargeback, users should provide the order, amount, issue and requested resolution so the merchant can investigate. Card-scheme rights remain intact, and Flash Gen may respond to a retrieval or dispute with transaction, consent and fulfilment evidence.
14.2 If chargebacks, retrievals and disputes is interrupted, the user should avoid repeated submissions until status is clear. Multiple retries can create separate authorisations even where only one order is ultimately completed.
14.3 Any discretionary accommodation for chargebacks, retrievals and disputes is assessed consistently but does not create an automatic entitlement for materially different circumstances.
15. Timing of delivery and Account crediting
15.1 In operational terms, Tokens are normally credited immediately after confirmed payment. Generation completion depends on queue, model, prompt and system capacity; a Verified Platform Failure with no usable output triggers Token restoration rather than a second charge.
15.2 Business Accounts applying timing of delivery and account crediting should maintain purchasing authority and internal reconciliation. Staff misuse is addressed through Account controls without removing payment rights that apply under law.
16. Payment records and audit trail
16.1 Flash Gen maintains order, status, currency, tax, Token-credit, job, output-access, refund, communication and dispute records. These records support user service, reconciliation, fraud response and lawful evidential needs.
16.2 Flash Gen does not redirect payment records and audit trail to gift cards, cryptocurrency, person-to-person transfers or an unrelated merchant identity. Suspected payment impersonation should be reported immediately.
16.3 The user remains responsible for downstream use connected with payment records and audit trail, including context, disclosures, third-party rights and compliance after an output is downloaded.
17. Geographic and legal restrictions
17.1 The controlling rule is as follows: Payments may be unavailable where law, sanctions, card-network rules or provider terms prohibit the transaction. Users must not disguise location, identity, merchant category or transaction purpose.
17.2 For geographic and legal restrictions, the checkout reference, amount, currency, authorisation result and Account entitlement are reconciled. Fulfilment pauses where the payment result is incomplete or conflicts with issuer information.
17.3 A restriction concerning geographic and legal restrictions can remain in place while a payment, safety or rights investigation is active and is reviewed when material new evidence becomes available.
18. Minors and payment authority
18.1 For the Flash Gen service, Only adults aged 18 or over may purchase. A business Account administrator must ensure that each authorised user acts within delegated purchasing limits.
18.2 Security controls affecting minors and payment authority are risk-based and may use device, velocity, address, authentication and sanctions signals. A lawful payment can still require review where the available evidence is inconsistent.
19. Changes to prices, methods and rules
19.1 This section allocates responsibility clearly. Future prices, Token rates and accepted methods may change before purchase. A confirmed order is governed by the price and quantity shown at its checkout and is not repriced retrospectively.
19.2 A user questioning changes to prices, methods and rules should provide the order date, amount, currency, Account email and limited method identifier. Full card numbers, card security codes and authentication codes must never be sent to support.
19.3 The operator will not impose a new price or recurring charge merely because changes to prices, methods and rules requires verification, correction or support.
20. Service interruptions and processor downtime
20.1 The Account and transaction outcome follows this position: Checkout may be paused during provider maintenance, incident response or elevated risk. Flash Gen does not request payment through informal channels as a workaround and will not fulfil an unpaid order.
20.2 Where service interruptions and processor downtime creates a pending issuer hold without capture, Flash Gen confirms whether it received funds. The issuer determines when an uncaptured authorisation expires or disappears.
20.3 Communications about service interruptions and processor downtime are sent to the Account email or another verified contact, and users must keep that route secure and current.
21. Card descriptor and complaint route
21.1 To keep the Service predictable, The statement descriptor is expected to appear as FLASH-GEN.COM or a clearly related legal-operator reference. Users who do not recognise a charge should contact info@flash-gen.com with the date and amount before initiating a dispute.
21.2 Records for card descriptor and complaint route connect checkout consent with payment and digital fulfilment. They support reconciliation, customer service, refund decisions and responses to retrievals or chargebacks.
22. Governing law and statutory rights
22.1 The practical and contractual position is this: This Policy is governed by the law of England and Wales. It does not limit statutory consumer rights, payment-service rights or card-scheme protections that cannot lawfully be excluded.
22.2 If governing law and statutory rights is interrupted, the user should avoid repeated submissions until status is clear. Multiple retries can create separate authorisations even where only one order is ultimately completed.
22.3 The burden of cooperation for governing law and statutory rights is limited to information reasonably available to the user and relevant to the decision.
23. Updates
23.1 In operational terms, The current version applies to transactions submitted after its effective date. Transaction-specific records remain evidence of the price, consent and terms presented at checkout.
23.2 Business Accounts applying updates should maintain purchasing authority and internal reconciliation. Staff misuse is addressed through Account controls without removing payment rights that apply under law.
23.3 Automated controls may assist with updates, but proportionate human review is available where required by law or appropriate for a material paid-access outcome.
Practical payment lifecycle overview
The lifecycle below helps users distinguish an authorisation, captured payment, fulfilled entitlement, refund and card dispute.
| Scenario / step | Practical rule |
| Before payment | Confirm the product, Token quantity, currency, total, tax, Account email and method authority. |
| At authentication | Complete issuer verification only in the protected checkout flow; do not share one-time codes with support. |
| After payment | Wait for confirmed status and verify the Token ledger or download access. |
| If pending | Do not repeatedly resubmit until issuer or checkout status is clear, as this can create multiple authorisations. |
| If unrecognised | Check for FLASH-GEN.COM, secure the Account, contact the issuer and send Flash Gen the date and amount. |
| If incorrect | Use the merchant support route first where practicable; this often resolves duplicates faster than a chargeback. |
Good practice before submitting payment
G1. Use only a payment method you are authorised to use and keep control of issuer authentication.
G2. Confirm the Account email, Token quantity, total price, currency, tax and statement descriptor.
G3. Do not repeatedly retry a pending payment; first check issuer and Account status.
G4. Keep the order confirmation and contact support promptly if the ledger or download does not match the order.
Flash Gen · Payment Policy · v1.0 · effective 21 July 2026 · Published on the website; subject to update; the current published version governs.
