SSolarc Labs
Privacy information

Privacy Notice

Updated 28 August 2026. This notice covers the public website, enquiry path, EPR Preflight and InvoiceBatch FR direct checkouts, partner/referral attribution, Google OAuth used for the private LAGE email tool, and the limited customer information needed to deliver paid work.

SOLARC GOODS LIMITED

Company Registration Number: 16998296

ICO registration reference published by Solarc Labs: ZC165202

Registered office: Office 16873, 182-184 High Street North, East Ham, London, United Kingdom, E6 2JA

Privacy requests: enoch@solarclabs.com

1. Information you choose to send or provide

The Guard enquiry form creates a pre-filled message and asks your email client to open it; nothing is sent until you review the message and choose to send it from your email account. Enquiries may contain your name, work email, company, selected product and workflow details. EPR Preflight checkout may collect business/name, contact, billing and payment-related information needed to process the order. Stripe processes payment details on its hosted checkout; Solarc Labs does not ask you to send card or bank credentials by email.

For EPR Preflight we ask for one anonymised 2025/2026 UK EPR packaging CSV. Do not include unnecessary personal data. The file should contain only the business/reporting data needed for the preflight.

For InvoiceBatch FR, the public site and Stripe checkout do not accept invoice files. After verified payment, representative UBL, CII or Factur-X material is handled only through the controlled founder-assisted intake described in the InvoiceBatch FR Privacy & Intake notice and, where Solarc acts as processor, the InvoiceBatch FR Data Processing Terms.

2. Why we use the information

We use enquiry information to answer requests, assess fit and take requested pre-contract steps. For paid EPR Preflight and InvoiceBatch FR orders, we use the minimum necessary contact, payment-reference and supplied service material to perform the purchased service, communicate the handoff, keep appropriate transaction/accounting records and resolve support, refund or dispute issues.

Where processing is necessary to perform a contract or requested pre-contract step, contract may be the relevant lawful basis. Separate legal obligations may apply to records we must retain. Other purposes require their own appropriate basis rather than being assumed from the commercial relationship.

3. Service providers and recipients

Stripe processes hosted checkout/payment information. Website hosting, communications and other infrastructure providers may process limited technical or business information needed to operate and protect the service. Google provides the OAuth identity and Gmail API services described in section 9. Customer-specific product deployments can involve different providers and data locations and should be agreed separately where relevant.

We do not sell personal information to advertisers or data brokers.

4. EPR CSV handling

The EPR tool is designed around a local/in-memory preflight boundary and does not require a public SaaS account. Founder-assisted delivery still requires the buyer to provide the CSV for review, so the buyer should anonymise it before sending and avoid unnecessary personal information. We use the file only for the purchased review, delivery evidence, support and any retention required to resolve the transaction or meet legal obligations.

5. Retention

Enquiry, order and support correspondence is kept only while reasonably needed to manage the prospective or active customer relationship, deliver the service, resolve disputes, protect the service or keep records required for legal/accounting purposes. Product data is retained only for the operational purpose and period reasonably needed for the selected service unless a customer-specific agreement requires otherwise.

6. Your data-protection rights

Depending on the processing and lawful basis, rights may include access, rectification, restriction, objection, portability and erasure in certain circumstances. Send requests to enoch@solarclabs.com. We may need enough information to identify relevant records and verify the requester where appropriate.

You also have the right to complain to the ICO about how your personal information has been handled.

7. Automated decisions and service boundaries

The public sales and checkout path does not make a solely automated decision with legal or similarly significant effect about the visitor. EPR Preflight and InvoiceBatch FR produce deterministic findings for human review and do not themselves make legal, tax, regulatory-acceptance or filing decisions.

8. Partner and affiliate referral attribution

When a visitor arrives through an approved partner link, the approved partner code can be carried in the URL for same-visit attribution. An ACTIVE partner referral uses that partner's dedicated Stripe checkout for the eligible InvoiceBatch FR buyer benefit. Stripe may receive a non-sensitive client_reference_id and affiliate campaign parameters so the sale can be reconciled to that ACTIVE partner. The public direct checkout remains the ordinary full-price path unless the referral resolves to a currently ACTIVE partner with a provisioned dedicated checkout.

Persistent affiliate attribution requires a separate optional choice. If the visitor explicitly enables “Affiliate referral attribution”, the site may store only the approved partner code and an expiry time in local browser storage for up to 180 days. Generic functional-preference consent does not enable this purpose. Legacy preference records without an explicit affiliate choice are treated as affiliate consent off.

If affiliate attribution is off or later withdrawn, the referral component does not read or write persistent partner attribution and clears its persistent attribution record. Same-visit referral parameters may still be carried in the URL to checkout without persistent storage. Partner codes must not contain names, email addresses or secrets.

The affiliate purpose is presented separately because persistent tracking used to reconcile affiliate remuneration is not treated as an essential site function. Visitors can change this choice on the Cookie & preference settings page.

9. Google OAuth and Gmail API data

Solarc Labs uses a private LAGE email tool that can connect a user-authorised Google Workspace mailbox through Google OAuth. The current outbound-only connection requests identity information needed to bind the selected Google account and the Gmail send permission https://www.googleapis.com/auth/gmail.send. It does not request permission to read mailbox contents for the outbound-only path.

Access and use: Google account identity/email data is used to verify that the OAuth grant belongs to the exact mailbox selected by the authorised operator. Gmail API access is used only to send messages that have passed the applicable LAGE approval and delivery controls. Google user data is not used for advertising, profiling or model training.

Storage and security: LAGE stores the minimum account-identification metadata needed for the connection and stores OAuth refresh tokens encrypted at rest in private application storage. Short-lived access tokens are obtained from Google when needed. Passwords, recovery codes and 2FA secrets are not part of this OAuth storage flow.

Sharing and disclosure: Solarc Labs does not sell Google user data and does not disclose it to advertisers or data brokers. Google user data is disclosed only where necessary to provide or secure the authorised service, where the user directs the disclosure, or where disclosure is required by applicable law. The use and transfer of information received from Google APIs will adhere to the Google API Services User Data Policy, including its Limited Use requirements.

Control and revocation: a user can revoke the application's Google access from their Google Account permissions. Revocation prevents future API access until the mailbox is explicitly authorised again. If a future deployment enables Gmail inbound/reply synchronisation, that broader capability requires separate explicit authorisation and this notice must be reviewed before materially different Google-data processing is relied on.

10. Changes to this notice

This notice should be updated before a materially different public collection method, payment flow, product-data use, Google API capability or processing purpose is relied on.

This page describes current operating boundaries; it is not a blanket statement that every possible deployment or customer use case satisfies every sector-specific regulatory requirement.