Product
CasaPay rent collection.
Review the connected request, reconciliation and payout workflow.
Explore rent collectionBuying guide
The payment screen is only one part of the decision. Evaluate the request, tenant journey, back-office status and path to settled rent together.
Start with the problem the team is trying to solve: manual requests, missing references, payment-method friction, reconciliation workload, landlord reporting or cash-flow protection. A platform can have many features and still fail to remove the highest-cost handoff.
Document the current workflow from obligation creation to confirmed settlement. Name each system, spreadsheet, owner and recurring exception.
Tenants need a clear source, amount, due date, available method, fee and next step. Optional guarantor or no-deposit services should be explained without implying automatic approval or waived liability.
Check mobile usability, accessibility, support routes, payment confirmation and recovery from an interrupted or failed attempt. Confirm which methods are live in each market instead of relying on a global logo list.
Ask how incoming payments connect to the original rent request, which matches are automated and how exceptions appear. The system should preserve the evidence trail without calling uncertain items complete.
Review exports, accounting entries, recipient structures, payout states, permissions and audit events. Allocation and confirmed settlement should remain separate states.
| Decision area | Evidence to request | Red flag |
|---|---|---|
| Payment status | Defined events from request to settlement | One generic paid status |
| Reconciliation | Match rules and a visible exception queue | Manual review of every line |
| Payouts | Allocation, routing and settlement shown separately | Allocation presented as money received |
| Controls | Roles, approvals and audit events | Shared access without an owner |
A portal or agreed no-API workflow can validate the process faster than a deep integration. Add PMS, accounting or AI-agent connections when they remove a measured handoff and an owner can support the rollout.
Assess API or file capability, data ownership, error handling, role permissions, reconciliation source of truth and the operational process when a connection is unavailable.
A successful rollout reaches KYB, a configured entity and payout route, a first live request, first successful settled payment and a repeatable exception process.
Compare vendors on time to activation, supported TPV, reconciliation effort, tenant support load and operating control, not feature count alone.
At minimum: identifiable requests, supported payment routes, accurate status, reconciliation, reporting, permissions and a viable settlement path.
Not necessarily. A connected payment layer can work alongside the current PMS and accounting stack.
No. Automation can describe reminders, request creation or reconciliation. Recurring payment pulls require a confirmed rail and mandate flow.
Use equivalent baseline and post-launch measures such as handling time, exception volume, activation time and realised settled TPV.
Start with the connected workflow your portfolio needs, then confirm market availability and terms during onboarding.