Tenant isolation
Every merchant’s data is isolated at two levels, and neither depends on application code remembering to filter. Within a deployment, row-level security in the database scopes every read and write to a single store; across deployments, each tenant runs on its own dedicated database and API layer. A query cannot reach another store’s data, and one deployment’s incident cannot affect another’s. This is covered in depth in Data Model & Multi-tenancy — the short version is that isolation is a property of the infrastructure, not a filter an engineer has to remember. Automations extend this guarantee. When a merchant’s own automation — a custom extension, or an AI-generated one such as an ad-optimization rule — needs to read the store’s data, it does not get direct database access. It reads a governed set of business concepts (revenue and margin by product, stock at risk, campaign performance, active promotions, and the like) exposed as a fixed, read-only interface. Every concept is scoped to the automation’s own store, returns computed business facts rather than raw records, and can never reach another tenant’s data or a table the automation wasn’t meant to see. This lets a merchant’s logic act on rich, meaningful signals while the underlying data stays walled off — the same isolation that protects the storefront protects what an automation can read.Authentication and access
Access to the API is by key, and the key type determines what it can do.Publishable keys
For the storefront — safe to ship in a browser or mobile bundle. A publishable key reads catalog and
other non-sensitive data, and can make the writes a shopper performs on their own behalf: adding to a
cart or wishlist, submitting a review, sending a message, lodging a return, updating their own profile.
It cannot place or modify orders, take payments, sign customers in, or touch store-wide or other
customers’ data.
Secret keys
Full read/write access, for server-side use only. Orders, payments, customer sign-in, and any
store-management write require a secret key — which must never reach the browser.
Data in transit and at rest
All API traffic is served over HTTPS/TLS; there is no plaintext endpoint. Sensitive values a merchant stores with the platform — payment-processor credentials, integration tokens — are encrypted at rest in a managed secrets vault, not in an ordinary table column, and the plaintext is never returned to the browser after it is entered. What the merchant sees afterward is a masked reference; the secret itself is used only server-side, to talk to the provider it belongs to.Payment integrity
The payment path is designed so that the platform never holds funds and never sees raw card details.1
Card details go straight to the processor
Card entry happens on the payment processor’s hosted checkout, not on a Galactic Core page. Card
numbers never reach the platform’s servers or database — the platform stores only a payment reference,
never a card number.
2
The processor holds the money
For marketplace payments, funds are captured by the processor and paid out to each merchant’s own
connected account. The platform never custodies money; it only directs the split. This is what keeps
marketplace operators outside money-transmitter territory.
3
Amounts are recomputed server-side
Prices, tax, shipping, discounts, and the order total are re-derived from the authoritative catalog
when an order is placed. A client that submits a tampered price or total is rejected — the amount the
customer is charged is the platform’s figure, never the client’s.
4
Payment confirmations are verified at the source
When a payment is confirmed, the platform re-checks the transaction directly with the processor and
reads the amount and status from the processor’s own response. Provider webhooks are cryptographically
signature-verified, and a notification that fails verification — or arrives without a signature — is
rejected before it can affect an order.
Environment separation
Test and live data never mix. The key prefix chooses the environment —tybrite_sk_test_ /
tybrite_pk_test_ operate on isolated sandbox data, …_live_ on production — and the two are stored under
a separate environment marker so a test order can never appear in live reporting. Sandbox data is purged on
a schedule, so test runs don’t accumulate. Because the environment is fixed by the key, there is no way for
a live key to read sandbox data or the reverse.
Data protection and privacy
Galactic Core is built for GDPR and CCPA from the ground up. The data in a store belongs to the merchant, and the tools to exercise data-subject rights over it are self-service — the merchant runs them directly, from their own dashboard, without going through us. Your store’s data is never shared with anyone else; we would only step in to help produce an export if a merchant were unable to run one themselves.Access and portability
A merchant can export a complete copy of their own store’s data — customers, orders, catalog,
accounting, and the rest — as a portable archive of spreadsheets, from Settings → Data Export, with
sensitive credentials excluded. They can also produce the data held about an individual customer to
satisfy a request that customer makes to them.
Erasure
A merchant can delete an individual customer’s personal data, and can request deletion of their entire
store. Erasure removes the personal data across the stores where it lives.
Shared responsibility
The platform secures the infrastructure and the boundaries; you secure how your integration uses it. The split:Found a security issue? We appreciate responsible disclosure — email
[email protected] and we will work with you on it. Please give
us a chance to address it before any public disclosure.
Authentication
Key types, scopes, environments, and request signing in detail.
Data Model & Multi-tenancy
How row-level security and per-deployment isolation keep tenants separate.