Check Designer — Terms of Service (Draft)

Status: Draft — subject to attorney review before commercial launch. Not legally binding until published by the service operator with an effective date.

1. Introduction

These Terms of Service (“Terms”) describe the rules for using the Check Designer web application (“Service”) when offered as a software-as-a-service (“SaaS”) to business customers. The Service helps organizations design check layouts, manage accounts and templates, queue and print checks, and maintain printed-check history and audit records.

By using the Service after publication of these Terms, the customer organization (“Customer,” “you”) agrees to these Terms on behalf of its users. Individual users must be authorized by the Customer.

2. Service description (current scope)

The Service currently provides, among other features:

Multi-tenant organization with stores/locations and role-based access
Check template design, approval workflow, and version history
Account records with sensitive bank fields protected by application-level encryption
Print queue, printed history, void/reprint controls, and reporting
Audit logging of significant actions
Optional time-boxed vendor support access only with tenant OWNER approval
Billing/subscription status display foundation (live card processing via Stripe is not implemented in the current codebase)

Features may change as the product evolves. Draft Terms describe implemented behavior at the time of publication; the operator may update Terms when material features change.

3. Customer responsibilities

You are responsible for:

Accuracy of check data, payee information, amounts, and account linkage you enter
Authorized users — assigning roles and removing access when staff leave
Compliance with applicable laws governing checks, banking, payroll, and record-keeping in your jurisdiction
Secure credentials — protecting login passwords and environment secrets (including encryption keys on self-hosted deployments)
Backups — maintaining your own copies of critical data where required by your policies (see `BACKUP_RESTORE_POLICY.md`)
Printer and MICR output — verifying physical check stock, alignment, and MICR readability before live disbursement

The Service uses browser-based printing and operator-configured calibration. The operator does not guarantee that every printer or stock combination will produce bank-acceptable MICR.

4. Tenant data ownership

Customer data (templates, accounts, queue items, printed history, users, audit entries, and related metadata within your tenant) is owned by you as between you and the service operator, subject to applicable law and your agreement with the operator.

The operator retains rights in the software, documentation, and non-customer-specific improvements. Aggregated, de-identified operational statistics may be used to operate and improve the Service if permitted by the Privacy Policy and counsel.

5. Acceptable use

You agree not to:

Use the Service for unlawful purposes or fraudulent checks
Attempt to bypass access controls, encryption, or support-access approvals
Probe or attack the Service infrastructure
Upload malware or interfere with other tenants (in multi-tenant hosting)
Share credentials across unauthorized individuals

The operator may suspend access for violations, non-payment (when billing enforcement is enabled), or security risk, consistent with published policies and notice practices defined at launch.

6. Support access

Vendor personnel do not receive standing access to your tenant. Support access requires a Support Access Session approved by your tenant OWNER, is time-limited, and is scoped to permissions granted in that session. See `SUPPORT_ACCESS_POLICY.md`.

7. Sensitive data

Check and bank-related fields are treated as high sensitivity. Account numbers and signature images are stored using application-level encryption (`enc:v1:` format) when configured with `BANK_DATA_ENCRYPTION_KEY`. API responses mask account numbers by default; full reveal requires explicit permission (`account.reveal`). See `SECURITY_POLICY.md`.

8. Billing (foundation only)

Subscription plan, status, and usage may be displayed in the application. Payment card numbers are not stored in the application database today. Future payment processing, if enabled, would be handled by a third-party processor (e.g., Stripe) under separate terms. Until then, billing changes may be manual via platform operators.

9. Disclaimers

THE SERVICE IS PROVIDED “AS IS” AND “AS AVAILABLE” TO THE EXTENT PERMITTED BY LAW. THE OPERATOR DISCLAIMS WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NON-INFRINGEMENT UNLESS REQUIRED OTHERWISE BY APPLICABLE LAW.

THE SERVICE IS NOT A BANK, PAYMENT NETWORK, OR LEGAL/TAX ADVISOR. YOU REMAIN RESPONSIBLE FOR CHECK LEGALITY, SIGNATURE AUTHORITY, AND RECONCILIATION.

10. Limitation of liability

To the maximum extent permitted by law, the operator’s aggregate liability arising from the Service is limited to the fees paid by you for the Service in the twelve (12) months before the claim (or a minimum amount counsel specifies). Consequential, indirect, and punitive damages are excluded unless prohibited by law.

*Attorney review required for enforceability in your jurisdiction.*

11. Changes

The operator may update these Terms. Material changes should be communicated before they take effect, using a method defined at launch (e.g., email or in-app notice). Continued use after the effective date may constitute acceptance where permitted by law.

12. Contact (placeholder)

Operator legal entity: *[To be completed before launch]* Notices / legal: *[legal@example.com — placeholder]* General support: *[support@example.com — placeholder]*

13. Governing law (placeholder)

Governing law and venue: *[To be completed with attorney review]*

*This document is an administrative draft for internal planning. It is not attorney-reviewed and does not certify compliance with any framework (SOC 2, HIPAA, PCI DSS, etc.).*