# DeAlgo pilot launch checklist

DeAlgo currently supports governed proposals and administrator approval. General money execution is disabled. The separate Stripe refund adapter is test-only. Configuration is not proof of successful onboarding or authorization to move money.

## 1 Complete provider onboarding

- The authorized business owner completes identity, business, and bank verification directly with Stripe.
- The deployment owner configures the canonical application URL, separate billing and merchant connection credentials, Connect client, monthly prices, and dedicated webhook secret in encrypted deployment settings.
- Keep test and live environments separate. Never paste keys, identity documents, card data, or bank details into agent prompts or proposal descriptions.
- In sandbox, complete merchant consent, account refresh, Checkout, signed webhook delivery, cancellation, and billing portal access. Confirm a second workspace cannot access any of those objects.
- Treat a configuration check as configuration only. Verify provider account status and actual event delivery separately.

## 2 Complete account and operational security

- Use MFA on the original Google or GitHub sign-in account. DeAlgo does not currently verify that provider MFA was used or enforce administrator MFA across all administrative paths. Configure and test recovery/security email before relying on /recover or email-based first-key enrollment. Provider configuration alone does not establish delivery.
- Password sign-in is limited to ten attempts per identity in fifteen minutes. Signup is limited to five per identity in fifteen minutes. Vercel client-IP and global ceilings add protection. Limits apply across server processes and fail closed if the protection store is unavailable.
- The optional owner approval key protects specified commerce decisions. Register and test a separate backup key; revocation needs another working key and ends account sessions. Password recovery preserves all approval keys. Loss of every key has no self-service bypass. Finish wider administrator MFA enforcement, an independent approval display, and independently reviewed recovery before live financial operation.
- Commission an independent review of tenant isolation, credentials, approval and dispatch authority, callbacks, and payment failure recovery.
- Verify production database backup retention and perform an isolated restore drill. Record recovery time and lost-data window; do not promise an unmeasured recovery objective.
- Configure monitored application and provider alerts, name their human owner, and rehearse pausing intake, revoking keys, preserving evidence, and reconciling uncertain provider outcomes.
- Confirm support contact, incident escalation, privacy notice, retention and deletion procedures, and reviewed customer terms.

## 3 Prove the refund workflow in sandbox

Use a test merchant and test payment. Submit an exact refund request, approve it with an authorized administrator, and reconcile its provider result. Retry the same request and verify there is no duplicate refund. Reject changed terms, wrong workspace, excessive amount, revoked credentials, expired authority, and missing approval. Simulate provider timeouts and reconcile the original request before any retry.

Do not test using real cards in live mode. Stripe prohibits this: https://docs.stripe.com/testing. A first live operation must be a genuine customer transaction with consent, after the live adapter and launch gates are complete. Do not manufacture transactions to demonstrate traction.

## 4 Run a narrow customer pilot

Start with one merchant, one refund workflow, one currency, named approvers, and an agreed financial cap. Remove direct provider credentials from the agent. Keep a human approval for every refund. Record integration time, review time, blocked requests, duplicates, provider outcomes, and support work. Reconcile every operation before expanding access.

An approved commerce proposal alone never moves funds. The generic proposal interface and the separate refund adapter must not be presented as a single live execution capability.

## 5 Expand only after evidence

Add purchases, sales, payouts, subscriptions, or agent-to-agent negotiation after a paying customer demonstrates demand. Each executable adapter needs its own provider authorization, immutable terms, limits, idempotency, reconciliation, revocation, and legal review. Existing proposal action names do not mean those payment rails are implemented.