Cancellation and refund policy
This is a draft slappy document checked against the available implementation. It describes verified features and identifies unresolved matters. Production settings and actual operation require separate verification.
1. Current payment status
The operator is [OPERATOR_NAME], status [OPERATOR_STATUS], address [OPERATOR_POSTAL_ADDRESS], website [SITE_DOMAIN]. Payment and refund contact: [REFUNDS_EMAIL]; backup support contact: [SUPPORT_EMAIL]. Until replaced, these placeholders are not working addresses.
The reviewed code has plans and quotas, but checkout and payment collection are not implemented. Paddle is not connected; this document does not present it as the current seller. Actual sales, external payment links and past transactions require separate verification: [BILLING_STATUS].
No checkout in the code does not establish that nobody has ever paid. If no money was charged for a particular transaction, there is no monetary payment to refund for that transaction; quota issues are handled separately. If money was paid, the actual purchase terms and mandatory law must be considered.
2. Requirements before paid launch
For future purchases, the seller and payment provider must be determined: [SELLER_DETAILS]. Before payment, the buyer must have access to the price, currency, taxes, service scope, billing period, quota rules and automatic renewal terms if offered: [PAID_OFFER].
A planned Paddle integration does not itself create a contract with Paddle. If a future purchase is made through it, seller details, receipt, applicable terms and a working contact channel must be disclosed at purchase. Service approval, an available portal or application of Paddle rules to every user cannot be promised in advance.
Payment data flow, including what the operator receives from the seller/provider and stores itself: [PAYMENT_DATA_FLOW]. Until verified, neither receipt of full card details by the operator nor a complete absence of payment information is asserted.
3. Cancellation and access
Stopping future renewal, cancelling a generation job and receiving a monetary refund are different actions. Cancelling generation or deleting an account/project must not be treated as cancelling a paid subscription. Verified cancellation method, fallback when it fails and access end date: [CANCELLATION_PROCESS].
Access and retention/export arrangements after closure or loss of access: [ACCESS_AFTER_CLOSURE]. Until a real process exists, this page does not promise one-click cancellation, charges stopping at a specific moment or an automatic prorated refund.
After a full or partial monetary refund, the continuation of access, subscription status, project/export availability and impact on content permissions must be determined separately: [ACCESS_AFTER_REFUND]. A refund is not declared to automatically erase data or cancel all future charges.
4. Requesting a refund
Once the contact is configured, send your request to [REFUNDS_EMAIL]. Include the account email, purchase/receipt identifier, date and amount of the disputed transaction, and a brief reason. Do not send a full card number, CVV, password or API keys.
Voluntary refund eligibility and window have not been set: [REFUND_ELIGIBILITY]. Review procedure, refund method and verified timing: [REFUND_PROCESSING]. This draft does not promise refunds within an arbitrary 7, 14 or 30 days or impose a no-refunds rule. Mandatory deadlines and rights under applicable law apply regardless of these unfilled fields.
Duplicate or mistaken charges, failure to supply a paid service and other issues are reviewed against the purchase facts. Any request for further information must be necessary for verification; rights to contact the seller, payment provider, competent authority or court remain.
5. Generation and quota errors
The current user quota is a usage counter, not a cash wallet or purchased credits. A failed job, uncertain submission result, cancellation and retry may have different quota effects. An AI error also does not automatically establish a monetary payment.
Provide support with the project identifier and a description of the problem. Usage review and restoration procedure: [CREDIT_CORRECTIONS]. Automatic restoration for every error or project deletion is not promised. Quota correction does not replace monetary remedies where law or the actual purchase terms provide them.
If purchased credits are introduced later, the treatment of remaining and already used credits/quotas after a full or partial refund must be disclosed before purchase: [CREDITS_AFTER_REFUND]. Automatic forfeiture, a negative balance, retention of all credits or an additional charge must not be assumed. The current free-usage counter is not presented as purchased credits.
6. Mandatory rights and withdrawal
Statutory rights for defects, failure to supply, mistaken charges and withdrawal from a distance contract, where applicable, remain. Some consumer contracts have a statutory withdrawal period; conditions and exceptions depend on the actual sale and applicable law.
AI use, starting generation, downloading an MP4 or an ordinary terms checkbox do not by themselves automatically remove withdrawal rights. If the law permits an exception for digital content or services, contract classification, separate consents, acknowledgements and required buyer confirmation must be checked.
Working withdrawal procedure, form or online mechanism and required consents: [WITHDRAWAL_PROCESS]. Governing law: [GOVERNING_LAW]. Dispute process: [DISPUTE_PROCESS]. Language rule: [LANGUAGE_RULE].