Landlord enrollment review pack

DRAFT FOR BUSINESS AND LEGAL REVIEW ONLY • RGU-LANDLORD-DRAFT-2026-10-13-01

Prepared October 13, 2026. No effective date has been assigned. This is not an approved agreement, an offer of active coverage, acceptance of membership, or authorization to charge. Viewing, downloading, or acknowledging this draft does not accept it. Live checkout remains blocked. The existing accepted-terms version and approval controls have not been changed.

1. Parties, scope, and enrolled profiles

The proposed agreement is between the landlord identified in the enrollment and the RentGuardUS contracting entity, which must be identified before approval. It governs only profiles itemized in the approved enrollment schedule. Each schedule must identify the rental, enrolled profile, selected plan, monthly rent, fees, and applicable coverage period. Registration, an enrollment request, signup payment, a billing subscription, lease approval, and protection activation are separate events.

DECISION D01: Confirm the legal contracting entity, approved jurisdictions, landlord authority and eligibility, and whether a profile means a rental unit, a tenant/unit relationship, or a lease. The current implementation keys admin-fee history to a persistent enrolled Unit ID, not an editable address. Decide whether tenant turnover, a replacement lease, ownership transfer, or reenrollment creates a new billable profile. Do not create additional fees by silently assigning a new ID.

2. Five proposed plans

Monthly membership pricing uses each enrolled unit's saved monthly rent, not rent actually collected. Amounts are rounded to USD cents per profile, then summed for the enrollment:

• Silver: 4.5% of monthly rent; proposed nonpayment coverage cap of 2 months. At $2,000 rent: $90/month.
• Gold: 5.5%; cap of 4 months. At $2,000 rent: $110/month.
• Platinum: 6.5%; cap of 6 months. At $2,000 rent: $130/month.
• Titanium: 8.5%; cap of 9 months. At $2,000 rent: $170/month.
• Obsidian: 10.5%; cap of 12 months, the full term of a 12-month lease, not unlimited protection or an extension beyond 12 months for a longer lease. At $2,000 rent: $210/month.

These are the current proposed rate and duration figures, not approval of coverage. Additional legal, damage, vacancy, screening, reporting, and service benefits displayed in marketing require an approved benefit schedule; no unspecified dollar benefit is granted by this draft.

DECISION D02: Confirm whether fees continue during vacancy or missing rent, how rent changes and plan changes affect billing, advance notice, proration, and the effective date of changes. Approve an exhaustive benefit schedule for each tier, including service availability and separate charges.

3. One-time signup admin fee

The proposed signup charge is $199.99 per newly enrolled profile, plus applicable tax. No monthly RGU fee is intended to be collected at signup. A profile with a previously verified paid admin fee is not charged that fee again merely because its address, label, or subscription status changes. Cancellation does not erase the historical payment or reset its paid marker.

For three new profiles, the admin subtotal is $599.97; for five, $999.95, before applicable taxes. An enrollment containing previously paid profiles must identify the exempt profiles and show the reduced subtotal.

DECISION D03: Approve what administrative work earns the fee, tax treatment, and treatment of eligibility denial, withdrawal, actual refunds, duplicate payments, and failed initial payment. Current zero configured tax is not a legal tax-exemption determination. A verified refund needs a separate ledger adjustment; cancellation itself is not a refund.

4. First recurring charge and monthly renewal

Proposed commercial rule: The first monthly RGU fee is to start 30 days after successful, provider-verified signup admin-fee payment, with monthly renewal thereafter, subject to approved cancellation provisions. Completing registration or submitting an unpaid request does not start this period. The enrolled profiles, plan rates, rents, recurring total, and tax must be disclosed before authorization.

UNRESOLVED TECHNICAL/COMMERCIAL CONDITION D04: The proposed Base44 Payments setup uses a 30-day provider trial. Subscription activation is asynchronous, and the documented subscription lookup does not expose trial-end or next-billing timestamps. A date calculated as payment + 30 days is therefore an estimate, not a confirmed provider charge date or evidence that the exact commercial rule has been satisfied. Do not promise an exact date or enable charges until the payment-time anchor, provider timing, timezone, month-end renewal behavior, and a method to prevent any earlier charge are approved and enforceable. Decide the start rule for an admin-fee-exempt reenrollment with no new signup payment.

5. Recurring authorization, proposed text

The following text is a review draft, not an authorization currently being collected:

“I authorize RentGuardUS, through Base44 Payments, to collect the disclosed one-time admin fees and applicable taxes, and to collect the disclosed monthly RGU membership fee after the approved 30-day start period, recurring monthly until cancellation takes effect under the approved agreement. I understand that signup payment does not activate rent protection. The enrollment schedule identifies my profiles, selected plans, rents, total recurring amount, billing start information, and cancellation method.”

Before this text becomes usable, the final agreement must disclose the actual approved start rule, amounts, frequency, cancellation process, and any permitted variable charges. The accepted document, immutable revision, assent timestamp, enrollment amount snapshot, and provider correlation must be retained. A terms number alone is not proof of a finalized agreement.

DECISION D05: Approve payment-method storage/authorization language, renewal notices, fee-change consent, customer receipts, electronic assent evidence and retention, and jurisdiction-specific recurring-payment requirements. Never charge undisclosed fees or increase the recurring total through an unapproved plan/rent change.

6. Probation and activation

A 60-day landlord probation period is contemplated separately from the 30-day billing start. Neither payment nor subscription activation alone activates protection. A legitimate eligibility, approval, and activation process must identify an effective date and applicable coverage schedule.

DECISION D06: Define when probation starts, whether fees are payable throughout it, what services are provided during it, treatment of defaults arising during probation, whether any coverage is retroactive, and consequences of denial or delayed activation. Do not infer these answers from the period length.

7. Coverage limits and claims

The duration caps in section 2 are proposed ceilings, not automatic payouts. Protection applies only after a legitimate activation event and under the final coverage schedule. Obsidian is capped at 12 months. No unlimited coverage, automatic legal outcome, or guaranteed acceptance is created by this draft.

DECISION D07: Approve dollar caps, per-claim/per-lease/aggregate limits, rent and tenant eligibility, covered default events, exclusions, deductibles, proof requirements, claim deadlines, payout timing, offsets, recovery rights, treatment of partial payments, disputes and fraud, damage/legal/vacancy benefits, and treatment of claims after cancellation. Confirm the legal/regulatory classification of the product; this draft does not label it insurance or make a compliance certification.

8. Cancellation and removal of profiles

Cancelling a subscription ends renewal according to the final approved cancellation policy; it does not rewrite a paid signup order, erase collected amounts or timestamps, or reset an admin-fee history. A request to cancel, confirmation of stopped renewal, and the effective end of services must be distinguished.

DECISION D08: Approve the cancellation channel, notice deadline, effective timing, immediate versus end-of-cycle termination, trial-period cancellation, future charge cutoff, any minimum commitment, and the treatment of pending claims and already earned benefits. The provider supports immediate cancellation and stopping auto-renewal; that capability does not select the policy. The current checkout groups multiple profiles into one subscription, so partial-profile cancellation, repricing, or removal requires an approved policy and a supported technical method, not a promise that individual units can already be cancelled independently.

9. Refunds and payment corrections

No refund policy is selected in this draft. Historical payment records must remain auditable; refunds, reversals and disputed charges require separate verified adjustments. A cancellation event alone is not evidence of a refund.

DECISION D09: Approve admin-fee refunds, recurring-fee refunds/proration, cooling-off and mandatory legal rights, protection denial, cancellation during probation, processing errors, duplicate charges, dispute handling, timing and method of refunds. Existing general website nonrefund wording must be reconciled with the final plan-specific policy; do not treat it as resolution of these decisions.

10. Payment failure and service status

A failed initial payment must not be described as paid enrollment or active protection. For recurring payments, billing status and coverage/service status must be recorded separately. A timeout, missing webhook, or uncertain processor response is pending reconciliation, not proof of delinquency. Do not create a negative TRS/TPL consequence from an unverified processor failure. Subscription termination does not make a historical signup payment unpaid.

DECISION D10: Approve retry count and timing, grace periods, notices, payment-method updates, whether any late fees apply, suspension/termination rules, claims during failure/recovery, and reinstatement. Confirm what verified provider events are actually available before implementing these rules. Provider-initiated cancellation may occur on payment failure, but the reviewed integration does not document a complete dunning schedule or recurring-failure webhook contract.

11. General terms, privacy, and conflicts

This draft must be reconciled with the general website terms and privacy policy. It does not replace them, override mandatory law, or approve a dispute-resolution clause. No personal or payment evidence is included in this review document.

DECISION D11: Approve order of precedence, governing law and mandatory local rights, dispute resolution, liability provisions, privacy and processor disclosures, renewal/change notices, contact/cancellation channels, and legal review of the final document.

12. Approval and release record

DECISION D12: Record the business approver, legal reviewer, resolved decision IDs D01–D11, complete final document revision/hash, approval date, effective date, benefit schedules, and enforceable billing/cancellation specifications. Final approval must be explicit, not inferred from this draft or from a version/status flag.

Current disposition: Unapproved. Membership terms remain partial; no approval record or effective date has been assigned. Proven concurrency and enforceable provider timing remain required independently. Preparing or reviewing this draft does not remove any checkout release blocker.

PROPOSED ARCHITECTURE • NOT CONNECTED, DEPLOYED, OR VERIFIED • October 13, 2026

Recommendation and evidence

Use Supabase PostgreSQL as the authoritative billing coordination ledger, called only from authenticated Base44 backend functions through the supported Supabase connector. Keep Base44 authentication, app records, and UI. No connection, database change, provider request, or migration is being made by this proposal.

Base44's entity schema documentation says entity schemas do not support unique constraints; the upsert documentation warns concurrent calls can create duplicate records. The reviewed documentation does not establish transaction or atomic compare-and-set guarantees for the existing guard. Consequently neither a pre-read, a group-hash key, a lease, nor simulated tests resolves the release blocker.

PostgreSQL documents primary/unique constraints and FOR UPDATE row locking. Supabase supports database functions/RPC. PostgREST transactions document that each request runs in one transaction; a mutating function must be invoked by POST and be VOLATILE. Multiple separate HTTP calls do not become one transaction merely because they use the same database.

Ledger invariants

1. One durable claim row per profile: a non-null primary key comprising environment, Base44 app, authorized owner, and persistent profile ID. It stores an optional current attempt reference. A/B and B/C both contend for the same B row, regardless of different whole-cart hashes. Editable addresses and labels are not identity keys.
2. Immutable attempt identity: a unique environment/app/owner/request key and an immutable server-derived cart fingerprint covering sorted profile IDs, saved rents, plans, currency/tax, charge model, and final terms revision. Replaying an old request never silently creates a new attempt. Once an old subscription is verified ended, reenrollment uses a new explicitly created generation; a unique cart fingerprint must not permanently prohibit legitimate future reenrollment.
3. Independent admin-fee ledger: one original verified fee-payment entitlement per profile identity, linked to immutable provider payment evidence. Cancellations never erase it. Genuine refunds/reversals are separate adjustments governed by approved policy.
4. Unique provider identities and webhook inbox: unique non-null checkout, order, and subscription IDs and deduplicated provider event identities, with append-only lifecycle history. Terminal events arriving before approval remain stored. Approval must not regress an already terminal subscription.
5. Namespace isolation: Test and Production cannot share claims, attempts, or dispatch permissions. Owner identity comes from Base44 auth, never a browser-supplied owner ID. Ownership of every Unit is verified server-side before a reservation.

Atomic reservation and overlap check

One stored procedure performs the complete reservation in one transaction. It creates missing claim rows with conflict-safe inserts, locks all requested profile rows in deterministic ID order using FOR UPDATE, and validates the frozen server quote. Existing immutable profile records must first be reconciled so duplicate client-profile registration cannot produce two supposedly independent IDs for the same registration key.

If all profiles are free, assign all to one durable attempt and commit together. If all are held by the same existing attempt with the identical fingerprint, return that attempt and its saved session, or a pending/reconciliation status if no session is known. If any requested profile is held by a different or incompatible attempt, reject the whole cart; do not automatically exclude B or create a second subscription for it. A/B then B/C therefore cannot simultaneously reserve B. Two concurrent first enrollments cannot create duplicate claim rows because the database enforces the primary key.

Use the same locks/transaction procedures for dispatch, approval, termination, and reconciliation. Cancellation must clear only claims still pointing at the ended attempt; a delayed old event must not release a newer enrollment. Partial-profile changes require the separately approved subscription policy.

Provider call boundary and crash handling

The Base44 Payments construct-session contract does not document an Idempotency-Key, checkout lookup-by-request-key, session cancellation API, or a provider-enforced per-profile uniqueness constraint. Do not invent one or assume the server cart fingerprint is passed through to the provider.

After reserving, a second transaction conditionally changes RESERVED to DISPATCHING and records a single dispatch token. Only the worker receiving that successful transition can issue one construct request. Commit that dispatch state before the external request; do not hold a SQL transaction open across payment-provider networking. Disable automatic HTTP/provider retries for session construction. Concurrent workers, repeat clicks and restarts return the same attempt; they do not dispatch again.

If the response is durably saved, record its checkout ID and URL and attach them to the attempt, then mirror the outcome to Base44. If the worker crashes, the response is lost, or persistence fails after provider creation, keep DISPATCHING/UNCERTAIN and hold every profile claim. Never reclaim it merely because a lease expired. Never automatically resend an ambiguous construct request, even if no checkout ID is known. A crash just before sending can also leave it blocked; this intentionally sacrifices availability for duplicate-charge safety.

This is at-most-one intentional application dispatch, not a claim of distributed exactly-once payment. No database transaction can atomically commit together with an external provider that lacks a documented idempotency/reconciliation contract. Ambiguous sessions must remain blocked until authoritative reconciliation is possible; where the reviewed API cannot prove a session is absent or terminated, operator inspection alone is not enough to permit an automatic retry. Escalating the missing provider capability for confirmation is a release prerequisite, not a reason to remove the gate.

Historical data, webhook ordering, and projections

Maintain the coordination/payment ledger as the billing authority. Base44 records become owner-scoped projections for screens, not a second source deciding whether a new checkout is allowed. Publish projection changes through a durable outbox in the SQL transaction and make projection consumers idempotent. The outbox must not automatically redeliver construct-session calls.

Store verified webhook events durably before acknowledging them. Match approvals by checkout ID and cancellation/expiration by subscription ID. An unlinked approval stays quarantined for reconciliation, including a webhook that arrives before the construct response is saved. Terminal events are monotonic. Payment history, admin-fee entitlement, subscription state, and protection activation remain separate. A projection/email failure cannot release a profile or cause another provider call.

Before adoption, reconcile all existing Base44 orders, pending sessions, unknown outcomes, paid admin fees, subscriptions, and persistent/client registration IDs into the ledger. Any unmatched or duplicate profile stays blocked. Do not create a parallel bypass path while migrating.

Security and supported connection path

The app's supported Supabase connector exposes project discovery, database SQL, and PostgREST access. It is currently not authorized. A server-owned connection is the appropriate architectural role; account mode and minimal required permissions must be approved before connecting. No Supabase end-user login system is required or proposed.

Backend functions must verify Base44 auth and profile ownership. Never expose Supabase administrative/service credentials in the browser. Deny public/anon/app-user table writes and restrict function execution to the server role; if a privileged definer function is used, pin its search path, validate inputs, and revoke default public execution. Keep sensitive billing details out of logs. All legacy payment entry points must use this ledger or stay disabled.

No-payment proof required before release consideration

In an isolated PostgreSQL test project, with a counting provider stub and network access to live payments disabled:

• Concurrent identical carts with the same and different request keys: one reservation, one intentional dispatch, one saved session result.
• Concurrent A/B and B/C, including first-time row creation: one B claim; conflicting cart dispatch count zero.
• Worker death before reservation commit, after reservation, after dispatch commit but before send, and after stub session creation but before saving: no duplicate dispatch; uncertain attempts retain claims.
• Stale workers and expired timers: no takeover; invalid dispatch tokens cannot mutate the attempt.
• Database outage, unique conflicts, deadlocks, response loss, and projection failure: fail closed; no live fallback.
• Duplicate/reordered approval, cancellation-before-approval, soft-cancellation still ACTIVE, and delayed termination for an older attempt: payment remains paid and a newer claim is not released.
• Cross-owner and Test/Production isolation; admin-fee entitlement survives cancellation and address/label edits; migration duplicates remain quarantined.

Evidence must include database rows/constraint outcomes, per-attempt dispatch counts, reproducible concurrent traces, and documented crash/recovery outcomes from the real transactional store. A stub run proves the application coordination only, not live provider behavior.

Release disposition: Proposal only. The concurrency blocker remains false/unverified. Actual store connection, schema/procedures, migration, concurrency/fault-injection evidence, provider ambiguity handling, final membership terms, and exact billing-start assurance all remain outstanding. No charges are enabled by this proposal.

BROWSER EVIDENCE STATUS: NOT RUN / NO RUN ID / NO SCREENSHOTS ATTACHED

This is a handoff and expected-results brief, not a test result. Browser execution belongs to the Testing Agent (test-tube icon in the side panel). Describe the goal and press Run. Do not represent source inspection or the previous 19 simulated/backend regression checks as browser evidence.

Safety boundary

Use the Testing Agent's isolated test environment and designated test identity. The testing documentation says agent runs do not affect production data. For any separate manual preview work, turn on Test Data; the database testing guide explains that ordinary preview with Test Data off and the published app use Production.

Do not enter card/bank details, start a hosted provider session, click a payment/checkout or resume-payment action, accept final terms, complete payment, or submit an enrollment request. Review can create saved test profiles through the quote flow; it must not touch production records. Stop at plan review. Do not weaken any terms or concurrency blocker to make a test pass. Payment-provider sandbox support is not implied by using test app data.

Goal 1: desktop funnel and persistence

Run the complete public landlord funnel from /LandlordPlans through /LandlordRegister to /LandlordPlanReview at a 1300-pixel-wide desktop viewport, without payment or enrollment submission. Test each of Silver, Gold, Platinum, Titanium and Obsidian in a fresh enrollment, confirm plan/rent prefill, enter designated test account and rental details, add/remove multiple units, switch individual unit plans, and verify per-unit and aggregate fees against the fixtures below. Verify review-only billing estimate labels, terms/concurrency warnings, payment Not started and protection Not active. Test Back to registration/plans, browser back/forward, refresh after saving registration and on review, and review with no saved draft. Preserve the chosen plan/rents/units after returning to edit; confirm whether unsaved edits survive a refresh and report any loss. Do not click Submit my enrollment, Complete enrollment & pay securely, or Resume checkout. Attach evidence for each case.

Goal 2: mobile, validation, and error states

Repeat landlord plans to multi-unit review at 390 × 844 and 360 × 800 mobile viewports. Check readable fees/disclosures, accessible plan selections, all controls reachable, no horizontal page overflow or overlapping content, and a usable back path. Test empty required fields, invalid email, missing unit identifier, zero/negative/excessive rent, remove/add/reorder-by-removal behavior, expired/corrupted/missing draft, and unavailable plan configuration/quote through supported test fault injection if available. Verify errors are visible, the page does not become blank or permanently loading, entered details can be corrected, no payment begins, and no successful charge/active protection is claimed. If a fault cannot be injected, mark that case NOT TESTED rather than pass. Stop at review and attach screenshots, actions, actual/expected observations and failures.

Expected fee fixtures, not observations

Use all-new test profiles with monthly rent $2,000 each. With the current no-tax-configured setup, signup subtotal equals due today; monthly fees are separate and not charged today. Zero configured tax is not a determination that real transactions are tax exempt.

• Silver: $90/month, $199.99 signup admin fee, 2-month proposed coverage cap.
• Gold: $110/month, $199.99 signup admin fee, 4-month cap.
• Platinum: $130/month, $199.99 signup admin fee, 6-month cap.
• Titanium: $170/month, $199.99 signup admin fee, 9-month cap.
• Obsidian: $210/month, $199.99 signup admin fee, 12-month cap, never unlimited.
• Three units, Silver + Gold + Platinum: $599.97 signup subtotal, $330/month thereafter.
• Five units, one of each plan: $999.95 signup subtotal, $710/month thereafter.
• Two units, Gold + Obsidian: $399.98 signup subtotal, $320/month thereafter.
• Remove Obsidian from that two-unit draft: $199.99 signup subtotal, $110/month thereafter. Confirm the retained unit's details did not move incorrectly.

For previously paid-profile exemption or active-subscription conflict cases, use only pre-existing designated test fixtures with genuine test ledger state. Do not manufacture a production payment, change paid flags, or pretend a signup payment occurred. If suitable fixtures are unavailable, mark those cases BLOCKED. Registration may estimate the fee for every listed unit; review must identify any verified admin-fee exemption and disclose estimate versus verified quote.

Billing and release-label expectations

Before any payment, no exact provider charge date is known. The 30-day provider trial and monthly renewal are proposed mechanics. A payment + 30-day date, if a designated existing test receipt has one, must be labelled Estimated; it cannot be called provider-confirmed. No timestamp should be fabricated from today's date. Existing cancelled-subscription fixtures must still show the historical paid signup amount and admin-fee exemption, separately from subscription termination.

Membership terms are partial/unapproved, the approval record is absent, and concurrency is unverified. Review may offer an unpaid enrollment-request action; its presence is not evidence that checkout is enabled. Do not press it in these tests. An acknowledgement of an incomplete draft must not appear to authorize an actual recurring charge.

Known source-derived checkpoints, not browser findings

The existing registration saves its session draft only on Continue to plan review, so refresh before that action may discard unsaved edits. Test and record this behavior; no persistence guarantee is asserted. A saved draft expires after 24 hours. Review depends on plan configuration and, for authenticated users, an additional quote request. Existing per-unit row displays and aggregate server quote need comparison, especially after editing a saved profile's rent or plan. These are priorities for observation, not claims of passed or failed browser tests.

Evidence required for the next milestone

For each run retain run ID, date/time, test environment, identity type, viewport, route, steps, fixture used, expected amount/label, actual observation, screenshot or relevant request/error evidence, and PASS / FAIL / NOT TESTED / BLOCKED disposition. Attach desktop results for all five plans, the three-/five-/two-unit examples, saved-draft navigation/refresh, and both mobile sizes. Record any unsupported fault injection or unavailable fixture explicitly.

Current evidence: None from a browser run. No browser run was initiated by this review pack. The earlier build and 19 backend/in-memory checks are distinct historical evidence and cannot certify layout, navigation, refresh, or error handling. The verified-flow milestone remains open until Testing Agent artifacts are reviewed and any failures are resolved.