Feature
Resident portal and rent payments
Residents see one balance made of real charges, pay through rails you control, and message the office in a thread tied to their lease. Managers see the same ledger — there is only one.
The problem
The balance the resident sees and the balance the office sees are two different numbers.
Because rent, fees, credits and payments live in different tools, someone reconciles by hand every month — and late fees get waived because nobody trusts the figure.
- Receipts are emailed manually or not at all.
- Zelle and cash payments are recorded from memory.
- Late fees are applied inconsistently, then argued about.
- Maintenance updates and office messages live in personal phones.
The workflow
One ledger, several rails, no reconciliation theatre
- Charges post to the ledger
Rent from the lease schedule, recurring charges, ad-hoc charges (repairs, NSF, pet fees) and credits — every line is a row, in integer cents, append-only.
- Resident pays
Card or ACH through Stripe Checkout on your Stripe account; receipts post from signed webhooks with replay protection. Or the resident reports a Zelle transfer with a reference.
- Manager confirms what needs confirming
Zelle and cash go through a confirmation queue before anything posts. Refunds and chargebacks are append-only adjustments.
- Late-fee policy runs
Flat, percent or daily accrual with grace and caps, per-lease overrides, duplicate protection and one-click suggestions that a person accepts.
- Everything is visible
Receipts as PDFs, statements, requests, documents and message threads in the portal — on the web or in the app.
Illustrative resident balance built from ledger rows. Payment options appear once rails are configured.
Capabilities
What is built, what needs configuration, what is planned
Each row is a real capability in the current build. Labels are derived from the codebase and its test suites, not from a roadmap deck.
How to read the labels
- Built
- Implemented in the current build and covered by its test suite.
- With configured integration
- Implemented; a live outcome requires a provider you configure (keys, contract, or credentials).
- Pilot
- Implemented in part and enabled per pilot customer with tuning.
- Planned
- On the roadmap. Not sold or promised today.
-
Resident portal
BuiltBalance, itemised charges, receipts, requests, documents, signing and messaging — scoped to the resident's own lease.
-
Charges ledger
BuiltRent, fees, ad-hoc charges and credits post to an append-only ledger in integer cents; balances are computed, never edited.
-
Card and ACH payments via Stripe Checkout
With configured integrationCheckout sessions, signed webhooks with replay protection, refunds and chargebacks as append-only adjustments. Live processing needs your Stripe account and keys.
-
Autopay and payment plans
With configured integrationAutopay enrolment, NSF handling and instalment plans on top of the ledger; live autopay uses Stripe SetupIntents.
-
Manager-confirmed Zelle queue
BuiltResidents report a Zelle transfer with a reference; a manager confirms it before anything posts to the ledger.
-
Late-fee policy engine
BuiltFlat, percent or daily-accrual policies with grace periods and caps, per-lease overrides, duplicate protection and one-click suggestions.
-
Threaded messaging and bulk notices
BuiltContext-linked threads with internal notes, read receipts and segment sends (by property, delinquency or expiring leases).
-
Email, SMS and push delivery
With configured integrationNotification engine with three channels and an in-app digest fallback; each channel needs its provider configured.
By role
What each party gets
Residents
One balance they can trust, a receipt for every payment, and a thread instead of a phone number.
Property managers
A queue for what needs a human (Zelle confirmations, late-fee suggestions) and nothing else.
Accounting
Append-only history: corrections are rows, never edits, so month-end reconciles.
Configuration and pilot notes
Before you rely on it
Things that are set up per operator during a pilot, or that depend on a provider you contract.
- Card and ACH processing requires your own Stripe account; ResidentAxis is not a payment processor and never holds funds. Processing fees are Stripe’s.
- Autopay uses Stripe SetupIntents and follows the same requirement.
- Zelle instructions and the recipient are configured per operator; Zelle itself has no API, which is why the queue is manager-confirmed.
- Email, SMS and push notifications each need their provider configured; an in-app digest is the fallback.
Questions about this area
Do you charge residents a convenience fee?
ResidentAxis does not add fees. Stripe’s processing fees apply to card and ACH payments; how you present them to residents is your policy and may be regulated in your state.
Can residents split rent between roommates?
Each payment is recorded against the lease; multiple residents on a lease can each pay part of the balance. Roommate-level sub-ledgers are not a separate feature.
What happens if a webhook is missed?
Stripe retries; ResidentAxis de-duplicates by event id and rejects replays outside a five-minute window. Nothing posts twice.
Related
Connected areas
See resident portal & payments on your portfolio.
A pilot starts with a discovery call and your CSV exports. We reply within two business days.