Authenticated sessions
Mabnee uses account authentication and session controls for cloud-synced business work. Protected business data is scoped to the authorized account rather than trusted from browser state alone.
SECURE BY DESIGN. PRIVATE BY DEFAULT.
Trust begins with clear data boundaries.
Mabnee separates account data, reusable business records, payment state, government/provider workflows, and high-risk sensitive information so each feature receives only the access it needs.
CURRENT PRODUCTION CONTROLS
What the live Mabnee system does today.
These controls are active in the current account, workspace, database, and billing architecture. Higher-risk features remain separately gated until their own requirements pass.
Row-level authorization
Business, payment-order, invoice, roadmap, passport, and related protected records use account-linked ownership controls in the production data layer.
High-risk fields stay gated
Ordinary business-profile flows are not designed for SSNs, raw card data, banking passwords, private keys, patient information, or identity-document uploads. Dedicated controls are required before those data classes are accepted.
Server-authoritative billing
Checkout amounts originate from Mabnee’s server-controlled catalog. Stripe hosts payment entry, and Mabnee does not treat a browser redirect as proof that money settled.
Verified provider events
Stripe webhook signatures are verified before events enter an idempotent server-side ledger. Duplicate events are rejected and transaction state is reconciled from provider-confirmed events.
No silent government action
Provider and government submission routes remain disabled when credentials, contracts, current fee/source records, review steps, or jurisdiction-specific controls are incomplete.
HIGH-RISK ACTIVATION GATES
More sensitive does not mean “turn it on and hope.”
Mabnee keeps identity documents, direct provider submissions, secure document storage, registered-agent fulfillment, and other higher-risk capabilities behind independent production gates.
High-risk personal data
- Explicit purpose and minimum-data analysis
- Dedicated secure fields or provider tokenization
- Encryption and access controls
- Retention and deletion rules
- Incident-response treatment
Secure vault activation
- Encrypted object storage
- Per-tenant authorization
- Malware scanning
- File-type restrictions
- Download and deletion auditability
Submission credentials
- Approved provider contract
- Production credentials
- Webhook reconciliation
- User review and authorization
- Failure and resubmission path
Jurisdiction coverage
- Eligible provider in each jurisdiction
- Appointment consent
- Service-of-process handling
- Notice and escalation
- Cancellation and replacement workflow
Authoritative amounts
- Government fee source and verification date
- Mabnee/government/tax separation
- Stripe Tax head-office setup
- Registration and nexus review
- No agency-approval implication
Recovery and response
- Monitoring and alerting
- Incident response
- Provider outage handling
- Payment dispute workflow
- Recovery and rollback evidence
PAYMENT SECURITY MODEL
The browser never gets to declare itself paid.
Mabnee creates checkout from server-owned price identifiers, records the expected service and government-fee split in its financial ledger, sends customers to Stripe-hosted payment entry, and changes authoritative transaction status only after Stripe-signed events or server-to-server reconciliation.
- No client-supplied price authority
- Stripe-hosted payment credentials
- Checkout idempotency key
- Signed webhook verification
- Duplicate event rejection
- RLS-protected payment orders and invoices
| Data class | Example | Default treatment |
|---|---|---|
| Public business | Approved website, public phone, service description | Reusable with user control |
| Operational | Entity facts, licenses, business address, ownership percentages | Authenticated and purpose-limited |
| Billing metadata | Service amount, government fee, Stripe references, invoice status | Server-authoritative and audit-tracked |
| Sensitive | SSN, bank credentials, identity documents | Blocked from ordinary fields; dedicated secure workflow required |
| Official | Certificates, filing receipts, acceptance records | Integrity and provenance preserved |
REPORTING
Security concerns should have a direct path.
Security reports should begin with a non-sensitive description. Do not include passwords, private keys, SSNs, full payment information, identity documents, or other high-risk data in an ordinary message.
Report a security concern
Use the Contact page and label the message “Security.” Include the affected page, approximate time, browser, and a non-sensitive description so Mabnee can triage the issue without exposing additional data.
Contact Mabnee →YOUR NEXT STEP STARTS HERE
Build with controls that match the risk.
Mabnee activates each capability only after its account, data, provider, payment, and jurisdiction requirements are verified.