Pixel Mill · Payment Policy · v1.0 · Effective 21 July 2026
| Field | Value |
| Operator | MANAGEMENT RESILIENCE LTD |
| Company number | 15587224 |
| Registered office | 20 Wenlock Road, London, England, N1 7GU |
| Trading name / brand | Pixel Mill |
| Website | https://pixel-mill.com |
| Contact email | info@pixel-mill.com |
| Support / complaints | info@pixel-mill.com; written correspondence may also be sent to the registered office |
| Governing law | England and Wales |
| Document version | v1.0 |
| Effective date | 21 July 2026 |
| Important: Payments are one-off, processed through the secure checkout provider and should normally appear under the descriptor “PIXEL MILL”; Pixel Mill does not store full card details. |
1. Scope and purpose
1.1 This Payment Policy explains how one-off payments for ready-made image content, Token Packs and other Pixel Mill Digital Products are priced, authorised, processed, recorded and disputed. In practice, scope and purpose is assessed through the checkout, provider, issuer, authentication, order and fulfilment records, with the result reflected in the reconciled payment status and resulting Account action.
1.2 The current model does not use automatic recurring billing or subscription renewal. When applying scope and purpose, those indicators are considered together rather than relying on a single unverified assertion. The Terms, Refund, Cancellation and Digital Product Fulfilment policies govern the surrounding contract and remedies.
2. Nature of transactions
2.1 Customers pay Pixel Mill for a licence to ready-made digital content or for prepaid Tokens used to request artificial intelligence image generation. The operational checkpoint for nature of transactions is the checkout, provider, issuer, authentication, order and fulfilment records; completion is shown by the reconciled payment status and resulting Account action.
2.2 Transactions are pay-in only and the Service does not offer withdrawal, payout, remittance, peer-to-peer transfer or user merchant-acquiring functions.
2.3 Tokens are contractual service credits rather than money, electronic money, cryptocurrency, stored value or a financial instrument. This treatment of nature of transactions is traceable without expanding collection or restriction beyond what the situation requires.
3. Accepted payment methods
3.1 The cards, wallets and other methods accepted for a particular customer are those displayed in the secure checkout.
3.2 Availability may depend on country, currency, device, payment provider, issuer, fraud controls and local law and can change for future orders. For accepted payment methods, relevant indicators include checkout disclosure, provider status, issuer response, amount, currency and authentication result, and the resulting action is documented through the reconciled order, provider reference and financial-status record.
3.3 Pixel Mill does not accept card credentials through email or ordinary support messages.
3.4 The accepted payment methods approach is calibrated to the transaction, request or risk actually identified and preserves any mandatory remedy.
4. Billing currencies and pricing
4.1 Prices are primarily displayed and charged in pounds sterling unless checkout clearly offers another currency and final amount. Implementation of billing currencies and pricing links checkout disclosure, provider status, issuer response, amount, currency and authentication result to the reconciled order, provider reference and financial-status record, so the practical consequence can be explained and reviewed.
4.2 The product, Token quantity, generation terms, price, tax and total are shown before payment submission. No billing currencies and pricing outcome is based solely on a technical label where reliable contrary evidence is available. Issuer conversion rates and cross-border fees may cause the statement amount to differ from an informational base-price equivalent.
5. Taxes and charges
5.1 Applicable value added tax or other digital-supply tax is included or itemised as required by the customer location and checkout configuration. Pixel Mill verifies taxes and charges against checkout disclosure, provider status, issuer response, amount, currency and authentication result and records the action in the reconciled order, provider reference and financial-status record.
5.2 Customers must provide accurate country and billing information, and business customers must provide valid tax details where documentation is requested.
5.3 Pixel Mill does not impose a hidden payment surcharge, while independent issuer or wallet fees remain governed by that provider. The taxes and charges record supports user communication, internal control and any provider, authority or court process that lawfully follows.
6. Authorisation and completion
6.1 Submitting payment asks the provider and issuer to approve the amount, and the request may be approved, declined, challenged, reversed or held for review.
6.2 A Pixel Mill transaction is complete for order purposes when successful status is received and an entitlement or confirmation is created. The practical standard for authorisation and completion is tested using the checkout, provider, issuer, authentication, order and fulfilment records; the reconciled payment status and resulting Account action then evidences the action taken.
6.3 A pending bank entry without an order confirmation may be an authorisation hold rather than a captured sale.
6.4 Timing, scope and any exception under authorisation and completion are determined from the actual Service stage rather than a generic classification.
Payment-lifecycle matrix
| Stage | What normally happens | Typical status | Key risk / control |
| Product selection | User selects content or a Token Pack and reviews licence, price, tax and total | Cart / ready for checkout | Clear product and currency disclosure |
| Payment submission | Provider securely collects the method and requests authorisation | Processing / authentication | Encryption, tokenisation, Strong Customer Authentication and fraud controls |
| Issuer decision | Issuer approves, declines or challenges the request | Approved, declined or pending | User authority and issuer risk decision |
| Order confirmation | Pixel Mill receives success and creates the entitlement | Paid / confirmed | Provider reference reconciled to one order |
| Digital fulfilment | File access or Tokens are delivered to the Account | Fulfilled or under review | Logs, email and entitlement-ledger evidence |
| After-sale handling | Refund, reversal, retrieval or chargeback where applicable | Settled, refunded or disputed | Original-method refunds and preserved evidence |
7. Third-party payment provider
7.1 An authorised third-party payment service provider identified in checkout collects payment credentials, transmits the request, supports authentication and returns transaction status. Operational review of third-party payment provider focuses on checkout disclosure, provider status, issuer response, amount, currency and authentication result, after which the reconciled order, provider reference and financial-status record confirms the result.
7.2 Pixel Mill does not store full card numbers or security codes and receives masked details, provider identifiers, status, amount, currency, authentication and relevant risk data. The third-party payment provider distinction prevents an Account, payment, content or rights issue from being treated as if every consequence were identical. The provider may act independently for network, sanctions, security and financial-law purposes under its own terms and privacy notice.
8. Security, verification and fraud controls
8.1 Checkout may use encryption, tokenisation, Strong Customer Authentication, 3-D Secure or comparable issuer verification. For security, verification and fraud controls, Pixel Mill considers risk signals, access logs, payment evidence, technical events, severity and recurrence and uses the proportionate protective measure, preserved evidence and review route to close or escalate the matter.
8.2 Email verification, device signals, velocity controls, location consistency, Account history and manual review may also be used proportionately.
8.3 A risk hold can delay fulfilment for up to 24 hours, and attempts to bypass checks, test cards or disguise location are prohibited. The security, verification and fraud controls outcome remains proportionate to severity, recurrence, user impact and the legal or contractual duty involved.
9. User payment responsibilities
9.1 A payer must be at least 18, have authority to use the method, provide accurate information and ensure sufficient funds.
9.2 The user must review the Digital Product, Token quantity, licence, total and currency before submission and preserve the receipt. In practice, user payment responsibilities is assessed through checkout disclosure, provider status, issuer response, amount, currency and authentication result, with the result reflected in the reconciled order, provider reference and financial-status record.
9.3 The statement should normally show PIXEL MILL or a close provider-approved variation disclosed at checkout.
9.4 When applying user payment responsibilities, those indicators are considered together rather than relying on a single unverified assertion.
10. Declined, failed and reversed payments
10.1 A decline may result from funds, issuer policy, authentication, incorrect details, geography or fraud controls, and Pixel Mill may not receive the issuer’s detailed reason. The operational checkpoint for declined, failed and reversed payments is checkout disclosure, provider status, issuer response, amount, currency and authentication result; completion is shown by the reconciled order, provider reference and financial-status record.
10.2 A failed attempt can create a temporary authorisation hold that the issuer releases under its own timetable if no capture occurs. This treatment of declined, failed and reversed payments is traceable without expanding collection or restriction beyond what the situation requires. A later provider, network, fraud or chargeback reversal can suspend or remove the related Tokens and licences.
11. Duplicate charges and technical errors
11.1 Users should not refresh or resubmit while checkout is processing and should check the Account and email before retrying. For duplicate charges and technical errors, relevant indicators include checkout disclosure, provider status, issuer response, amount, currency and authentication result, and the resulting action is documented through the reconciled order, provider reference and financial-status record.
11.2 A verified duplicate is identified through order and provider references and returned to the original payment method.
11.3 A manifest amount or currency error is corrected transparently and cannot be exploited by either party. The duplicate charges and technical errors approach is calibrated to the transaction, request or risk actually identified and preserves any mandatory remedy.
12. Unauthorised transactions
12.1 An unfamiliar charge should be investigated by securing the Account, reviewing the PIXEL MILL descriptor and order history, contacting the issuer and notifying Pixel Mill.
12.2 Pixel Mill may revoke sessions, freeze Tokens and coordinate with the provider while preserving evidence. Implementation of unauthorised transactions links the checkout, provider, issuer, authentication, order and fulfilment records to the reconciled payment status and resulting Account action, so the practical consequence can be explained and reviewed.
12.3 A genuine victim is not required to abandon statutory or scheme rights, while a knowingly false fraud report may trigger enforcement.
12.4 No unauthorised transactions outcome is based solely on a technical label where reliable contrary evidence is available.
13. Refunds and the Refund Policy
13.1 Refund eligibility, evidence and service standards are set out in the Refund Policy. Pixel Mill verifies refunds and the refund policy against order status, payment capture, fulfilment evidence and the remedy already supplied and records the action in the case decision, payment instruction and corresponding Token or licence adjustment.
13.2 Approved refunds return to the original payment method and typically post within five to ten business days after processing, subject to issuer timing. The refunds and the refund policy record supports user communication, internal control and any provider, authority or court process that lawfully follows. A refund or void reverses the corresponding Tokens, downloads or licences and is not sent to an unrelated payment destination.
14. Chargebacks, retrievals and disputes
14.1 Users are encouraged to contact Pixel Mill first where practical with the order reference, issue, requested remedy and evidence. The practical standard for chargebacks, retrievals and disputes is tested using checkout disclosure, provider status, issuer response, amount, currency and authentication result; the reconciled order, provider reference and financial-status record then evidences the action taken.
14.2 Providers and schemes may request consent, authentication, descriptor, order, Token, generation, download, device and communication records.
14.3 A parallel merchant refund may be paused during an active chargeback to prevent double reimbursement, without removing a distinct statutory claim. Timing, scope and any exception under chargebacks, retrievals and disputes are determined from the actual Service stage rather than a generic classification.
15. Timing of delivery and Account crediting
15.1 After successful payment, ready-made content and Tokens are normally available immediately or within several minutes.
15.2 Generation output becomes available when processing completes and the file appears in the Account or download interface. Operational review of timing of delivery and account crediting focuses on purchase record, Account identifier, Token ledger, generation deductions and reversals, after which the corrected balance, entitlement status and linked transaction history confirms the result.
15.3 Payment, fraud or technical review may extend fulfilment to 24 hours, and a captured but undelivered order must be corrected.
15.4 The timing of delivery and account crediting distinction prevents an Account, payment, content or rights issue from being treated as if every consequence were identical.
16. Payment records and audit trail
16.1 Pixel Mill retains the order, amount, currency, tax, masked method, provider reference, authentication result, consent, descriptor, fulfilment, refund and dispute status. For payment records and audit trail, Pixel Mill considers checkout disclosure, provider status, issuer response, amount, currency and authentication result and uses the reconciled order, provider reference and financial-status record to close or escalate the matter.
16.2 These records support accounting, customer service, fraud prevention and chargeback evidence and are accessible only to authorised personnel and providers. The payment records and audit trail outcome remains proportionate to severity, recurrence, user impact and the legal or contractual duty involved. Transaction and tax records are ordinarily retained for seven years under the Privacy Policy.
17. Geographic and legal restrictions
17.1 Payment availability may be limited by sanctions, export controls, network rules, provider coverage, issuer policy or local restrictions. In practice, geographic and legal restrictions is assessed through the checkout, provider, issuer, authentication, order and fulfilment records, with the result reflected in the reconciled payment status and resulting Account action.
17.2 Users must not disguise location or route payments through another person to evade a restriction.
17.3 If an order cannot lawfully proceed after capture, Pixel Mill will void or refund it rather than retain payment without fulfilment. When applying geographic and legal restrictions, those indicators are considered together rather than relying on a single unverified assertion.
18. Minors and payment authority
18.1 Only adults aged 18 or over may purchase, and an organisation must ensure that the person paying is authorised to bind it.
18.2 A cardholder reporting use by a minor should secure the Account and contact Pixel Mill and the issuer promptly. The operational checkpoint for minors and payment authority is checkout disclosure, provider status, issuer response, amount, currency and authentication result; completion is shown by the reconciled order, provider reference and financial-status record.
18.3 Any authority check is proportionate and never requires full payment credentials by email.
18.4 This treatment of minors and payment authority is traceable without expanding collection or restriction beyond what the situation requires.
19. Changes to prices, methods and rules
19.1 Pixel Mill may change future prices, Token Pack sizes, generation costs, currencies and accepted methods. For changes to prices, methods and rules, relevant indicators include checkout disclosure, provider status, issuer response, amount, currency and authentication result, and the resulting action is documented through the reconciled order, provider reference and financial-status record.
19.2 A change does not alter a completed order, create recurring billing or apply without a new affirmative checkout submission. The changes to prices, methods and rules approach is calibrated to the transaction, request or risk actually identified and preserves any mandatory remedy. Promotional pricing may have stated eligibility, period and quantity limits and may not be manipulated through multiple Accounts.
20. Processor downtime and interruptions
20.1 Checkout can be unavailable because of maintenance, provider outage, issuer disruption or network failure. Implementation of processor downtime and interruptions links provider role, contractual instruction, returned status, security control and independent legal duty to the supplier record, user-facing status and any necessary escalation, so the practical consequence can be explained and reviewed.
20.2 Users should wait for the secure checkout, check Account and issuer status and avoid sending card details to support or placing rapid duplicate attempts.
20.3 Pixel Mill remains responsible for correcting a captured order it did not fulfil, even where the original interruption began with a provider. No processor downtime and interruptions outcome is based solely on a technical label where reliable contrary evidence is available.
21. Data protection and confidentiality
21.1 Payment-related personal data is processed under the Privacy Policy using provider tokenisation and data minimisation.
21.2 Users should not send bank statements or identity documents unless a secure, proportionate support route is supplied, and unrelated information should be redacted. Pixel Mill verifies data protection and confidentiality against data category, purpose, lawful basis, recipient, location and retention criterion and records the action in the processing record, rights response and deletion or retention action.
21.3 Evidence may be shared with providers, issuers, schemes, advisers and authorities where necessary and lawful.
21.4 The data protection and confidentiality record supports user communication, internal control and any provider, authority or court process that lawfully follows.
22. Governing law and statutory rights
22.1 This Policy is governed by the laws of England and Wales. The practical standard for governing law and statutory rights is tested using applicable status, user location, request details, correspondence and mandatory legal conditions; the reasoned response, escalation route and preserved statutory option then evidences the action taken.
22.2 Consumers retain non-excludable rights, mandatory local protections and available rights against an issuer or payment provider. Timing, scope and any exception under governing law and statutory rights are determined from the actual Service stage rather than a generic classification. The courts of England and Wales have jurisdiction subject to mandatory consumer forum rules.
23. Contact and complaint route
23.1 Payment questions should be sent to info@pixel-mill.com with the Account email, order reference, date, amount, currency, last four card digits and concise issue. Operational review of contact and complaint route focuses on applicable status, user location, request details, correspondence and mandatory legal conditions, after which the reasoned response, escalation route and preserved statutory option confirms the result.
23.2 Pixel Mill aims to acknowledge a payment or refund complaint within two business days and normally issue a substantive decision within ten business days.
23.3 Written escalation may be sent to the registered office, and the user may also contact the issuer or another mandatory dispute route. The contact and complaint route distinction prevents an Account, payment, content or rights issue from being treated as if every consequence were identical.
24. Updates
24.1 The version and effective date identify the current Payment Policy.
24.2 Updates may reflect provider, scheme, law, security or Service changes and apply to future payments. For updates, Pixel Mill considers the previous version, reason for change, affected feature, notice route and transaction date and uses the effective version, preserved accrued right and future-use rule to close or escalate the matter.
24.3 An update does not retrospectively authorise a charge or remove a right attached to a completed transaction.
24.4 The updates outcome remains proportionate to severity, recurrence, user impact and the legal or contractual duty involved.
25. Practical payment lifecycle overview
25.1 The user selects the product or Token Pack, checks the Account, licence, total and currency and submits through the secure provider interface. In practice, practical payment lifecycle overview is assessed through checkout disclosure, provider status, issuer response, amount, currency and authentication result, with the result reflected in the reconciled order, provider reference and financial-status record.
25.2 The issuer then approves, declines, challenges or holds the request, after which Pixel Mill confirms and fulfils an approved order. When applying practical payment lifecycle overview, those indicators are considered together rather than relying on a single unverified assertion. After purchase, the user should save the receipt, verify delivery and compare the statement descriptor before reporting an issue.
26. Good practice before payment
26.1 Users should use a trusted device and network, verify the pixel-mill.com domain, check the total and Token quantity and confirm authority to use the payment method. The operational checkpoint for good practice before payment is checkout disclosure, provider status, issuer response, amount, currency and authentication result; completion is shown by the reconciled order, provider reference and financial-status record.
26.2 They should keep the authentication page open until a final status, avoid rapid retries and never use another person’s card or misleading location data.
26.3 An unfamiliar charge should be compared with the PIXEL MILL descriptor, receipt and order history before a fraud report is made. This treatment of good practice before payment is traceable without expanding collection or restriction beyond what the situation requires.