PROPERTY SALES & PROPERTY PURCHASES
The module manages the complete purchase journey for properties offered for sale. It connects the public listing, buyer offer, negotiation, agreed price, financing method, deposit, balance payments, landlord payouts, documents, notifications and final sold status.
|
LEASEORA PROPERTY SALES & PROPERTY PURCHASES End-to-End User, Operations and Technical Reference Guide List • Discover • Negotiate • Pay • Payout • Complete |
For property developers, real estate companies, sales teams, finance teams and client-support teams
Version 1.0 | July 2026
|
|
Purpose of this guide This guide explains how a real estate company uses the Leaseora Property Sales / Property Purchases module from listing publication and buyer negotiation through deposit, balance payment, landlord payout and final sale completion. The main sections use plain business language, while the appendices preserve the current backend models, controllers, services, events, notifications and route patterns supplied for this guide. |
1 Purpose, Audience and Terminology
The module manages the complete purchase journey for properties offered for sale. It connects the public listing, buyer offer, negotiation, agreed price, financing method, deposit, balance payments, landlord payouts, documents, notifications and final sold status.
|
Item |
Description |
|
Primary audience |
Real estate company directors, property-sales teams, finance teams, client-support teams, compliance staff and authorised administrators. |
|
Buyer audience |
Individuals or corporate clients browsing and purchasing properties through Leaseora web or mobile experiences. |
|
Business scope |
Sale listings, buyer offers, counter-offers, approval, 10% deposit, balance payments, payouts, dashboards, notifications and completion. |
|
Technical scope |
The current model, controller, service, event, notification, reference and API flow supplied for this guide. |
|
Terminology |
This guide uses Client or Buyer. Some backend names and routes still use Tenant because those are the current internal identifiers. |
|
|
Important operating principle Leaseora automates and records the transaction, but the real estate company remains responsible for property ownership, listing accuracy, offer approval, legal documentation, payment verification, regulatory compliance and physical handover. |
What the module connects
· PropertyListing + SaleListing - the public sale information, asking price, currency and negotiability.
· SalesApplication - the core offer and purchase record for each buyer.
· Buyer account - identity, profile, financing choice, documents and transaction history.
· Payment channels - wallet, payment gateway or bank transfer.
· Landlord payout - the record and route used to transfer each received payment to the landlord.
· Notifications and events - real-time communication and automated workflow changes.
· Property and unit status - the final record showing the listing and property are sold.
Main roles
|
Role |
Main responsibility |
|
Real Estate Company / Landlord |
Creates listings, configures payments and payout accounts, reviews offers, approves or negotiates, verifies transfers, monitors sales and completes the transaction. |
|
Sales Officer |
Monitors enquiries and offers, communicates with buyers and prepares recommendations for approval. |
|
Finance Officer |
Confirms payments, verifies bank transfers, reconciles gateway transactions and reviews payouts. |
|
Buyer / Client |
Browses listings, submits an offer, selects a financing type, pays the deposit and balance, and tracks the purchase. |
|
Leaseora Platform Services |
Perform authorised calculations, events, notifications, payment routing, fee recording, status updates and payout processing. |
2 Module Overview and Business Value
Figure 1. Complete Property Sales / Purchases lifecycle
Business outcomes for the real estate company
· Publish verified properties for sale with structured information, media, currency and pricing.
· Give buyers a professional web and mobile journey from discovery to completion.
· Centralise all offers and prevent multiple active offers from the same buyer on one listing.
· Negotiate digitally through counter-offers while keeping a complete record.
· Collect deposits and balance payments through wallet, gateway or verified bank transfer.
· Route each confirmed payment to the landlord through the configured payout method.
· Provide management dashboards for offers, active purchases, completed sales, deposits and revenue.
· Use events and notifications to keep buyers and internal teams informed in real time.
|
|
Not only a listing feature A normal advert may stop after generating an enquiry. Leaseora continues the transaction through offer negotiation, payment, payout, status management and final sale completion. |
3 Before the Company Starts Selling
The company should complete the following setup before publishing its first sale listing. This reduces failed payments, incorrect pricing, delayed payouts and duplicate work.
Company readiness checklist
|
☐ |
Corporate Leaseora account is active and verified. |
|
☐ |
Property ownership or authority-to-sell documents are available. |
|
☐ |
Authorised staff roles and permissions have been assigned. |
|
☐ |
Sale prices, negotiability rules and approved financing options are documented. |
|
☐ |
Accepted payment gateways have been configured and tested. |
|
☐ |
An active landlord bank account or approved wallet payout destination is available. |
|
☐ |
Currency and foreign-exchange treatment have been approved by finance. |
|
☐ |
Platform-fee treatment has been understood and approved. |
|
☐ |
Standard offer, reservation, sale and completion documents are ready. |
|
☐ |
Internal rules exist for approval, counter-offers, rejection, cancellation and refunds. |
Recommended segregation of duties
|
Responsibility |
Recommended owner |
Control |
|
Create and publish listing |
Property administrator / sales manager |
Second-person review before activation. |
|
Approve or counter an offer |
Authorised sales director / management |
Decision recorded against the SalesApplication. |
|
Verify bank transfer |
Finance officer |
Compare uploaded proof with bank statement. |
|
Change payment or payout records |
Finance / authorised administrator |
Use activity logs and documented reasons. |
|
Cancel an active purchase |
Director or authorised manager |
Review legal, payment and refund consequences first. |
|
Mark sale completed |
Sales, finance and legal approval |
Confirm full payment and transaction requirements. |
4 Phase 1 - List the Property and Configure Payments
Steps 1 and 2: create the sale listing and prepare how the company will receive funds.
|
STEP |
Create a Property Listing for Sale Primary user: Real estate company / authorised listing staff |
Open the property-listing area and create or select the property that will be offered for sale. The listing must use listing_type = sale. Once reviewed and published, the listing status becomes active.
|
Field |
Purpose |
Good practice |
|
Listing type |
Identifies the transaction as a sale. |
Use Sale, not Lease or Mortgage, for this workflow. |
|
Status |
Controls whether buyers can discover the listing. |
Keep as draft or inactive until all information is approved; publish as Active. |
|
Asking price |
The seller's advertised price. |
Use the approved amount and correct listing currency. |
|
Listing currency |
The currency in which the sale is stored and settled. |
Confirm before receiving offers or payments. |
|
Price negotiable |
Controls whether negotiation is invited. |
Use only when management permits counter-offers. |
|
Title and description |
Explains what is being sold. |
Use accurate, clear and legally supportable statements. |
|
City and address |
Supports discovery and buyer understanding. |
Use consistent location information. |
|
Bedrooms / property type |
Supports search filters. |
Select the correct structured values. |
|
Images |
Shows the property and supports the listing. |
Use authorised, current, high-quality media. |
When the sale listing is created, Leaseora links the public PropertyListing to a SaleListing record containing the asking price, currency and sale-specific metadata. The underlying Property and PropertyImage records remain connected to the listing.
|
|
Publication check Only activate a property after confirming ownership or sale authority, price, currency, media, physical details and internal approval. An inaccurate active listing can create financial and legal risk. |
|
STEP |
Configure Accepted Payment Gateways and Payout Account Primary user: Finance / authorised account administrator |
The company chooses which payment channels buyers can use and where landlord payouts should be sent. The current flow supports configured gateways such as Flutterwave, Stripe, Revolut, Paystack and Squad, together with bank transfer and wallet flows.
|
Configuration |
What to complete |
Why it matters |
|
Payment gateways |
Activate only gateways approved for the company and market. |
Determines the online options shown to the buyer. |
|
Landlord bank account |
Add and verify the account used for payouts. |
Allows confirmed buyer payments to be transferred to the company. |
|
Default payout method |
Confirm the route selected by the payout resolver. |
Controls whether payout uses Embedly, Flutterwave, Revolut, Stripe, PayPal, SEPA, Solaris or wallet. |
|
Wallet fallback |
Ensure the landlord wallet is active where used. |
Receives payout when there is no active bank-account route. |
|
Settlement and reconciliation owner |
Assign finance staff to monitor gateway and payout statuses. |
Prevents a payment from being treated as fully settled before confirmation. |
|
|
Payout readiness A buyer may be able to pay even when the landlord payout destination is incomplete, but that can delay settlement. Configure and test the company payout method before accepting live purchases. |
5 Phase 2 - Buyer Discovers the Sale Listing
Steps 3 and 4: browse active listings and review the full property details.
|
STEP |
Browse Active Sale Listings Primary user: Buyer / client |
The buyer can browse active sale listings on the Leaseora web experience or mobile application. The browse query includes properties offered for sale across the platform, not only properties already associated with the buyer through a lease.
|
Filter |
Use |
|
City |
Find properties in a preferred market or location. |
|
Minimum and maximum price |
Limit results to the buyer's budget range. |
|
Bedrooms |
Find a suitable residential size. |
|
Property type |
Select apartment, house, commercial or another configured type. |
|
Price negotiable |
Show listings where the seller allows price negotiation. |
Mobile route: GET /api/mobile/property-sales/listings. The current controllers responsible for browsing are PropertySaleMobileController@listings and ListingBrowserController.
|
STEP |
View the Listing Details Primary user: Buyer / client |
The buyer opens a listing to review the complete sale information before submitting an offer.
· Property images and description.
· Asking price and listing currency.
· Property type, bedrooms, location and address information.
· Landlord or company information made available through the listing.
· Whether price negotiation is allowed.
· Whether the buyer already has an active offer on the same listing.
Mobile route: GET /api/mobile/property-sales/listings/{slug}. The listing-detail response is managed by PropertySaleMobileController@listingDetail.
|
|
One active offer per buyer per listing Leaseora prevents a buyer from creating another active offer on the same listing while an offer is Pending, Counter-offered, Approved, Deposit Paid or In Progress. This protects the integrity of the negotiation and payment process. |
6 Phase 3 - Buyer Submits a Purchase Offer
Step 5: propose a price, choose financing and upload supporting information.
|
STEP |
Submit the Offer Primary user: Buyer / client |
The buyer submits an offer from the listing page or mobile application. The offer becomes a SalesApplication with status Pending.
|
Offer field |
Meaning |
Example / control |
|
Offer amount |
The price proposed by the buyer. |
Must use the listing transaction rules and accepted currency treatment. |
|
Financing type |
How the buyer intends to fund the purchase. |
Cash, Mortgage or Instalment. |
|
Message |
Optional explanation or condition sent to the landlord. |
Keep specific and professional. |
|
Documents |
Optional evidence supporting the offer. |
PDF, DOC or image files, maximum 10 MB each under the supplied workflow. |
Supporting documents are stored under sale-applications/{tenant_id}/ in the current backend flow. The platform checks that the listing is a Sale listing and that the buyer does not already have an active offer on it.
Web: offer form on the listing page. Mobile: POST /api/mobile/property-sales/listings/{id}/offer.
What happens immediately after submission
1. A SalesApplication record is created with status Pending.
2. The buyer sees the new offer in their purchase or offer history.
3. The SaleOfferSubmitted event is fired.
4. The landlord receives a notification that a new offer requires review.
5. The listing remains active unless the company takes a later action.
|
|
Pending is not acceptance A Pending offer is a buyer proposal. It does not reserve ownership, confirm the final price or permit handover. The real estate company must review and approve the offer before the deposit stage. |
7 Phase 4 - Landlord Reviews and Responds to Offers
Steps 6 and 7: compare offers and choose approval, counter-offer or rejection.
|
STEP |
View All Offers for the Listing Primary user: Sales team / authorised management |
Open the sale-offers dashboard for the property. The company can review every SalesApplication linked to the listing together with the buyer profile and current status.
|
Dashboard information |
Business use |
|
Total offers |
Shows the overall buyer interest in the listing. |
|
Pending |
Offers waiting for a decision. |
|
Counter-offered |
Offers where the company has proposed a different amount. |
|
Approved |
The selected offer that can proceed to deposit. |
|
Rejected |
Offers that will not proceed. |
|
Deposit Paid |
Approved purchases secured by the 10% deposit. |
|
Completed |
Sales where the agreed price has been fully paid and the sale completed. |
|
Currency display |
Amounts may be shown in the landlord's preferred currency using CurrencyExchangeService. |
Backend: SalesApplicationController@index.
|
STEP |
Choose an Action on the Offer Primary user: Authorised landlord decision-maker |
Option A - Approve the offer
1. Review the buyer, offer amount, financing type, message and documents.
2. Click Approve when the company accepts the offer.
3. The selected SalesApplication changes to Approved and approved_at is recorded.
4. The SaleListing is marked as Pending Sale.
5. Other Pending or Counter-offered offers for the same listing are automatically rejected.
6. The SaleOfferApproved event fires and the buyer is notified to pay the deposit.
|
|
Approval selects one buyer Approving an offer has a direct effect on competing buyers. Staff must verify the listing, agreed price and decision authority before approval because the current workflow automatically rejects competing Pending or Counter-offered offers. |
Option B - Send a counter-offer
1. Enter the company's proposed counter_offer_amount.
2. The SalesApplication changes to Counter-offered.
3. The SaleCounterOfferSent event fires.
4. The buyer receives a SaleCounterOfferNotification and can accept or withdraw.
Option C - Reject the offer
1. Choose Reject when the company will not proceed with the offer.
2. The SalesApplication changes to Rejected and rejected_at is recorded.
3. The buyer receives the configured rejection notification.
4. Record a clear internal reason according to company policy.
Backend actions: SalesApplicationController@approve, @counterOffer and @reject.
8 Phase 5 - Buyer Responds to a Counter-Offer
Step 8: accept the revised price or withdraw from negotiation.
|
STEP |
Accept or Withdraw Primary user: Buyer / client |
|
Buyer action |
System result |
Route |
|
Accept counter-offer |
The offer_amount is replaced with the counter_offer_amount. Status changes to Approved and approved_at is recorded. The buyer is prompted to pay the 10% deposit. |
POST /api/mobile/property-sales/offers/{id}/accept-counter |
|
Withdraw offer |
Allowed while the offer is Pending or Counter-offered. Status changes to Withdrawn and the buyer leaves the negotiation. |
POST /api/mobile/property-sales/offers/{id}/withdraw |
|
|
Agreed price becomes the transaction basis Once the buyer accepts the counter-offer, the revised offer amount becomes the agreed price used for the deposit and remaining balance calculations. |
9 Phase 6 - Pay the 10% Deposit
Step 9: secure the approved purchase through wallet, gateway or verified bank transfer.
Under the current workflow supplied for this guide, the buyer must pay a deposit equal to 10% of the agreed offer amount. The deposit confirms commitment and moves the purchase into the payment stage.
|
|
Current configured rule Deposit amount = agreed offer amount x 10%. This guide preserves the current supplied workflow. Any future change to the deposit percentage should be configured and documented before use. |
|
STEP |
Deposit by Leaseora Wallet Primary user: Buyer / finance automation |
1. The buyer chooses Wallet Payment.
2. Leaseora calculates the 10% deposit in the listing currency.
3. Where the buyer wallet currency differs, the applicable FX conversion is calculated and shown.
4. FeeCalculationService calculates the property_purchase_payment platform service fee.
5. EmbedlyTenantWalletCollectionService collects from an Embedly-linked wallet where applicable.
6. The buyer wallet is debited using the wallet deduction process.
7. The fee transaction is recorded.
8. The SalesApplication records deposit_status = Paid, deposit_amount and a transaction reference such as PROP-DEP-{id}-{timestamp}.
9. The purchase status changes to Deposit Paid.
10. A LandlordPayout is created and the payout process begins.
11. PropertyDepositPaid fires and both landlord and buyer receive the relevant notifications.
Mobile route: POST /api/mobile/property-sales/purchases/{id}/pay-deposit-wallet.
|
STEP |
Deposit by Payment Gateway Primary user: Buyer / configured payment gateway |
1. The buyer selects an available gateway such as Flutterwave, Stripe, Revolut, Paystack or Squad.
2. Leaseora creates a payment session or link with sale_application_id and type = deposit metadata.
3. The transaction reference follows PROP-DEP-{saleId}-{timestamp}.
4. The buyer completes the gateway payment.
5. The gateway callback returns to Leaseora.
6. Leaseora parses the reference, verifies the transaction with the gateway API and updates the SalesApplication.
7. The deposit status and paid amount are updated, and landlord payout processing begins.
Mobile route: POST /api/mobile/property-sales/purchases/{id}/pay-deposit-gateway. Callback: GET /api/mobile/property-sales/gateway-callback.
|
STEP |
Deposit by Bank Transfer Primary user: Buyer and authorised finance officer |
1. The buyer selects Bank Transfer and uses the approved company bank details.
2. The buyer transfers the required amount and uploads proof.
3. Leaseora creates a BankTransferTransaction record.
4. Finance compares the uploaded proof with the company bank account or statement.
5. Authorised staff confirm or reject the transfer.
6. Only after confirmation are the purchase payment status and payout process updated.
Mobile route: POST /api/mobile/property-sales/purchases/{id}/pay-deposit-bank-transfer.
|
|
Uploaded proof is not final payment A screenshot or bank receipt is only evidence submitted by the buyer. Finance must verify actual receipt of funds before confirming the deposit. |
10 How Payment, Fees and Landlord Payout Work
Figure 2. Payment, fee and payout control flow
Each confirmed buyer payment creates or updates the purchase record and creates a related LandlordPayout. The payout route is selected from the company configuration and can use Embedly, Flutterwave, Revolut, Stripe, PayPal, SEPA, Solaris or the landlord wallet.
|
Stage |
What Leaseora records or performs |
|
Payment initiation |
Sale application, payment type, amount, currency, gateway or bank-transfer context and transaction reference. |
|
Currency handling |
Stores the sale in listing currency while showing converted amounts where buyer or landlord preferences differ. |
|
Fee handling |
Calculates and records the configured property_purchase_payment service fee. |
|
Purchase update |
Updates deposit or cumulative paid amount, remaining balance and purchase status. |
|
Payout creation |
Creates LandlordPayout with a reference such as PROP-MOB-PROP-DEP-... or the matching instalment pattern. |
|
Payout execution |
ProcessLandlordPayout or the relevant observer-managed flow transfers funds to the configured destination. |
|
Notifications |
Sends payment received / confirmed messages to landlord and buyer. |
|
Audit trail |
Retains transaction, fee, payout and status history for reconciliation. |
|
|
Immediate payout does not remove reconciliation The current workflow triggers landlord payout when a payment is confirmed. Finance should still monitor gateway settlement, payout success, reversals, disputes and bank reconciliation. |
11 Phase 7 - Pay the Remaining Balance
Steps 10 and 11: view the plan and complete cash, instalment or mortgage-related payments.
|
STEP |
View the Purchase Payment Plan Primary user: Buyer / client |
After the deposit is paid, the buyer opens the payment plan for the approved purchase.
|
Payment-plan information |
Meaning |
|
Total sale |
The agreed offer price in the listing currency. |
|
Paid sale |
The cumulative confirmed amount, beginning with the deposit. |
|
Remaining sale |
The unpaid balance still required for completion. |
|
Wallet balance |
Funds available in the buyer wallet where applicable. |
|
Available gateways |
Online gateways configured for the landlord and market. |
|
Bank account details |
Approved destination for bank-transfer payments. |
|
FX display |
Converted values shown when the buyer currency differs from the listing currency. |
Mobile route: GET /api/mobile/property-sales/purchases/{id}/payment-plan.
|
STEP |
Pay Instalments or Remaining Balance Primary user: Buyer / client and finance |
|
Method |
Route / reference |
Result |
|
Wallet |
POST /api/mobile/property-sales/purchases/{id}/pay-installment-wallet; reference PROP-INST-{saleId}-{timestamp} |
Fee and payout flow runs, cumulative paid amount increases and remaining balance reduces. |
|
Gateway |
POST /api/mobile/property-sales/purchases/{id}/pay-installment-gateway |
Gateway session and callback verify the payment before updating the purchase. |
|
Bank transfer |
POST /api/mobile/property-sales/purchases/{id}/pay-installment-bank-transfer |
Buyer uploads proof; finance verifies before confirmation. |
When the cumulative confirmed paid amount reaches or exceeds the agreed offer amount, the purchase automatically advances to Completed under the current supplied workflow.
Financing-type interpretation
|
Financing type |
How the module records it |
Operational note |
|
Cash |
Buyer intends to settle the agreed price without a long-term instalment structure. |
The deposit may be followed by one or more balance payments until complete. |
|
Instalment |
Buyer pays the balance in multiple payments. |
The company should communicate agreed due dates and conditions clearly. |
|
Mortgage |
Buyer intends to use mortgage finance. |
External lender approval and mortgage documentation remain separate responsibilities unless integrated into the wider Leaseora mortgage workflow. |
|
|
Payment status must follow confirmed funds Do not mark a purchase complete because the buyer submitted a payment attempt. Completion should follow successful gateway verification, confirmed wallet collection or verified bank transfer. |
12 Phase 8 - Complete the Property Sale
Steps 12 and 13: close the purchase, mark the property sold and finish payouts.
|
STEP |
Mark the Sale as Completed Primary user: System and authorised company staff |
When full payment is confirmed, the SalesApplication status becomes Completed. The PropertySaleCompleted event fires, the PropertyListing / SaleListing is marked Sold, and the underlying property or unit status is updated to Sold.
|
Completion action |
Outcome |
|
SalesApplication completed |
The buyer purchase record shows the financial transaction is complete. |
|
PropertySaleCompleted event |
Triggers the configured completion processes. |
|
Buyer notification |
PropertySaleCompletedTenantNotification confirms completion to the buyer. |
|
Landlord notification |
PropertySaleCompletedLandlordNotification confirms completion to the seller. |
|
Listing sold |
The property should no longer be offered as available for a new sale. |
|
Property / unit sold |
Inventory reflects the completed transaction. |
|
|
Financial completion and legal handover A Completed payment status records the sale workflow described here. The company must still follow its approved legal transfer, title, possession and handover process before releasing the property. |
|
STEP |
Complete the Final Landlord Payout Primary user: Finance automation and reconciliation team |
LandlordPayout records are created for each confirmed payment. ProcessLandlordPayout is dispatched synchronously or through the queue, depending on configuration, to transfer funds to the company bank account or wallet.
|
☐ |
Every payment has a transaction reference and confirmed status. |
|
☐ |
Every expected LandlordPayout record exists. |
|
☐ |
Payout method matches the landlord configuration. |
|
☐ |
Gateway or bank settlement status has been reconciled. |
|
☐ |
Failed or pending payouts have been investigated. |
|
☐ |
Platform fees and net settlement are correctly recorded. |
|
☐ |
Final revenue and payment reports match finance records. |
13 Phase 9 - Landlord Sales Dashboard and Cancellation
Steps 14 and 15: monitor the full portfolio and control exceptional cases.
|
STEP |
Monitor All Property Purchases Primary user: Directors, sales and finance |
The landlord dashboard brings all buyer purchases across all company properties into one management view. Current route: GET /landlord/property-sales.
|
Filter / statistic |
Business use |
|
Status filter |
Find Pending, Approved, Deposit Paid, In Progress, Completed, Rejected, Withdrawn or Cancelled records. |
|
Financing type |
Separate Cash, Mortgage and Instalment purchases. |
|
Deposit status |
Identify approved buyers who have or have not secured the property. |
|
Buyer search |
Find a purchase by buyer name or email. |
|
Property search |
Find all offers and purchases for a specific listing. |
|
Total purchases |
Overall number of purchase records. |
|
Pending purchases |
Offers waiting for action. |
|
Approved purchases |
Accepted offers awaiting or entering payment. |
|
Active purchases |
Deposit Paid plus In Progress transactions. |
|
Completed purchases |
Sales that have reached full payment completion. |
|
Cancelled purchases |
Purchases stopped by the landlord. |
|
Total deposit collected |
Sum of deposit amounts recorded across purchases. |
|
Total revenue |
Sum of completed sale amounts. |
Backend: LandlordPropertySalesController@index and @show.
|
STEP |
Cancel an Active Purchase Primary user: Authorised landlord management |
The supplied workflow allows the landlord to cancel a purchase in Approved, Deposit Paid or In Progress status. Cancellation changes the record to Rejected and records rejected_at.
|
☐ |
Confirm the person requesting cancellation has authority. |
|
☐ |
Review the signed agreement and cancellation terms. |
|
☐ |
Check all received payments, fees and landlord payouts. |
|
☐ |
Determine whether refund, reversal or dispute action is required. |
|
☐ |
Record the cancellation reason and supporting approval. |
|
☐ |
Notify the buyer through the approved communication process. |
|
☐ |
Update the property or unit availability only when legally and operationally appropriate. |
|
|
Cancellation may require financial recovery Changing a status does not automatically resolve funds already paid or paid out. Finance and legal teams must manage refunds, payout reversals, fees, disputes and property availability according to the applicable agreement. |
Backend: LandlordPropertySalesController@cancel.
14 Complete Status Lifecycle and Business Meaning
Figure 3. Offer and purchase status flow
|
Status |
Meaning |
Who normally acts next |
|
Pending |
Buyer submitted an offer; company has not decided. |
Sales / authorised landlord reviewer. |
|
Counter-offered |
Landlord proposed a revised price. |
Buyer accepts or withdraws. |
|
Approved |
Agreed offer can proceed to deposit. |
Buyer pays 10% deposit. |
|
Deposit Paid |
Deposit has been confirmed and landlord payout is initiated. |
Buyer and finance continue remaining balance. |
|
In Progress |
The purchase is actively receiving balance payments. |
Buyer pays; finance verifies and reconciles. |
|
Completed |
Full agreed amount has been confirmed. |
Company completes legal transfer and handover. |
|
Withdrawn |
Buyer ended a Pending or Counter-offered offer. |
No payment stage; listing remains available subject to other offers. |
|
Rejected |
Landlord declined, a competing offer lost, or an active purchase was cancelled under the supplied status behaviour. |
Company manages communication and any financial consequences. |
|
|
Status accuracy is essential Dashboards, notifications, payment access, payout processing and listing availability depend on the correct status. Staff should not change statuses outside the approved workflow. |
15 Events and Notification Matrix
Events connect business actions to automated notifications and follow-up processes. The following matrix preserves the supplied workflow names.
|
Trigger |
Event |
Primary notification / result |
|
Buyer submits offer |
SaleOfferSubmitted |
Landlord receives a new-offer notification. |
|
Landlord approves |
SaleOfferApproved |
SaleOfferApprovedNotification tells buyer to pay deposit; competing offers are rejected. |
|
Landlord counter-offers |
SaleCounterOfferSent |
SaleCounterOfferNotification tells buyer the revised amount. |
|
Buyer pays confirmed deposit |
PropertyDepositPaid |
PropertyDepositReceivedNotification to landlord and PropertyDepositConfirmedNotification to buyer; payout starts. |
|
Full payment confirmed |
PropertySaleCompleted |
PropertySaleCompletedLandlordNotification and PropertySaleCompletedTenantNotification; listing and unit become sold. |
|
|
Notification does not replace staff judgement Automated notifications improve speed and consistency, but staff should personally manage complex negotiations, failed payments, cancellations, disputes and legal completion. |
16 Multi-Currency, Fees and Reconciliation Controls
The supplied workflow stores the sale in listing currency and can display converted values to buyers or landlords in their preferred currency. CurrencyExchangeService supports the conversion flow.
|
Control area |
How it works |
Company responsibility |
|
Listing currency |
Asking price and agreed sale are stored in the listing currency. |
Choose the correct currency before publication. |
|
Buyer wallet currency |
Conversion applies where wallet currency differs from listing currency. |
Explain the displayed conversion and any applicable rate timing. |
|
Landlord preferred currency |
Dashboard amounts may be displayed through FX conversion. |
Use listing-currency records for transaction reconciliation. |
|
Platform service fee |
FeeCalculationService calculates and records the property_purchase_payment fee. |
Understand the fee basis and net settlement. |
|
Gateway fee / settlement |
External gateway terms may affect timing or net amount. |
Reconcile gateway reports and bank settlement. |
|
Payout status |
LandlordPayout tracks transfer to bank or wallet. |
Monitor Pending, Successful or Failed outcomes and investigate exceptions. |
17 Staff Roles, Permissions and Approval Controls
|
Role |
Typical access |
Key restriction |
|
Listing Administrator |
Create and edit PropertyListing and SaleListing data. |
Should not approve their own price exception without authorisation. |
|
Sales Officer |
Review buyer details, communicate and prepare recommendations. |
Should not confirm bank settlement or payout. |
|
Sales Director / Approver |
Approve, counter or reject offers. |
Must understand automatic rejection of competing offers. |
|
Finance Officer |
Verify transfers, reconcile gateways, fees and payouts. |
Should not change sale price without management approval. |
|
Compliance / Legal |
Review buyer documents, sale terms and cancellation implications. |
AI or uploaded documents do not replace legal review. |
|
Customer Support |
Assist buyers with navigation, notifications and evidence submission. |
Should not approve offers, waive funds or confirm settlement. |
|
Company Director |
Approve cancellations, exceptional refunds and final completion controls. |
Use audit trail and documented decisions. |
Recommended security controls
· Use individual staff accounts and avoid shared passwords.
· Enable two-factor authentication where available.
· Limit approval, cancellation and finance actions to authorised roles.
· Require a documented reason for rejection, cancellation, fee adjustment or payment correction.
· Review activity logs for sensitive actions.
· Remove staff access promptly when duties change or employment ends.
18 Worked Example - One Property Sale from Listing to Completion
|
|
Scenario Harbour Homes Limited lists a four-bedroom terrace for 150,000,000 in the listing currency. The seller allows negotiation. Buyer Chidi submits a cash offer of 140,000,000. The landlord counter-offers 145,000,000, which Chidi accepts. |
|
Stage |
What happens in Leaseora |
|
1. Listing |
Harbour Homes creates an active Sale listing with price 150,000,000, correct currency, images and property details. |
|
2. Discovery |
Chidi finds the listing using city, price and property-type filters. |
|
3. Offer |
Chidi submits 140,000,000 with financing_type = Cash. SalesApplication status: Pending. |
|
4. Counter-offer |
The landlord proposes 145,000,000. Status: Counter-offered; notification sent. |
|
5. Acceptance |
Chidi accepts. offer_amount becomes 145,000,000. Status: Approved. |
|
6. Deposit |
The 10% deposit is 14,500,000. Chidi pays through a configured gateway. Payment verifies and status becomes Deposit Paid. |
|
7. Payout |
A LandlordPayout is created for the confirmed deposit and routed to Harbour Homes. |
|
8. Balance |
Chidi pays the remaining 130,500,000 through one or more confirmed balance payments. |
|
9. Completion |
Cumulative paid amount reaches 145,000,000. Status becomes Completed; listing and property are marked Sold. |
|
10. Finalisation |
Harbour Homes reconciles payouts, completes legal transfer and hands over the property. |
|
|
Calculation check Agreed price 145,000,000. Deposit 10% = 14,500,000. Remaining balance = 130,500,000. All values remain in the explicit listing currency; no currency conversion is assumed in this example. |
19 Management Reporting and Review Rhythm
|
Frequency |
Recommended review |
|
Daily |
New offers, counter-offer responses, approved offers awaiting deposit, unverified transfers and failed gateway payments. |
|
Weekly |
Offer conversion, active purchases, overdue balance payments, payout exceptions and listing availability. |
|
Monthly |
Deposits collected, completed revenue, gateway reconciliation, platform fees, payout settlement and cancelled purchases. |
|
Before approval |
Buyer profile, offer amount, financing type, documents, unit availability and competing offers. |
|
Before cancellation |
Agreement terms, funds received, payouts made, refund obligations, disputes and unit-release decision. |
|
Before completion |
Full payment confirmation, final payout, listing status, property status and legal handover readiness. |
Management reports are only reliable when staff record decisions and confirm transactions through the correct workflow rather than keeping material information only in email, WhatsApp or spreadsheets.
20 Common Issues and Troubleshooting
|
Issue |
Recommended action |
|
Sale listing does not appear |
Confirm listing_type = sale, status = active and required property information is complete. |
|
Buyer cannot submit an offer |
Check the listing is active and the buyer has no active offer in Pending, Counter-offered, Approved, Deposit Paid or In Progress status. |
|
Wrong currency is displayed |
Review listing_currency, buyer preference and CurrencyExchangeService configuration. |
|
Counter-offer cannot be accepted |
Confirm the SalesApplication is still Counter-offered and has not been rejected, withdrawn or superseded. |
|
Deposit amount looks incorrect |
Confirm the agreed offer amount after counter-offer and apply the current 10% rule. |
|
Wallet payment fails |
Check wallet balance, currency conversion, wallet linkage and transaction error details. |
|
Gateway payment remains pending |
Review gateway verification, callback reference and gateway API response. |
|
Bank transfer is not confirmed |
Finance must verify the uploaded proof against actual bank receipt. |
|
Landlord payout is missing |
Check LandlordBankAccount, default payout method, LandlordPayout record and ProcessLandlordPayout status. |
|
Property remains active after completion |
Verify PropertySaleCompleted processing, SaleListing status and property/unit status update. |
|
Competing offer was rejected |
This is expected when another offer on the same listing is approved under the supplied workflow. |
|
Cancellation completed but funds remain unresolved |
Finance and legal teams must manage refund, payout reversal, dispute and agreement consequences separately. |
|
|
Support information to provide When contacting Leaseora Support, include the company name, property listing ID or slug, SalesApplication ID, buyer email, transaction reference, gateway, status and a clear description of the error. Do not send passwords or full sensitive payment credentials. |
21 Frequently Asked Questions
Can a buyer negotiate the price?
Yes, where the listing is marked price negotiable. The landlord can counter-offer, and the buyer can accept or withdraw.
Can one buyer submit several offers on the same property?
Not while they already have an active offer in Pending, Counter-offered, Approved, Deposit Paid or In Progress status.
What happens to other offers when one is approved?
Other Pending or Counter-offered offers for the same listing are automatically rejected.
Is the deposit always 10%?
The supplied current workflow uses a 10% deposit. Any future configurable change should be documented before use.
Can buyers pay in instalments?
Yes. Instalment is a supported financing type, and balance payments can be made through wallet, gateway or bank transfer.
Can buyers use mortgage financing?
Mortgage is a supported financing type. External lender approval and mortgage-specific legal processes still apply.
Can a buyer pay from a different currency wallet?
Yes, where the configured currency-conversion and wallet services support the transaction. The sale remains stored in listing currency.
Does Leaseora pay the landlord after every buyer payment?
The supplied workflow creates a LandlordPayout for each confirmed payment and triggers the configured payout process.
What happens if the landlord has no active bank account?
The supplied wallet flow can credit the landlord wallet as a fallback.
Is uploaded bank proof enough?
No. Finance must verify the actual funds before confirming payment.
Can a landlord cancel after deposit?
The supplied workflow permits cancellation in Approved, Deposit Paid or In Progress status, but legal, refund and payout consequences must be handled.
Does Completed mean the buyer automatically receives title?
No. Completed records the platform sale-payment workflow. The company must still complete legal transfer and physical handover requirements.
22 Implementation and Go-Live Checklist
Listing and sales data
|
☐ |
Property records and ownership or sale-authority documents are ready. |
|
☐ |
Asking prices, currencies and negotiability rules are approved. |
|
☐ |
Property descriptions, addresses, types, bedrooms and images are complete. |
|
☐ |
Cash, mortgage and instalment policies are documented. |
|
☐ |
Offer-approval and counter-offer authority is assigned. |
Payments and payouts
|
☐ |
Accepted gateways are configured and tested. |
|
☐ |
Landlord bank account is active and verified. |
|
☐ |
Default payout method is confirmed. |
|
☐ |
Wallet fallback is available where required. |
|
☐ |
Fee and FX treatment is understood by finance. |
|
☐ |
Bank-transfer verification process is documented. |
|
☐ |
Gateway and payout reconciliation owners are assigned. |
Test transaction
|
☐ |
Test sale listing is active and visible on web and mobile. |
|
☐ |
Test buyer can view details and submit an offer. |
|
☐ |
Landlord can approve, counter and reject correctly. |
|
☐ |
Buyer can accept a counter-offer and withdraw when permitted. |
|
☐ |
Deposit calculation equals 10% of agreed price. |
|
☐ |
Wallet, gateway and bank-transfer flows are tested where enabled. |
|
☐ |
LandlordPayout is created and status can be monitored. |
|
☐ |
Full payment changes the purchase and listing to Completed / Sold. |
|
☐ |
Notifications reach the correct parties. |
23 Quick Reference - The Entire Process in 15 Actions
1. Create and activate the Sale listing.
2. Configure payment gateways, landlord bank account and payout method.
3. Buyer browses and opens the listing.
4. Buyer submits amount, financing type, message and optional documents.
5. Landlord reviews all offers and buyer profiles.
6. Landlord approves, counter-offers or rejects.
7. Buyer accepts the counter-offer or withdraws where applicable.
8. Approved buyer pays the 10% deposit.
9. Leaseora records fees, status, transaction and LandlordPayout.
10. Buyer views the remaining payment plan.
11. Buyer pays the balance through wallet, gateway or bank transfer.
12. Finance verifies and reconciles every payment and payout.
13. Full payment changes the SalesApplication to Completed.
14. Listing and property / unit are marked Sold.
15. Company completes legal transfer and physical handover.
|
|
Core value The Property Purchases module gives the real estate company one controlled record for listing, negotiation, buyer commitment, payment collection, landlord settlement and final sale completion. |
Appendix A Technical Reference - Models, Controllers, Services and Jobs
This appendix preserves the backend identifiers supplied for the current Leaseora workflow. It is intended for product, technical, support and implementation teams.
|
Component |
Purpose |
|
PropertyListing |
Stores the main property listing, listing type, status and discoverable property information. |
|
SaleListing |
Stores sale-specific asking price, currency and sale metadata. |
|
Property |
Underlying property record linked to the listing. |
|
PropertyImage |
Images linked to the property or listing. |
|
SalesApplication |
Core model tracking every buyer offer and purchase lifecycle. |
|
PaymentGateway |
Configured online payment gateway records. |
|
LandlordBankAccount |
Landlord bank details used for payouts. |
|
Wallet |
Buyer wallet for payments and landlord wallet for payout fallback. |
|
LandlordPayout |
Tracks each payout created for a buyer payment. |
|
BankTransferTransaction |
Tracks uploaded bank-transfer proof and manual verification. |
|
Transaction / Payment |
Records payment activity and references. |
|
Controller / service / job |
Current responsibility |
|
PropertySaleMobileController |
Buyer mobile flows: browse, detail, offer, counter acceptance, withdrawal, deposit, instalment and payment plan. |
|
ListingBrowserController |
Web listing browsing. |
|
SalesApplicationController |
Landlord offer list, approve, counter-offer and reject. |
|
LandlordPropertySalesController |
Landlord portfolio dashboard, detail and cancellation. |
|
CurrencyExchangeService |
FX conversion and preferred-currency display. |
|
FeeCalculationService |
Platform fee calculation and fee transaction recording. |
|
PaymentGatewayFactory |
Creates the configured gateway implementation. |
|
EmbedlyTenantWalletCollectionService |
Collects from an Embedly-linked buyer wallet. |
|
LandlordPaymentMethodResolver |
Determines the landlord payout route. |
|
PaymentGatewayService::getDefaultPayoutMethodForLandlord() |
Returns the configured default payout method. |
|
ProcessLandlordPayout |
Executes or queues the landlord payout. |
Appendix B Technical Reference - Routes, Events, Notifications and References
|
Buyer/mobile route |
Purpose |
|
GET /api/mobile/property-sales/listings |
Browse active Sale listings. |
|
GET /api/mobile/property-sales/listings/{slug} |
View listing detail. |
|
POST /api/mobile/property-sales/listings/{id}/offer |
Submit a purchase offer. |
|
POST /api/mobile/property-sales/offers/{id}/accept-counter |
Accept a landlord counter-offer. |
|
POST /api/mobile/property-sales/offers/{id}/withdraw |
Withdraw a Pending or Counter-offered offer. |
|
POST /api/mobile/property-sales/purchases/{id}/pay-deposit-wallet |
Pay 10% deposit from wallet. |
|
POST /api/mobile/property-sales/purchases/{id}/pay-deposit-gateway |
Create deposit gateway payment. |
|
POST /api/mobile/property-sales/purchases/{id}/pay-deposit-bank-transfer |
Upload deposit bank-transfer proof. |
|
GET /api/mobile/property-sales/gateway-callback |
Verify gateway deposit or instalment transaction. |
|
GET /api/mobile/property-sales/purchases/{id}/payment-plan |
View total, paid, remaining and payment options. |
|
POST /api/mobile/property-sales/purchases/{id}/pay-installment-wallet |
Pay balance from wallet. |
|
POST /api/mobile/property-sales/purchases/{id}/pay-installment-gateway |
Pay balance through gateway. |
|
POST /api/mobile/property-sales/purchases/{id}/pay-installment-bank-transfer |
Upload balance bank-transfer proof. |
|
Event |
Related notification / result |
|
SaleOfferSubmitted |
Landlord notified of new offer. |
|
SaleOfferApproved |
SaleOfferApprovedNotification to buyer; competing offers rejected. |
|
SaleCounterOfferSent |
SaleCounterOfferNotification to buyer. |
|
PropertyDepositPaid |
PropertyDepositReceivedNotification to landlord and PropertyDepositConfirmedNotification to buyer. |
|
PropertySaleCompleted |
PropertySaleCompletedLandlordNotification and PropertySaleCompletedTenantNotification; sold status updates. |
|
Reference pattern |
Use |
|
PROP-DEP-{saleId}-{timestamp} |
Deposit transaction reference. |
|
PROP-INST-{saleId}-{timestamp} |
Instalment or balance payment reference. |
|
PROP-MOB-PROP-DEP-... |
Landlord payout reference for a mobile property-deposit payment. |
|
sale-applications/{tenant_id}/ |
Current storage path for buyer supporting documents. |
|
|
Implementation caution Backend names, routes, supported gateways, deposit rules and service behaviour can change as Leaseora evolves. Product and technical teams should compare this guide with the deployed version before configuration, training or release. |
Appendix C Glossary
|
Term |
Meaning |
|
Active listing |
A published sale listing visible to buyers. |
|
Asking price |
The seller's advertised price before negotiation. |
|
Counter-offer |
A revised price proposed by the landlord in response to a buyer offer. |
|
SalesApplication |
The central record for the buyer offer and purchase lifecycle. |
|
Agreed price |
The approved offer amount or accepted counter-offer amount. |
|
Deposit |
The initial 10% payment required by the current supplied workflow. |
|
Cumulative paid amount |
All confirmed deposit and balance payments recorded against the purchase. |
|
Listing currency |
The currency in which the sale is stored. |
|
FX conversion |
Display or payment conversion where buyer or landlord preference differs from listing currency. |
|
Platform fee |
The configured property_purchase_payment fee calculated and recorded by Leaseora. |
|
LandlordPayout |
A record of funds being transferred to the landlord bank account or wallet. |
|
Gateway callback |
The return request used to verify an online payment with the gateway. |
|
Bank-transfer proof |
Evidence uploaded by the buyer; it requires finance verification. |
|
Completed |
The platform status reached when the full agreed amount is confirmed. |
|
Sold |
The listing and property status after successful sale completion. |
LEASEORA
PROPERTY SALES & PURCHASES
From buyer discovery to completed sale - managed in one connected platform.
|
|
Support and onboarding For company account setup, payment configuration, staff training or operational assistance, contact Leaseora through support@leaseora.com. |
leaseora.com
Was this article helpful?
Your feedback helps us improve our documentation.