Data & Security

1. Local-first data model

In the current public beta, the private comeback profile, setup state, dispute cases, drafts, notes, goals, Debt Autopilot balances, strategy settings, locally recorded payment history, and payoff-cycle planning data are stored in browser local storage. Imported credit-report files, locally extracted report text, and evidence files are stored in browser IndexedDB. CredBounce does not transmit those materials by default. If a user explicitly authorizes CredBounce Send for one specific dispute, the browser assembles the selected dispute letter and attached PDF/PNG/JPG/TXT evidence into a final PDF packet locally, then transmits that final packet plus sender/recipient mailing addresses through the secure delivery gateway to the configured mailing provider for that one mailing.

The Contact form, UPSHIFT+ early-access form, and Debt Autopilot+ Level 2 activation-interest form use a separate protected submission path. Those forms send only the information you intentionally enter so CredBounce can review support requests and beta interest. The Level 2 interest form does not collect bank credentials, creditor credentials, account numbers, funding authorization, or a payment mandate.

2. Erasing local data

The Dispute Center includes an erase-local-data control for reports, evidence, drafts, response text, local delivery metadata, and dispute timeline information, and Start Here includes a separate profile-clear control. Users should also understand that browser settings, private-browsing behavior, device cleanup tools, or clearing site data can remove the broader locally stored workspace. Erasing local data does not cancel or erase a mailing already authorized and handed to a third-party mailing provider, and it does not delete provider records retained under that provider’s policies.

Keep independent originals of credit reports, evidence, correspondence and other records you may need later.

3. Local storage is not a backup system

Device-local storage reduces centralized collection, but it does not make data invulnerable. Anyone with access to an unlocked device or browser profile may be able to access local application data. Device loss, browser corruption, storage quotas, or clearing browser data can cause loss.

4. HTTPS, delivery gateway, protected forms, and premium checkout

The public site is delivered over HTTPS. CredBounce Send uses HTTPS to transmit an explicitly authorized final packet to a separate delivery gateway. That gateway validates the authorization, packet type/size, mailing class, and idempotency key before calling the mailing provider; it is designed not to persist packet or address contents. HTTPS protects data in transit but does not replace normal device security such as a screen lock, current operating-system updates, and safe account practices.

Support, early-access, and Debt Autopilot+ activation-interest forms are submitted through the platform’s server-side visitor form system with session, CSRF, and rate-limit protections. Their submissions are stored in the project’s private lead inbox rather than exposed as public website content.

UPSHIFT+ membership payment is handled on Stripe-hosted checkout. Raw payment-card details are not entered into the CredBounce local workspace. The membership payment flow is separate from any future funding-account authorization used for creditor payments.

Public marketing pages use a Google Ads tag for advertising measurement. The private app workspace is designed separately, and CredBounce does not intentionally send imported credit reports, evidence files, locally extracted report text, or dispute drafts through that advertising tag.

5. Information we do not need in this beta

Do not enter Social Security numbers, bureau passwords, bank passwords, authentication codes, full payment-card data, or other credentials into free-text fields. The private profile asks for ordinary mailing details used to organize your own workflow and prefill your own draft letters; it does not ask for an SSN or bureau login. CredBounce does not need those credentials to provide the current self-service workflow.

6. Delivery, future accounts, synchronization and payment partners

CredBounce Send is designed as user-directed mailing logistics, not managed credit-repair decisioning. The user selects the dispute, reviews the final packet, confirms truthfulness, supplies a matching typed authorization signature, and authorizes that specific transmission. Provider test/sandbox resources are kept separate from live postage, and live delivery remains fail-closed unless the configured provider and production controls are enabled.

Debt Autopilot Level 1 remains local planning/tracking and does not move money. Debt Autopilot+ Level 2 is designed around separate premium membership billing and a specialized creditor-payment provider. The current beta keeps live creditor-payment execution locked while provider approval, tokenized funding-account setup, identity verification where required, creditor destination validation, recurring authorization, pause/revoke controls, failure handling, reconciliation, and launch review are completed.

UPSHIFT+ premium membership checkout is active through Stripe. Optional membership accounts use Supabase Auth and store account email, account ID, Stripe customer/subscription IDs, and membership status on the server. The Premium payoff comparison reads local debt balances in your browser and does not upload those balances or report files. If future versions add cloud synchronization, licensed credit monitoring, bank connectivity, identity verification, or live creditor-payment services, the data model and disclosures will be updated before those features are made available. CredBounce should not directly collect raw bank passwords or full payment-card credentials for those integrations.