# PaynuityCard phase-one backend status

Updated October 13, 2026, America/Chicago.

Phase-one completion means an authenticated applicant can save a non-sensitive business application and card designs across devices, submit a fixed version for review, and an authorized reviewer can manage the queue with audit history. Live card issuance and external rewards transfers remain outside phase one.

| Capability | Current state | Completion evidence still needed |
| --- | --- | --- |
| Card design and reward/economics experience | Deployed private browser-local demo | Real browser/mobile QA |
| Rewards domain | In-memory server logic; six tests passed | Database-backed journal and integration into the authenticated API |
| Application/design request handler | Implemented; seven request-to-database tests passed | Connect to hosting, verified authentication and frontend |
| Durable storage | SQLite local reference adapter passes restart test | Dedicated Neon/PostgreSQL migrations, transactions and hosted restart/cross-device test |
| Tenant and applicant ownership | Tested in request handler | Clerk membership adapter and real-session tests |
| Review snapshots and queue | Tested in durable local adapter | Executive dashboard wired to authenticated API |
| Artwork files | Browser-local demo only | Private storage, ownership, scan/validation and quotas |
| Audit history | Local writes in same transaction as domain operations | Hosted append-only permissions, monitoring and retention |
| Bank/processor/rewards connections | Not integrated | Contracts and API documentation; later phase |

## Remaining work to finish phase one

1. Provision the isolated production-target environment: private PaynuityCard GitHub repository, new Vercel project, separate Clerk application and Neon database. The connected Vercel account previously denied project creation under raise-x. Existing Agent credentials and services remain separate.
2. Connect verified login/tenant membership, PostgreSQL storage, artwork storage and the user interface to the new backend. Complete draft saving, rewards-rule versioning, submissions and executive reviews through those services.
3. Verify the complete hosted flow with distinct applicant/reviewer accounts, cross-tenant attempts, retries, concurrent edits, database persistence, iPhone Safari and Windows browsers. A fixed completion time cannot be established before access and provisioning are resolved.

## What Matt needs to provide

- Access that can create a project under raise-x and a private repository in the intended Paynuity GitHub organization. Alternatively, create empty paynuity-card resources and share the project/repository links.
- Connected access to provision a NEW Clerk application and a NEW Neon project. Do not copy Agent keys or paste secrets into chat. Runtime secrets must be configured through the platform's secret-management tools.
- No additional brand assets or financial/legal documents are required for the next non-sensitive demo implementation.

For later integration, supply actual sponsor-bank/BIN correspondence, processor sandbox API documentation and credentials through secure configuration, plus the rewards-provider contract and active catalog/API documentation. The supplied overview is not that approval packet.

## Verification limits

Backend tests use real local SQLite transactions and Fetch Requests but fictional session verification. No new hosted API or real Clerk session was enabled by this continuation. Database provisioning, browser/mobile tests, backups, security assessment and real partner integrations are not complete. Live activation always rejects.