Skip to content

Data privacy & compliance

bc-subscriptions stores only the data needed to run recurring billing for your store. This page explains what that data is, what rights your subscribers have, and what the app handles on your behalf versus what you remain responsible for.

Jurisdiction

GDPR applies when any subscriber is an EU resident. CCPA applies to California residents. bc-subscriptions implements the same data-subject rights for all subscribers regardless of location.

How subscriber data is handled

When a subscriber purchases through your store, bc-subscriptions records the following:

Data Storage location Purpose
Email address bc-subscriptions database (Cloudflare D1) Billing receipts and lifecycle communications
BigCommerce customer ID bc-subscriptions database Links subscriber account to your BC store
Subscription state (plan, status, dates) bc-subscriptions database Core billing record
Charge history (amounts, outcomes, timestamps) bc-subscriptions database Billing audit trail; retained 7 years for tax records
Payment method reference (token ID, last 4 digits, brand) bc-subscriptions database Displayed in subscriber portal; used for recurring charge execution
Consent preferences (marketing, lifecycle emails, profiling opt-out) bc-subscriptions database Honored across all outbound communications

What bc-subscriptions never stores:

  • Raw card numbers (PAN), CVV, or full payment account details. Card data stays inside Stripe or the BigCommerce Vault. bc-subscriptions stores only opaque processor token references.
  • Passwords. Authentication uses magic links or BigCommerce OAuth.

This design keeps the app in PCI SAQ-A scope — the lightest PCI DSS self-assessment category — because card data never touches bc-subscriptions servers. See the Compliance, trust & audit guide for the PCI scope statement and how to download the attestation PDF.

Subscriber data rights (GDPR)

bc-subscriptions implements the following data-subject rights. Subscribers can exercise most of them without contacting you, via Account → Data & Privacy in the subscriber portal.

Right to access and portability

A subscriber can request a copy of all data bc-subscriptions holds about them. The request initiates a job that produces a downloadable JSON and CSV bundle. The bundle includes:

  • Subscription state and history
  • Charge history
  • Address records
  • Payment method references (token IDs; never raw card numbers)

The bundle is delivered via a secure, expiring link within 30 days of the request (the regulatory deadline). Subscribers can trigger this themselves from the portal, or you can initiate it from Admin → Subscribers → Actions → Export data.

Right to erasure

A subscriber can request deletion of their personal data. The erasure cascade:

  1. Cancels any active subscriptions
  2. Anonymizes the subscriber record — email, name, and address are replaced with [redacted]
  3. Detaches the payment token at the processor
  4. Preserves audit-log entries using the anonymized identifier, so the compliance event history survives

The cascade completes within 30 days. A confirmation is sent to the subscriber's last-known address when complete.

Retention exception: Financial records (charge amounts, dates, outcomes) are retained with PII stripped for 7 years to satisfy legal financial-record obligations. This is the standard legal basis under GDPR Art. 17(3)(b) for records required by law. The subscriber's email and name are not recoverable after erasure.

Erasure and refunds are separate: erasure removes identity, it does not reverse charges. If a subscriber wants a refund, process that first. The refund flow requires the linked payment token; erasure detaches it.

Subscribers can adjust three communication preference flags in Account → Communication preferences:

Preference Controls
Marketing emails Promotional offers sent on your behalf
Lifecycle emails Renewal reminders, failed-payment notices, cancellation confirmations
Profiling Whether dunning retry logic uses payment-history patterns to personalize retry timing

Opting out of lifecycle emails does not stop mandatory transactional notifications (such as erasure confirmation). Regulatory-required communications are always sent.

Data retention

Data category Retention Basis
Active subscriber profile Until erasure or store uninstall + grace window Active subscription contract
Charge history 7 years Tax-record legal obligation
All audit-log events Minimum 1 year Operational compliance
Charge events in audit log 7 years Tax-record legal obligation
Anonymized erasure records Indefinite (no PII present) Legal documentation of erasure event

On uninstall: Active subscriptions are paused (not cancelled). The store's access token is revoked immediately. If you reinstall within 30 days, all subscription data is restored to its pre-uninstall state. If you do not reinstall within 30 days, all subscription data for your store is permanently deleted. Reinstalling after that window is treated as a fresh install — subscription history is not recoverable.

Audit trail

bc-subscriptions records compliance-relevant events in an immutable audit log. The log captures actor, action, subject, and before/after state for every mutating operation — subscription changes, charge events, admin actions, and erasure jobs.

You can export the audit log from Admin → Audit log for any date range. The export format is CSV and is suitable for auditor review.

Audit log events include charge-level fields (mit_subtype, chain_position, actor_user_id or actor_kind for system-initiated events) that provide the evidence trail for SCA dispute defense.

Erasure jobs are logged separately in the audit log even when the subscriber's event rows are stripped during anonymization.

Merchant responsibilities

bc-subscriptions handles the app-side data obligations described above. The following remain your responsibility:

  • External data copies. If you export subscriber data to a CRM, data warehouse, email platform (e.g., Klaviyo), or any other system, you are responsible for applying erasure and retention controls in those systems when a subscriber makes a request. The bc-subscriptions erasure cascade does not reach external tools you have connected.

  • Identity verification for DSAR requests. When a subscriber makes a request by email rather than through the portal, you must verify their identity before fulfilling it. The portal's magic-link login is the verification mechanism bc-subscriptions provides.

  • DSAR record-keeping. GDPR recommends keeping your own log of data requests received, how they were handled, and when they were fulfilled. bc-subscriptions does not maintain this log on your behalf.

  • Annual PCI re-attestation. bc-subscriptions surfaces a "next attestation due" date in Admin → Settings → Compliance → PCI. SAQ-A status is only valid as long as you do not accept card data through any other channel. If you add a custom payment form or other card-handling path, your PCI scope expands beyond SAQ-A.

  • Processor compliance. Stripe and BC Payments each have their own compliance posture. Your relationship with your processor is separate from bc-subscriptions.

  • Outbound webhooks. If you use bc-subscriptions webhooks to push data to external systems, those payloads must not include unredacted PII beyond what the receiving system is authorized to process.