Trust
Security at CashSDK.
Including what we don't have yet.
We handle your customers' purchase records and your store credentials. This page is what we do to protect them, who else touches the data, and where the gaps are, written so your security team can stop reading and start filling in their questionnaire.
Architecture
Isolation that does not depend on remembering
The controls below are structural. They hold whether or not the next person to touch the code knows they exist.
Tenant isolation in the database, not the application
Every tenant table carries a Postgres row-level-security policy keyed on the workspace. Isolation does not depend on an application-layer check being remembered on every query. It is enforced one layer below the code that could forget it.
Fails closed
Money-path services refuse to boot without their secrets, and the dev-only verification bypasses are hard-blocked outside an explicitly-development environment. A missing key stops a deploy instead of quietly downgrading a security control.
Validated against the source of truth
Receipts are verified server-to-server against the App Store and Google Play. We are wired into Apple and Google directly, not into a reseller, so an entitlement reflects what the store actually says.
Idempotent by construction
Validation and entitlement writes are keyed on the store's own transaction identifiers, so a retried webhook, a duplicated notification, or an outage mid-purchase cannot double-charge or double-grant.
Your data
What we hold, how it is protected, and when it goes
You are the controller of your end users' data and we are your processor. The Data Processing Addendum is the binding version of everything on this page.
Store credentials are envelope-encrypted
Your App Store Connect key and Google Play service account are encrypted at the application layer with segregated key material before they reach the database. A database backup on its own does not yield a usable credential.
Encrypted in transit and at rest
TLS for all SDK, API and dashboard traffic. Databases and backups are encrypted at rest by our hosting providers.
Retention has an end date
Analytics events are kept 13 months, raw store notifications 90 days, sign-in codes 30 days, and the audit trail 13 months. Your financial ledger is retained for the life of the workspace. We are required to keep it, and you would not thank us for deleting it.
Deletion actually deletes
Deleting a workspace puts it in a read-only 30-day hold (still exportable, and reversible if it was a mistake) and then destroys it. We issue a written deletion certificate recording what was removed.
Access control
Who can get in, and what they can do
SAML 2.0 single sign-on, with enforcement
Bring any SAML 2.0 identity provider: Okta, Microsoft Entra, Google Workspace. Enforcing SSO for your domain means no other sign-in route works for it, including any support or testing path on our side.
SCIM 2.0 provisioning
Users are provisioned and, more importantly, deprovisioned from your directory. A membership deactivated in your IdP grants nothing here. It is refused exactly like no membership at all.
Roles, and a policy table you can review
Owner, admin and member, with a single declarative policy governing every privileged route: store credentials, API keys, billing, revenue import, entitlement grants and SSO configuration.
Audit trail you can read and export
Every change made through the dashboard or API is recorded with the actor, the action, the target and a hash of the arguments, as are sign-ins, failed sign-ins and session revocations. Owners and admins can filter it and export it as NDJSON from Settings → Security.
Subprocessors
Everyone who touches the data
The authoritative list, with the role each one plays, is Annex 3 of the DPA. We give 30 days' notice before engaging a new subprocessor.
| Provider | Purpose | Location |
|---|---|---|
| Railway | Application hosting, databases and queues | United States |
| Cloudflare | DNS, content delivery, network security and transactional email | United States |
| Vercel | Web hosting for our sites and dashboard | United States |
| Google Cloud Platform | Google Play purchase notification transport | United States |
| Sentry | Error and performance monitoring, scrubbed of secrets | United States |
| Stripe | Platform billing and payment processing | United States |
| Anthropic | AI paywall generation, when you use that feature | United States |
Data is processed primarily in the United States. Transfers from the EEA rely on the Standard Contractual Clauses, incorporated in the DPA. We do not currently offer EU data residency.
Honesty
What we don't have yet
Every vendor's trust page lists strengths. Here is the other half, so you find out from us rather than in diligence.
No SOC 2 report. The architecture is built along SOC 2 lines (least privilege, audit logging, encryption, vendor management) but we have not completed an audit and we will not imply otherwise. Ask us where this sits on the roadmap.
No third-party penetration test yet. The platform has been through repeated internal adversarial review, with the findings fixed and regression-tested. That is self-assessment, and we know the difference.
No EU data residency. Processing is in the United States under the Standard Contractual Clauses. If in-region processing is a hard requirement for you, tell us before you start an integration.
Two native SDKs, not five. iOS and Android ship today. React Native, Flutter, Unity, Cordova and Capacitor do not exist yet and are marked “Soon” wherever they appear.
Disclosure
Found something? Tell us.
Email security@cashsdk.com. We will acknowledge within one business day and keep you updated until it is resolved.
We will not pursue or support legal action against anyone who reports a vulnerability in good faith, gives us a reasonable chance to fix it before disclosing, and avoids privacy violations, data destruction, and any degradation of the service while testing.
Please do not test against another customer's workspace. Create your own. The sandbox is free and it exercises the same code paths as production.
For contractual security terms see the DPA, for availability and support commitments see the SLA, and for what you may run on the platform see the Acceptable Use Policy.