Privacy Policy
The Schedance Privacy Policy for the Ontario beta. The effective date is stated at the top of the policy.
> **Scope: Ontario beta.** This Privacy Policy describes Schedance's data practices during the Ontario-only beta period. Providers (tenant studios) must be Ontario-based to operate on Schedance during beta. Customers (end users) booking through Ontario Providers may reside in any Canadian province; their personal information is governed by PIPEDA and, where the Customer resides in Alberta or British Columbia, the substantially similar provincial statute may also apply. Quebec residents are addressed in Section 1 below.
Schedance Privacy Policy — Beta (Ontario)
**Effective date:** 2026-06-12
**Designated person responsible for privacy compliance under PIPEDA:** `privacy@schedance.net`. We respond to privacy requests within 30 days of receipt.
---
1. Who we are
Schedance is the trade name of **17910797 Canada Inc.** (operating as Schedance) — a corporation incorporated under the *Canada Business Corporations Act* (federal), with registered office at 4030 Sheppard Avenue East, Toronto, ON M1S 1S6, Canada. We provide a scheduling and booking platform to movement professionals (yoga, dance, Pilates, fitness, and similar). This Privacy Policy explains how we collect, use, disclose, retain, and protect personal information when you use our services.
**Beta scope (current period):**
- **Providers (tenant studios)** must be **Ontario-based** to operate on Schedance during beta. Eligible jurisdictions for Providers may expand after beta per a future revision of this Policy. - **Customers (end users)** booking through a Schedance-hosted Provider may reside in any Canadian province. The privacy laws that apply to a Customer's personal information depend on the Customer's province of residence, not on the Provider's location.
We comply with the **Personal Information Protection and Electronic Documents Act** (PIPEDA, federal — primary framework for Ontario private-sector activity), the **Alberta Personal Information Protection Act** (AB PIPA, where a Customer is resident in Alberta), and the **British Columbia Personal Information Protection Act** (BC PIPA, where a Customer is resident in British Columbia). Where any applicable provincial statute imposes a stricter requirement than PIPEDA, the stricter requirement governs.
**Quebec residents:** Schedance does not make its service available to Quebec-resident Providers during beta. Provider eligibility is limited to Ontario-based studios, and tenant accounts are created only through a fail-closed operator allowlist; provider signup additionally applies a country-level region check, and payment activation is gated by a billing-address eligibility flag. Schedance does not currently operate an affirmative technical control that blocks a Quebec-resident Customer from submitting a booking on an (Ontario) Provider's page. If a Quebec-resident Customer provides personal information through the Service, Quebec's *Act respecting the protection of personal information in the private sector* (commonly "Law 25") may apply to that personal information, and Schedance will respond to any such case in line with Law 25's obligations through `privacy@schedance.net`. A dedicated Quebec compliance review, including customer-side access controls, will precede any formal availability in Quebec.
---
2. Roles under PIPEDA
Under PIPEDA terminology (which uses "organization" rather than the GDPR "controller/processor" distinction):
- **For data about Providers (you, the studio operator):** Schedance is the organization collecting and using your personal information. - **For data about Customers (students of Providers):** Schedance acts as a service provider to the Provider, processing Customer personal information **on behalf of** the Provider. The Provider is the primary organization for that data; the Provider's privacy notice to Customers governs the Provider's use of the data. - **For fraud-prevention data across all tenants:** Schedance is a sub-controller in the GDPR sense (we make independent decisions about the cross-tenant fingerprint linkage); under PIPEDA, we have an independent reasonable-purpose basis for this processing. See Section 7.
The Data Processing Agreement at [https://schedance.net/legal/dpa](https://schedance.net/legal/dpa) governs the Schedance–Provider relationship for Customer data.
---
3. Information we collect
### 3.1 From Providers
- **Account and profile:** legal name, email address, phone number, business name, address, time zone, password hash (via Supabase Auth), profile photos. - **KYC and onboarding for paid features:** information collected by Stripe for KYC (SIN/BN, business registration, banking info). **Stripe collects this directly through Stripe Connect Express; Schedance does not store SINs or full bank account numbers.** - **Platform-compliance and sanctions screening (Provider beneficial owners):** As the operator of a Stripe Connect platform, Schedance is responsible for collecting Stripe's connected-account requirements and for the ongoing monitoring of connected accounts. Through Stripe's account and person webhooks, we receive a limited set of beneficial-owner identifiers — **name, percentage of ownership, role (owner / director / title), and a politically-exposed-person (PEP) indicator that the individual self-declares during Stripe-hosted verification.** We use these only for sanctions and PEP screening and platform-integrity purposes. We do **not** use beneficial-owner identity documents, SINs, or bank-account details, and we do not record dates of birth or full residential addresses in our structured records — those remain with Stripe. Where a Stripe webhook event includes such fields, the **raw event is retained under restricted internal access** pending a payload-minimization step, and is not used by Schedance beyond the limited purposes described here. The field-level custody model is documented in our internal data-custody procedures. - **Subscription and billing:** Stripe customer ID, subscription tier, billing card last 4 (never full PAN), billing address. - **Schedance subscription billing:** billing email, billing address, subscription status, Stripe customer/subscription IDs, and any billing tax ID supplied through Stripe customer billing for Schedance's own subscription invoicing. This is separate from Provider Connect KYC data. - **Operational data:** offerings created, studio configuration, support communications. - **Technical:** IP address (hashed for fraud-prevention purposes — see Section 7), user-agent (hashed), session tokens, audit-log events. - **Signup forensics:** when you attempt to create a studio account, we log the attempt (email, outcome, hashed IP/user-agent) to a dedicated table to support fraud investigations and to allow our operator to manually allowlist legitimate signups caught by automated blocklists. This data is retained for **90 days** from the attempt and is never shared with other studios. The full disclosure is at [https://schedance.net/legal/fraud-prevention](https://schedance.net/legal/fraud-prevention).
### 3.2 From Customers (collected on behalf of the booking Provider)
- **Booking identifiers:** name, email, phone (optional), and free-text scheduling notes the Customer or Provider enters at booking (see Section 3.4 regarding health information). - **Payment data:** Stripe payment method ID, last 4, brand, expiration. Schedance never sees the full PAN; Stripe handles all cardholder data. - **Booking history:** classes booked, attended, refunded, paid, with the Provider whose booking page initiated the booking. - **Technical / abuse prevention:** IP address and user-agent are used for rate limiting, abuse prevention, and audit/security evidence. Where Schedance persists IP/user-agent evidence in application tables, it stores HMAC/pseudonymized values with separate keys. Rate-limit keys and short-lived preview-session state are stored in Upstash Redis and may include raw IP addresses, normalized email addresses in some authentication buckets, tenant identifiers, opaque session/JTI tokens, and expiry/protocol metadata.
### 3.3 Automatically collected
- **Service logs:** request paths, status codes, error traces. Structured service logs are used for diagnostics and operations. Stripe webhook handlers use a dedicated redaction helper before logging event content, and most application log calls emit IDs/status metadata rather than full payloads. Some current log call sites may still include raw IP addresses, email addresses, user-agent values, customer identifiers, or CSP report content; Schedance is tightening logger-level redaction before scale. Access to service logs is restricted to Schedance's operations personnel, and general service logs are deleted after 30 days (see Section 8). Application error reports captured for diagnostics travel a separate path — see Section 14. - **Cookies and local storage:** session cookies (essential). A detailed cookie disclosure is planned for a future release; during beta we use only essential cookies for authentication and session integrity.
### 3.4 Health information (no health-information feature in this version)
Schedance's current version offers **no feature** for recording health, medical, or injury information and does not ask for it; Schedance does not intentionally collect health information. Because the booking notes in Section 3.2 are free-text, Schedance cannot prevent a Provider or Customer from entering health-related text there — any such content is not solicited, is treated as ordinary Provider-controlled booking data, and is not used by Schedance for any health-related purpose. The free-text scheduling notes described in Section 3.2 are controlled by the Provider and the Customer and are intended for scheduling logistics (for example, "first class" or "arriving late"); they **must not** be used to record health, medical, injury, or other sensitive information without appropriate safeguards and consent. Any notes a Provider or Customer chooses to enter are processed by Schedance on the Provider's behalf as ordinary booking data, are governed by the Provider's own privacy notice, and are not analyzed or used by Schedance for any purpose beyond operating the Service. A dedicated, separately-governed health- or injury-notes capability is deferred to a future version and will carry its own privacy disclosures and consent flow before any such information is collected.
---
4. How we use information
We use personal information to:
- provide and operate the Service (authentication, booking page hosting, calendar sync); - process payments and refunds through Stripe Connect; - detect and prevent fraud (see Section 7); - communicate with you about your account, transactions, security events, and product changes; - comply with legal obligations (tax filings, regulatory requests, breach reporting); - enforce our Terms of Service; - improve the Service (using aggregated, de-identified data; we do not use Provider or Customer individual data to train AI models, and we do not sell personal information).
PIPEDA's framework works as follows: an organization may collect, use, or disclose personal information only for purposes that a reasonable person would consider appropriate in the circumstances (PIPEDA s. 5(3)), and — unless a statutorily enumerated exception applies — only with the individual's knowledge and meaningful consent (PIPEDA Schedule 1, Principle 3; s. 6.1). Applying that framework:
- **Meaningful consent** is our basis for marketing communications, optional features, and the cross-tenant fraud-prevention fingerprint linkage (obtained through the disclosures described in Section 7). - **Appropriate purposes (s. 5(3)):** operating the Service, security, and fraud prevention are purposes we document as ones a reasonable person would consider appropriate in the circumstances. The appropriate-purposes rule bounds what we may do; it does not replace consent. PIPEDA does not use the GDPR's "legitimate interest" concept, and we do not rely on it. - **Enumerated exceptions:** where PIPEDA itself permits collection, use, or disclosure without consent (for example, certain legal-obligation, legal-proceeding, investigative, or fraud-related circumstances under s. 7), we rely on the specific exception, narrowly — for example, for tax compliance, litigation hold, and responses to lawful demands.
---
5. Sharing and disclosure
### 5.1 Sub-processors
We share personal information with the following sub-processors as needed to operate the Service. **All are headquartered in or operate primarily from the United States** (cross-border accountability disclosed under PIPEDA Principle 4.1.3 — see Section 8 of the Data Processing Agreement and Section 6 below).
| Sub-processor | Purpose | Data shared | Location | |---|---|---|---| | Stripe (Stripe Inc., Stripe Payments Canada Ltd.) | Payment processing, payment-method storage, KYC, Connect transfers, fraud signals | Provider KYC, Customer payment-method tokens, transaction metadata | US (Canadian entity for some processing) | | Twilio | SMS notifications (Studio tier+), phone verification | Provider/Customer phone numbers, SMS content | US | | Cloudflare | DNS, edge proxy, WAF, bot mitigation, country-level geo headers | IP addresses, request metadata | US (global edge) | | Better Stack | Telemetry, error monitoring, status page | Application logs (Stripe webhook event content redacted before logging; broader logger-level PII redaction in progress — some log entries may still contain raw IP, email, or user-agent values, see §3.3) | US (EU region under review; not contractually assured) | | Render | Application hosting, container runtime, cron services | All application data in transit | US | | Resend | Transactional email | Recipient email addresses, email content | US | | Supabase | Postgres database, authentication, storage | All application data at rest | US (project region: us-east) | | Upstash (Upstash, Inc.) | Serverless Redis for API rate-limiting and short-lived session/preview state | Rate-limit keys that may include raw IP address, tenant slug/ID, action name, and normalized email address in some authentication buckets; opaque preview JTI/session tokens and tenant/slug/expiry/protocol metadata | US |
We require each sub-processor to maintain reasonable security measures and to use the data only for the purpose for which we share it. We have a Data Processing Agreement (DPA) or equivalent contractual safeguard with each. Most are clickwrap-executable; we retain records of these agreements.
### 5.2 Authorities and legal process
We may disclose personal information to government authorities or in response to legal process when we have a good-faith belief that disclosure is required by law, necessary to protect rights and safety, or required to investigate fraud. We will notify the affected individual where legally permitted.
### 5.3 Corporate transactions
If Schedance is acquired, merged, or its assets transferred, personal information may be transferred to the successor entity, subject to this Privacy Policy.
### 5.4 No sale of personal information
Schedance does not sell personal information. Schedance does not engage in targeted advertising. Schedance does not share personal information for the benefit of third parties' marketing.
---
6. Cross-border transfers (PIPEDA accountability)
Most of our sub-processors are located in or operate primarily from the **United States**. By using the Service, you acknowledge that personal information may be processed in the US.
While your personal information is in the United States, it may be accessed by the courts, law enforcement, and national security authorities of that jurisdiction. We provide this notice so that you are informed of that possibility before you provide personal information through the Service.
PIPEDA Principle 4.1.3 (accountability) requires that an organization remain accountable for personal information transferred to a third party for processing, regardless of the location of the third party. We meet this principle by:
- entering into Data Processing Agreements (or equivalent contractual safeguards) with each sub-processor; - requiring sub-processors to apply security measures comparable to ours; - limiting sub-processor access to the minimum data needed for the specific purpose; - disclosing the cross-border transfer transparently in this Privacy Policy (you have the right to know); - maintaining records of sub-processor compliance posture and reviewing them at least annually.
This is the PIPEDA framework. We do **not** rely on GDPR adequacy decisions, Standard Contractual Clauses, or any EU-specific framework, because Schedance is a Canadian-only beta service and not subject to GDPR.
---
7. Fraud prevention and cross-tenant linkage
For successful paid card bookings, we may receive Stripe's payment-method fingerprint from the expanded payment event. We HMAC that payment-method fingerprint with a key dedicated to payment fingerprints and compare it across Provider tenants to detect coordinated fraud. IP address and user-agent signals are HMACed separately for audit/security and provider signup-forensics surfaces; they are not combined with the card fingerprint into a single booking fingerprint. We additionally apply a self-booking heuristic to flag bookings where the booker matches the studio owner. The full disclosure is at [https://schedance.net/legal/fraud-prevention](https://schedance.net/legal/fraud-prevention), summarized here:
- **Pseudonymized, not anonymized.** A fingerprint can identify a match to another transaction we have seen but cannot be reversed to recover the original IP/user-agent/card. - **Cross-tenant linkage** — fingerprints from Studio A's bookings may match against Studio B's bookings, internally to Schedance's fraud-detection layer; Studios do not see each other's data. - **Self-booking detection** — when the booker's email or card matches the studio owner's, the resulting transfer is held for operator review. The customer (also the studio owner in this case) is not automatically blocked. - **Cryptographic isolation** — we use separate cryptographic keys for hashing different categories of data (IPs and user-agents on one side; payment-method fingerprints on the other). This means a single key compromise cannot de-anonymize all stored data. - **Basis under PIPEDA:** meaningful consent, disclosed at booking, in the Provider's privacy notice, and in this Privacy Policy; fraud prevention is additionally documented as a purpose a reasonable person would consider appropriate under PIPEDA s. 5(3). - **Retention:** up to 18 months from last paid transaction, or 90 days post-account-closure for fingerprints; 90 days for signup-attempt forensics; whichever ends sooner per category, plus extensions for open disputes or legal hold.
---
8. Retention
| Category | Retention | |---|---| | Active Provider account | For the duration of the account | | Closed Provider account | Tax-touched billing and transactional data: 6 years from the end of the last taxation year to which the records relate (Income Tax Act s. 230 — see note below); less for non-essential data | | Active Customer account, with paid transactions in the last 18 months | For the duration of the relationship with the Provider | | Active Customer account, dormant >18 months from last paid transaction | Fraud-prevention fingerprints: target purge at 18 months from last paid transaction (per Section 7; enforced by operator review/manual deletion until the automated purge job ships); booking and transaction records retained 6 years (tax-records requirement — see note below) | | Closed Customer account | Fraud-prevention fingerprints: target purge 90 days post-closure OR 18 months from last paid transaction, whichever ends sooner (enforced by operator review/manual deletion until the automated purge job ships); booking and transaction records retained 6 years (tax-records requirement — see note below) | | Provider signup attempts (forensic log of every signup form submission) | Target: 90 days from attempt timestamp (enforced by operator review/manual deletion until the automated purge job ships) | | Application logs (general service logs) | 30 days, then deleted at the log-retention layer | | Diagnostic / telemetry logs that include Stripe Connect identifiers or status | up to 90 days (operator-set affirmative maximum under our internal data-custody procedures) | | Backup snapshots | 35 days rolling | | Open dispute or chargeback | Retained for the dispute window plus 90 days post-resolution | | Legal hold | For the duration of the hold |
After retention expires, data is hard-deleted from production. Backups roll off on the standard cycle.
The "6 years" tax-record windows above reflect the record-retention requirement under the *Income Tax Act* (s. 230) — **6 years from the end of the last taxation year to which the records relate**. Schedance earns a platform fee on every paid booking, so booking and transaction records form part of the books and records supporting Schedance's **own** tax filings; while the Provider relationship continues, the same records also serve the Provider's access to its own sales history. Non-tax-touched personal information is retained only as long as necessary for the purpose for which it was collected (PIPEDA Schedule 1, Principle 4.5), and we are reviewing whether the post-relationship tax-record copy can be reduced to a de-identified or minimized form.
**Cross-jurisdictional retention compliance:**
- **PIPEDA (Canada-wide):** "as long as necessary for the purpose" — the 18-month fingerprint retention is tied directly to the chargeback-fraud-prevention purpose and the card networks' dispute horizon. Defensible under PIPEDA Schedule 1 Principle 4.5. - **AB PIPA / BC PIPA:** substantially similar retention rules; the same posture applies. - **Quebec Law 25:** stricter retention and destruction rules apply when Quebec is in scope; a dedicated review precedes any Quebec availability. - **Other jurisdictions:** Schedance is a Canadian-only beta service. A dedicated compliance review precedes availability in any other jurisdiction.
---
9. Security
We use commercially reasonable physical, technical, and organizational safeguards to protect personal information, including:
- TLS 1.2+ in transit; AES-256 at rest in Supabase; - Row-Level Security (RLS) policies on all database tables; - HMAC-based pseudonymization of fraud-prevention fingerprints with a dedicated rotated secret key; - Webhook signature verification with dual secrets; - Selective webhook-event redaction today, plus a planned logger-level redaction pass for known PII fields before logs leave the application boundary; - Automated security checks in our development and deployment process; - A documented offboarding procedure that rotates security secrets whenever any personnel's access ends; - Security audits under our internal security-audit protocol, conducted at least annually.
No system is perfectly secure. We do not warrant that personal information will not be subject to unauthorized access or loss.
---
10. Breach notification
If we determine that a breach of security safeguards has created a real risk of significant harm to an individual, we will notify the Office of the Privacy Commissioner of Canada (OPC) and affected individuals **as soon as feasible** after we make that determination, as required by PIPEDA (s. 10.1). Our internal operating target is to notify within **7 calendar days** of the confirmed-breach determination, with an outer bound of **30 calendar days** where a documented justification requires additional time; the statutory standard remains "as soon as feasible." The full procedure is in Schedance's internal breach-notification procedure.
---
11. Your rights
You have the right to:
- **Access** the personal information we hold about you and learn how we use and disclose it; - **Correct** inaccurate information; - **Withdraw consent** for collection, use, or disclosure (subject to legal or contractual restrictions); withdrawal of consent for fraud-prevention linkage may result in suspension of paid bookings; - **Request deletion** of personal information when retention is no longer justified; - **Make a complaint** to the OPC at https://www.priv.gc.ca/ or to the AB or BC Information and Privacy Commissioner if applicable.
To exercise these rights, email `privacy@schedance.net`. We respond substantively within 30 days of receipt.
**During beta**, data-subject rights are fulfilled manually through privacy@schedance.net. A self-serve UI is planned for a post-beta release; until then, requests are handled through the manual process described above.
---
12. Children and minors
**Account holders must be 16 or older.** You must be at least 16 years old to create a Schedance account — this applies both to Providers and to Customers who register to book. Schedance is not directed to children, and we do not knowingly permit a person under 16 to hold an account or to provide personal information to us directly.
**Bookings that involve a minor (under 16).** Many movement studios teach minors. Where a class participant is under 16, the booking is made by a parent or legal guardian who is the account holder. In that case:
- the **minor remains the individual whose personal information is processed**; the parent or legal guardian is the account holder and the authorized representative who provides consent on the minor's behalf (PIPEDA Schedule 1, clause 4.3.6); - the **Provider (the studio) is the organization responsible** for obtaining that consent and for its own privacy notice to families. Schedance processes the booking on the Provider's behalf as the Provider's service provider (see Section 2 and the Data Processing Agreement at [https://schedance.net/legal/dpa](https://schedance.net/legal/dpa)); and - we **minimize the information collected about a minor**: the Service does not require a minor participant's full date of birth, and we ask Providers to use the parent's or guardian's contact details rather than the child's wherever their workflow allows. Any additional information a Provider chooses to collect about a participant is the Provider's responsibility under the Provider's own privacy notice.
If you believe a person under 16 has provided personal information to us directly — outside the parent/guardian booking model above — contact `privacy@schedance.net` and we will delete it.
---
13. Changes to this Policy
We will revise this Policy as needed. Material changes will be communicated by email to your account address and posted in the dashboard at least seven (7) days before they take effect (or sooner where required by law). Your continued use after the effective date constitutes acceptance.
---
14. Cookies and local storage
During beta, the Service uses only essential cookies (authentication, session integrity). A more detailed cookie disclosure with categorization, a preference toggle, and granular consent management is planned for a future release. Until then, no advertising or analytics cookies are deployed.
We use application error-monitoring to detect and fix faults. It is configured for diagnostic error capture only — **no performance tracing, no session replay, and no advertising or behavioural analytics.** We do not intentionally send customer personal information to error monitoring, and we are extending automated redaction to the error-capture path; diagnostic error data may nonetheless contain limited technical context (for example, a URL or identifier present in an error). Diagnostic data is sent to our telemetry sub-processor (Better Stack, see Section 5.1).
---
15. Contact
- **Privacy (PIPEDA designated person):** `privacy@schedance.net` (substantive response within 30 days of receipt) - **Legal:** `legal@schedance.net` - **General support:** `support@schedance.net` - **Mailing address:** 4030 Sheppard Avenue East, Toronto, ON M1S 1S6, Canada