Skip to content
Bizmerce

Trust

Security and isolation by design

See how Bizmerce approaches tenant isolation, access control, payment boundaries, automation guardrails, and data handling across the platform.

Where formal certifications or independent audits are not available, we state that explicitly.

Contact securityView privacyReview subprocessors

  • Tenant isolation

    Organization and store access is scoped by trusted server context.

  • Server-side authority

    Pricing, inventory, entitlements, permissions, and sensitive actions are enforced centrally.

  • Payment boundaries

    Shopper payments and Bizmerce subscription billing remain separate systems of record.

  • Controlled automation

    Automation operates only inside merchant-defined policies, approvals, budgets, and limits.

What this page covers

A transparent overview of security, isolation, and operational control principles built into Bizmerce.

What we do not claim

We do not present certifications, audit reports, or security controls we cannot substantiate.

Principles

Architecture commitments

The product rules that shape enterprise trust conversations.

  1. 01

    Tenant isolation is correctness

    Organization A must never read or modify Organization B data. Protected operations are scoped by trusted server context.

  2. 02

    Authentication and membership

    Users authenticate globally, then gain merchant access through organization membership, store context, and permissions.

  3. 03

    Backend is authoritative

    Pricing, inventory, refunds, entitlements, and protected state are enforced on the server.

  4. 04

    Payments stay separated

    Shopper payments and Bizmerce SaaS billing use separate records, providers, and state flows.

  5. 05

    Automation stays policy-bound

    Automation can act only inside configured channels, budgets, approvals, inventory rules, and kill switches.

  6. 06

    Audit and least surprise

    Important actions should be explainable, traceable, and free from deceptive interaction patterns.

Identity & access

Who can act, and under which authority

Access is layered: account identity, organization membership, store context, then permission.

Unique accounts
Each user authenticates individually. Account verification and password reset are server-owned.
Membership-based access
Merchant access flows through organization membership. Platform staff authority is separate from merchant roles.
Store-scoped permissions
Protected actions are validated against store context and role permissions.
Session and MFA controls
Sessions can be revoked. Optional TOTP multi-factor authentication is available for accounts that enroll it.
OAuth verification
Optional Google and Facebook sign-in verify provider tokens on the backend. Long-lived secrets are not stored in the browser.

Tenant isolation

Selectors are not authorization

Client-supplied organization or store identifiers are lookup hints. The server revalidates membership and permissions for protected operations.

Organization A must never read or modify Organization B data across catalog, orders, customers, growth, media, or support. Storefront host resolution and merchant admin membership checks stay separate paths with the same isolation requirement.

Sensitive business state stays server-authoritative

  • Pricing and promotions
  • Inventory availability
  • Payment success state
  • Refunds
  • Plan entitlements and usage
  • Roles and permissions
  • Automation approval state

Client UI can request actions, but protected business rules are revalidated before state changes.

Payments & webhooks

Commerce money and SaaS billing stay separate

These flows remain intentionally separate systems of record, providers, and webhooks.

Shopper commerce payments

  1. Store checkout
  2. Merchant payment provider
  3. Verified provider event / webhook
  4. Order / payment state

Bizmerce subscription billing

  1. Organization
  2. SaaS billing provider
  3. Subscription state
  • Browser redirect is not proof of payment success
  • Provider/webhook evidence is authoritative
  • Webhook signatures are verified where the provider supports them
  • Duplicate events are tolerated with idempotent processing

Shopper card data is handled by the merchant’s configured payment provider. Bizmerce does not claim PCI DSS certification; provider scope depends on the integration the merchant enables.

Automation safety

Automation stays inside merchant policy

Manual, Assisted, and Autopilot modes are explicit. External mutations revalidate policy immediately before execution.

  • Allowed channel
  • Budget limit
  • Inventory condition
  • Approval requirement
  • Merchant-configured policy
  • Kill switch

AI and model output is treated as untrusted input and cannot directly mutate external provider state without validated application controls, guardrails, and audit.

Audit event fields

Actor
Authenticated membership user
Action
Refund approved
Resource
Order
Store
Store context
Time
Timestamp (UTC)

Material merchant and platform actions record actor, action, resource, and timing for explainability. Audit visibility may vary by plan.

Infrastructure & data protection

Operational controls we can substantiate

Hosting region and managed services depend on deployment configuration. We describe categories, not invented certifications.

Transport security
Application traffic is served over HTTPS/TLS in deployed environments.
Credential handling
Passwords are hashed with a maintained password encoder. Secrets stay in deployment/runtime configuration, not source code.
Data storage
PostgreSQL is the transactional system of record. Managed Postgres (such as RDS) may be used depending on deployment.
Object storage & CDN
AWS S3 or S3-compatible storage, with CloudFront where configured, for media delivery.
Input and upload safety
Uploads and imports validate tenant/store context, type, size, purpose, and ownership.
Abuse protection
Selected public and sensitive endpoints use rate limiting and authentication throttling.

Subprocessors & integrations

Who processes what

Bizmerce-managed infrastructure is separate from merchant-controlled payment and marketing integrations.

  • Hosting & database

    Bizmerce-managed

    Run the Bizmerce application and store platform data

    Application host and PostgreSQL (managed Postgres where deployed)

  • Object storage & CDN

    Bizmerce-managed

    Store and deliver media assets

    AWS S3 or S3-compatible storage; CloudFront where used

  • Transactional email

    Bizmerce-managed

    Verification, invitations, and operational notifications

    SMTP delivery configured by Bizmerce operations

  • Commerce payments

    Merchant-controlled integration

    Process shopper checkout for a store

    Merchant-configured payment providers

  • Marketing providers

    Merchant-controlled integration

    Paid advertising and related Growth Hub actions

    Meta, Google Ads, and TikTok when a merchant connects them

  • SaaS billing

    Bizmerce-managed

    Organization subscription billing to Bizmerce

    Configured SaaS billing provider for plan charges

Commerce payment providers process shopper payments on behalf of the merchant and are not automatically Bizmerce subprocessors for shopper funds. Exact managed hosts and SMTP vendors can change with deployment.

Requests

Privacy and enterprise security paths

We provide factual answers based on the current platform and deployment configuration.

Privacy requests

  • Access, export, and deletion requests
  • Consent and marketing preferences
  • Customer data handling in store operations
View privacy notice

Enterprise security requests

  • Security questionnaires
  • DPA and hosting questions
  • Subprocessor and architecture review
Contact security

Related

Security sits next to privacy and the product you will actually run.

PrivacyTermsFeaturesIntegrations

Evaluating Bizmerce for your organization?

Send us your security questionnaire or ask about hosting, tenancy, access controls, subprocessors, or data handling.
Contact securityView privacy