PAYMENTS MANAGEMENT
The Payments module is Leaseora's cross-module transaction hub. It connects payment obligations from leases, property purchases, We Build for You, land sales, wallet activity, utilities and Lease Angel to collection, verification, fees, landlord payout, notifications, receipts, analytics and reconciliation.
|
LEASEORA PAYMENTS MANAGEMENT Detailed User and Technical Operations Guide Schedules • Rent • Property Sales • We Build For You • Land • Wallet • Bank Transfer • Fees • Payouts • Reminders • Refunds • Analytics |
For real estate companies, finance teams, property managers, client-support teams, operations staff and technical administrators
Version 1.0 | July 2026
|
|
Purpose of this guide This guide explains how a real estate company uses Leaseora's Payments module to configure payment infrastructure, generate obligations, collect through three payment channels, calculate fees, update module records, pay landlords, manage reminders and exceptions, process refunds, analyse performance and reconcile the full money flow. Technical model names retain Tenant where that is part of the supplied backend design. |
1 Purpose, Audience and Scope
The Payments module is Leaseora's cross-module transaction hub. It connects payment obligations from leases, property purchases, We Build For You, land sales, wallet activity, utilities and Lease Angel to collection, verification, fees, landlord payout, notifications, receipts, analytics and reconciliation.
|
Item |
Description |
|
Primary users |
Real estate company finance administrators, property managers, accounts receivable staff, operations teams, client-support teams, authorised technical users and management. |
|
Core payment channels |
Payment gateway, Leaseora wallet and bank transfer with proof and approval. |
|
Connected modules |
Lease Management, Property Sales, We Build For You, Property Development, Land Management, Wallet, Accounting, Finance, Utilities and Lease Angel. |
|
Client terminology |
This guide uses Client or Buyer in user-facing explanations. Technical class and route names may retain Tenant. |
|
Operational boundary |
Leaseora manages the workflow and records. External provider settlement, banking availability, chargebacks and legal ownership remain dependent on the provider, bank, contract and jurisdiction. |
|
|
Control principle A payment should be marked paid only after the applicable channel has produced reliable evidence: provider verification, wallet debit confirmation or approved bank-transfer proof. |
What the module controls
· Obligation - what is due, when, to whom and in which currency.
· Collection - gateway, wallet or verified bank transfer.
· Verification - reference, amount, currency and payment status.
· Allocation - the correct lease, sale, booking or instalment.
· Fees - the correct platform-fee type and value.
· Payout - landlord destination, status and audit trail.
· Communication - confirmation, receipt, reminder and overdue notice.
· Reporting - collection rate, revenue, overdue risk and reconciliation.
2 Payments Module Architecture
Figure 1. Payments as the cross-module hub
|
Layer |
Purpose |
|
Infrastructure |
Gateways, landlord bank accounts, wallet, late-fee rules and auto-collection. |
|
Schedules |
Payment, PropertyDevelopmentPaymentPlan, LandPaymentPlan and LandPaymentInstallment. |
|
Client channels |
Gateway, wallet and bank transfer. |
|
Services |
Currency conversion, fee calculation, payment gateway resolution, recording and payout. |
|
Business updates |
Lease, SalesApplication, WeBuildTenantBooking, land sale and instalment status. |
|
Outputs |
Receipts, notifications, events, analytics, audit and financial records. |
3 Roles, Permissions and Segregation of Duties
|
Role |
Responsibility |
Control |
|
Finance Administrator |
Configures gateways, fees, bank accounts, payout rules and reports. |
Should not unilaterally verify their own offline receipts where separation is possible. |
|
Property Manager |
Reviews property payments, sends reminders and supports clients. |
Access should be limited to assigned properties. |
|
Accounts Receivable Officer |
Monitors schedules, overdue amounts and allocation. |
Write-offs and waivers require approval. |
|
Bank Transfer Verifier |
Reviews proof and bank evidence. |
Must confirm bank receipt, not just an uploaded screenshot. |
|
Payout Administrator |
Reviews failed or manual payouts. |
Should not change client payment status without evidence. |
|
Technical Administrator |
Maintains callbacks, webhooks, queues and gateway integrations. |
Should not have routine authority to issue refunds. |
|
Management |
Reviews collection, risk, revenue and exceptions. |
Uses approved reports and reconciled figures. |
|
|
Recommended segregation Separate payment initiation, bank-transfer verification, manual marking, refund approval, payout processing and reconciliation wherever staffing allows. |
4 End-to-End Payments Lifecycle
Figure 2. End-to-end Payments lifecycle
The business workflow begins before a client reaches checkout. A valid payment depends on correct infrastructure, an accurate payment schedule, an eligible channel, a unique reference, reliable verification, correct fee and payout handling, and final reconciliation.
5 Phase 1 - Configure Payment Gateways
|
STEP |
Configure Accepted Payment Gateways Primary user: Landlord finance administrator |
Navigate to Payment Gateways -> Configure. Select from the gateways enabled by SuperAdmin, enter the landlord credentials, test each connection, activate eligible gateways and set a default where appropriate.
|
Configuration item |
Operational purpose |
|
Enabled gateway |
Must first be available to the landlord through the platform Payment Gateway module. |
|
API credentials |
Landlord-specific provider credentials where required. |
|
Default gateway |
Preferred provider; routing or failover may still select another. |
|
Active status |
Controls whether clients can use the gateway. |
|
Property assignment |
PropertyPaymentGateway limits options per property. |
|
Connection test |
Confirms connectivity and configuration before client use. |
|
☐ |
Sandbox and production credentials are not mixed. |
|
☐ |
The provider account supports the property country and currency. |
|
☐ |
Callback and webhook URLs are registered. |
|
☐ |
The gateway is active and tested. |
|
☐ |
At least one fallback or alternative collection method exists. |
|
|
Related guide Detailed platform registration, health monitoring and gateway failover are covered in the separate Leaseora Payment Gateway Module guide. This guide focuses on business payment operations. |
6 Configure Late Fees and Automatic Collection
|
STEP |
Set Late-Fee and Auto-Collection Rules Primary user: Landlord finance administrator |
Use PropertyPaymentController@configureLateFees and @toggleAutoCollection to define how overdue rent and recurring collection should operate.
|
Setting |
Meaning |
Control |
|
Late-fee type |
Flat amount or percentage. |
Use contractually permitted values. |
|
Grace period |
Number of days after the due date before a fee applies. |
Match the lease and local law. |
|
Auto-collection |
Automatically attempts recurring payment on the due date. |
Use only a recurring-capable gateway and valid authorisation. |
|
Gateway test |
Checks the connection. |
Retest after credential or webhook changes. |
|
Webhook URL |
Provider notification endpoint. |
Register and verify the exact production URL. |
|
|
Late-fee caution A configured fee does not automatically make it legally enforceable. The lease, notice process and jurisdiction must permit the charge. |
7 Configure Landlord Bank Accounts
|
STEP |
Add and Verify Payout Bank Accounts Primary user: Landlord finance administrator |
Use LandlordBankAccountController@store to add each authorised settlement account and @setPrimary to select the default payout account.
|
Field |
Purpose |
|
Bank name |
Identifies the financial institution. |
|
Account number |
Destination account for payout. |
|
Account name |
Beneficiary name. |
|
Country |
Determines verification and payout support. |
|
Currency |
Currency accepted by the account. |
|
Primary status |
Default destination used by the resolver. |
|
Verification status |
Confirms account details through the configured API. |
|
☐ |
Account belongs to the landlord or authorised receiving entity. |
|
☐ |
Name and account number are verified. |
|
☐ |
Currency matches expected payouts or an approved conversion process. |
|
☐ |
Primary status is assigned deliberately. |
|
☐ |
Changes require approval and audit evidence. |
|
|
Fallback behaviour According to the supplied workflow, when no active bank account is available, the payout may be credited to the landlord wallet. Confirm the deployed rule before onboarding. |
8 Payment Records and Core Statuses
Payment is the core rent-payment record. Each record links the obligation to a lease, client, landlord and property and tracks the collection result.
|
Field |
Purpose |
|
lease_id |
Lease that created the obligation. |
|
tenant_id |
Technical identifier for the client. |
|
landlord_id |
Receiving landlord. |
|
property_id |
Property context. |
|
amount / currency |
Contractual amount and currency. |
|
due_date |
Date payment is due. |
|
status |
Pending, paid, overdue, partial or waived; refund states may also apply in the refund flow. |
|
payment_method |
Gateway, wallet, bank transfer, cash or other approved method. |
|
transaction_reference |
Unique reference for tracking and callbacks. |
|
paid_at |
Confirmed payment timestamp. |
Figure 3. Payment and payout status lifecycle
|
|
Status definitions require confirmation The supplied scenario lists pending, paid, overdue, partial and waived for Payment, plus refunded and partial_refund for the refund flow. Confirm the exact deployed enum and transition rules. |
9 Phase 2 - Lease Payment Schedule Generation
|
STEP |
Generate a Lease Payment Schedule Primary user: Lease system / landlord |
When a lease is activated, LeaseController@generatePaymentSchedule creates all rent obligations from the start date, end date and payment frequency.
1. Confirm the active lease dates and rent amount.
2. Read the payment frequency: monthly, weekly, bi-weekly or quarterly.
3. Calculate each due date through the lease term.
4. Create one Payment record per due date.
5. Set each new record to pending.
6. Link the payment to the lease, client, landlord and property.
7. Display the resulting schedule to both parties.
8. Review edge cases such as partial periods and lease amendments.
|
|
Schedule is the source obligation Do not create a second manual rent payment for a due date that already exists. Correct the schedule or allocation instead. |
10 Development and Land Payment Schedules
|
STEP |
Generate Development Instalments Primary user: We Build For You / Property Development system |
TenantWeBuildController@bookUnit and PreLeasingController@storeApplication generate PropertyDevelopmentPaymentPlan records with amount, due date, status and instalment number.
|
STEP |
Generate Land Instalments Primary user: Land Management system |
LandManagementController@storeManualSale can create a LandPaymentPlan containing total, deposit, balance, frequency and duration, then generate LandPaymentInstallment records for each due date.
|
Schedule type |
Core record |
Typical fields |
|
Lease rent |
Payment |
Amount, currency, due date, status and lease identifiers. |
|
Development / WeBuild |
PropertyDevelopmentPaymentPlan |
Instalment number, amount, due date and status. |
|
Land sale |
LandPaymentPlan + LandPaymentInstallment |
Total, deposit, balance, duration, frequency and individual due dates. |
11 Phase 3 - Client Payment Dashboard
|
STEP |
Review Upcoming and Historical Payments Primary user: Client - web or mobile |
Tenant\RentPaymentController@index and Mobile\RentPaymentController@index present obligations across active leases. Mobile lease endpoints provide schedule, history and statistics.
|
Dashboard area |
What the client sees |
|
Upcoming |
Due date, amount, property and available payment methods. |
|
History |
Paid, partial, overdue and waived records. |
|
Reminders |
Upcoming or overdue notices. |
|
Annual summary |
Total paid, on-time rate and late payments. |
|
Payment stats |
Total paid this year, total overdue, next due amount and date. |
|
Payment streak |
Consecutive on-time payments according to the deployed calculation. |
|
|
Display currency versus processing currency The client may see a preferred-currency display, while the payment is processed and stored in the property or listing currency. |
12 Phase 4 - Three Rent Payment Channels
Figure 4. Three payment channels and common completion controls
Gateway, wallet and bank transfer lead to the same business objective, but the evidence, timing and exception handling differ.
13 Method A - Rent Payment by Gateway
|
STEP |
Initiate and Verify a Gateway Rent Payment Primary user: Client and payment services |
1. Client selects an eligible configured gateway.
2. Mobile\RentPaymentController@initiate creates the payment attempt.
3. PaymentGatewayFactory resolves the correct gateway implementation.
4. gateway@processPayment receives the payment payload.
5. Generate RENT-{leaseId}-{timestamp}.
6. Redirect the client to the provider page.
7. Receive the mobile callback or gateway callback.
8. gateway@verifyPayment confirms the transaction with the provider API.
9. Confirm reference, amount, currency, status and lease metadata.
10. Set Payment.status to paid and paid_at to the verified time.
11. Trigger receipt, notification and payout actions.
|
Verification item |
Why it matters |
|
Leaseora reference |
Links the provider transaction to the correct lease. |
|
Provider reference |
Supports provider lookup and reconciliation. |
|
Amount |
Prevents underpayment or tampering. |
|
Currency |
Prevents wrong-currency completion. |
|
Status |
Distinguishes successful, failed and uncertain outcomes. |
|
Merchant / destination |
Confirms the payment reached the intended account. |
|
Idempotency |
Prevents duplicate completion on repeated callbacks. |
|
|
Redirect is not verification Do not mark a payment paid because the client returns to a success page. Verify directly with the gateway API or trusted webhook. |
14 Gateway Rent Payment and Foreign Exchange
CurrencyService and ExchangeRateService support conversion when the client currency differs from the property currency.
1. Determine the client preferred currency.
2. Determine the property currency from the property country or listing.
3. Convert the display amount for the client.
4. Present the exchange rate and any applicable fee where the user interface supports it.
5. Process the payment in the property listing currency according to the supplied workflow.
6. Store the original property-currency amount.
7. Retain rate and converted display context for explanation and reporting where implemented.
|
|
Rate movement and rounding Confirm the rate source, timestamp, rounding rule, markup and how long a quoted rate remains valid. |
15 Method B - Rent Payment by Wallet
The wallet flow combines balance validation, FX conversion, fee calculation, wallet debit and immediate payout creation.
1. Client selects Pay with Wallet.
2. Check wallet status and available balance.
3. Convert the property amount when the wallet currency differs.
4. FeeCalculationService calculates the rent_payment service fee.
5. Confirm total debit: payment amount plus applicable fee.
6. wallet->deductFunds debits the client wallet.
7. recordFeeTransaction stores the platform fee.
8. Set Payment.status to paid and record the payment method.
9. Create a LandlordPayout with RENT-MOB-{leaseId}-{timestamp}.
10. Dispatch ProcessLandlordPayout.
11. Send payment confirmation and provide the receipt.
|
|
Atomicity Wallet debit, payment completion, fee record and payout creation should be handled so that a partial system failure does not create inconsistent balances. |
16 Method C - Rent Payment by Bank Transfer
Bank transfer is a two-stage evidence workflow. The client uploads proof, but the payment remains unconfirmed until the landlord verifies actual receipt.
1. Client opens the bank-transfer payment option.
2. Display the correct landlord account and transfer instructions.
3. Client completes the transfer outside Leaseora.
4. Client uploads proof through uploadBankTransferProof.
5. Create BankTransferTransaction with pending status.
6. Send LeasePaymentProofUploadedNotification to the landlord.
7. Landlord reviews the bank statement, reference, amount and currency.
8. Approve the bank-transfer payment only after receipt is confirmed.
9. Set Payment.status to paid and record approval evidence.
10. Client checks status through getBankTransferPaymentStatus.
11. Generate confirmation and receipt.
|
|
Uploaded proof is not settlement Screenshots and receipts can be incorrect, duplicated or falsified. Verify the bank credit before approval. |
17 Payment Confirmation, Notifications and Receipts
|
STEP |
Confirm the Payment and Issue Evidence Primary user: System and finance operations |
|
Output |
Recipient / purpose |
|
LeasePaid |
Client confirmation that rent was paid. |
|
LeasePaymentReceivedNotification |
Landlord notification of rent received. |
|
TenantPaymentConfirmation |
Detailed client confirmation and receipt context. |
|
Mobile receipt |
Downloadable transaction receipt. |
|
PDF receipt |
Formal PDF version for client records. |
|
Landlord payment receipt |
Landlord-side receipt download. |
|
☐ |
Reference and payment date are present. |
|
☐ |
Property, lease and client are correct. |
|
☐ |
Amount, currency and payment method are correct. |
|
☐ |
Fee is shown separately where required. |
|
☐ |
Receipt cannot be generated twice with conflicting data. |
|
☐ |
Refunds or reversals are visible on later statements. |
18 Phase 5 - Property Purchase Deposit
|
STEP |
Collect the 10% Property Deposit Primary user: Buyer and Property Sales module |
After an offer is approved, the supplied workflow calculates deposit_amount as offer_amount x 10%. The buyer can pay through wallet, gateway or bank transfer.
1. Confirm the approved SalesApplication and offer amount.
2. Calculate the 10% deposit.
3. Calculate the property_purchase_payment platform fee.
4. Generate PROP-DEP-{saleId}-{timestamp}.
5. Process through the selected channel.
6. Verify or approve the transaction.
7. Set SalesApplication.deposit_status to paid.
8. Set SalesApplication.status to deposit_paid.
9. Trigger the landlord payout using the sale-payment payout flow.
10. Send PropertyDepositReceivedNotification to the landlord.
11. Send PropertyDepositConfirmedNotification to the buyer.
|
|
Deposit rule The 10% value is based on the supplied implementation. Confirm whether it is configurable and whether taxes or fees are included before production training. |
19 Property Purchase Instalments and Completion
|
STEP |
Pay the Remaining Property Purchase Balance Primary user: Buyer and Property Sales module |
PropertySaleMobileController uses PROP-INST-{saleId}-{timestamp} for instalment payments. The cumulative paid amount is updated after each verified payment.
1. Select the outstanding amount or allowed instalment.
2. Process wallet, gateway or bank transfer.
3. Verify reference and SalesApplication ID.
4. Update the cumulative paid amount.
5. Record the fee and landlord payout.
6. Confirm that the cumulative amount does not exceed the approved offer without a documented reason.
7. When cumulative paid is at least the offer amount, set status to completed.
8. Fire PropertySaleCompleted.
9. Mark PropertyListing, SaleListing and related unit sold according to the sales workflow.
10. Send completion notifications and preserve final receipts.
The mobile gateway callback parses PROP-DEP and PROP-INST references to identify the correct payment action.
|
|
Financial completion versus legal handover Full payment status does not by itself prove legal title transfer or physical handover. Those actions remain governed by the signed documents and sales process. |
20 Phase 6 - We Build For You Down Payment
|
STEP |
Pay the WeBuild Down Payment Primary user: Client and We Build For You module |
1. Open the confirmed booking.
2. Review the calculated down payment and project currency.
3. Select wallet, gateway or bank transfer.
4. Generate WB-DEP-{bookingId}-{timestamp}.
5. Process and verify the payment.
6. Set WeBuildTenantBooking.down_payment_status to paid.
7. Create LandlordPayout and dispatch ProcessLandlordPayout.
8. Send WeBuildDownPaymentReceivedNotification to both parties.
9. Update the booking payment summary and receipt.
21 We Build For You Instalments
|
STEP |
Pay a Development Instalment Primary user: Client and We Build For You module |
TenantWeBuildController@processPayment and @makePayment update the selected PropertyDevelopmentPaymentPlan record after wallet, gateway or bank-transfer confirmation.
1. Open upcoming payments.
2. Select the correct instalment number and due date.
3. Confirm amount, currency and any late fee.
4. Process through the selected channel.
5. Verify or approve the payment.
6. Mark the instalment paid.
7. Record fee and landlord payout.
8. Send client and landlord payment notifications.
9. Enable receipt download.
10. Recalculate booking balance and overdue status.
|
|
Instalment allocation Never allocate a payment to the next instalment merely because the amounts are equal. Use the selected schedule record and transaction reference. |
22 Phase 7 - Land Sale Payments
|
STEP |
Pay Land Instalments or Outright Balance Primary user: Buyer and Land Management module |
TenantLandPurchaseController, LandMobileController and LandPaymentApiController support wallet, gateway and bank-transfer proof.
1. Open the active LandSale and LandPaymentPlan.
2. Select the pending LandPaymentInstallment or outright balance.
3. Apply CurrencyExchangeService for client display and payment conversion.
4. Generate the configured land-payment reference, such as LAND-INST-{saleId}-{timestamp}.
5. Process through wallet or gateway, or upload a bank-transfer receipt.
6. Verify the provider or approve the bank transfer.
7. Mark LandPaymentInstallment paid.
8. Trigger LandlordPayoutService.
9. Send LandPaymentReceivedNotification to the buyer.
10. Send LandlordPaymentReceived to the landlord.
11. Update total paid, remaining balance and next due instalment.
|
|
Reference confirmation The supplied reference table includes LAND-INST, but individual controllers may use their own implementation. Confirm the actual deployed pattern used by callbacks. |
23 Phase 8 - Landlord Payment Dashboard
|
STEP |
Review All Payments Primary user: Landlord finance and property teams |
LeaseController@payments, @paymentHistory and PropertyPaymentController@history provide lease-level and property-level payment history.
|
Dashboard metric |
Interpretation |
|
Total collected this month / year |
Confirmed payment value in the selected scope. |
|
Overdue count and amount |
Outstanding obligations past due. |
|
Collection rate |
Paid obligations divided by the defined due population. |
|
Average days to payment |
Average difference between due date and paid date. |
|
Payment status distribution |
Pending, partial, paid, overdue and waived records. |
|
Payment method distribution |
Gateway, wallet, bank transfer and manual payments. |
|
☐ |
Confirm period and property filters. |
|
☐ |
Confirm original or reporting currency. |
|
☐ |
Separate verified payments from pending transfers. |
|
☐ |
Review manual and waived records. |
|
☐ |
Open unusually large or duplicated transactions. |
|
☐ |
Export only reconciled or clearly labelled operational data. |
24 Manual and Offline Payment Management
|
STEP |
Record a Manual Payment Primary user: Authorised finance user |
LeaseController@markPaymentAsPaid, @verifyPayment and PropertyPaymentController@processManualPayment support cash or approved offline payments.
1. Open the correct pending Payment record.
2. Select the offline method and payment date.
3. Enter amount, currency and external receipt reference.
4. Attach supporting evidence where supported.
5. Confirm whether the payment is full or partial.
6. Obtain approval under the company policy.
7. Mark paid or partial.
8. Generate the receipt and update history.
9. Reconcile cash or bank evidence.
|
|
Manual payment is high risk Restrict manual marking and bulk marking. Every manual change should include who, when, why and the supporting evidence. |
25 Late Fees, Waivers and Bulk Actions
|
STEP |
Apply or Waive Payment Obligations Primary user: Authorised landlord finance user |
|
Action |
Use |
Control |
|
applyLateFee |
Adds an approved fee to an overdue obligation. |
Confirm grace period and contract. |
|
waivePayment |
Removes the payment obligation. |
Require reason and approval. |
|
bulkMarkPaid |
Marks multiple records paid. |
Use only with verified batch evidence. |
|
bulkApplyLateFee |
Applies fees to multiple overdue records. |
Review eligibility and legal rules. |
|
sendPaymentReminder |
Sends one manual reminder. |
Use correct balance and due date. |
|
bulk reminders |
Sends property-level reminders. |
Exclude paid, disputed or waived records. |
|
|
Waiver is not deletion Keep the original obligation, waiver reason, approver and date so financial and client history remain traceable. |
26 Phase 9 - Automated Payment Reminders
|
STEP |
Run the Reminder and Overdue Notification System Primary user: Scheduled jobs and operations |
|
Notification |
Recipient |
Trigger |
|
LeasePaymentReminderNotification |
Client |
Before rent due date. |
|
LeaseReminderNotification |
Client |
General lease reminder. |
|
WeBuildPaymentDueReminderNotification |
Client |
Before WeBuild instalment due date. |
|
WeBuildOverduePaymentNotification |
Client |
WeBuild instalment overdue. |
|
WeBuildOverduePaymentLandlordNotification |
Landlord |
Client WeBuild payment overdue. |
|
LandPaymentReminderNotification |
Buyer |
Before land instalment due date. |
|
LandPaymentOverdueNotification |
Buyer |
Land instalment overdue. |
Reminder controls
|
☐ |
Use the correct local time zone. |
|
☐ |
Do not send after the payment is confirmed. |
|
☐ |
Include property, due date, amount and payment options. |
|
☐ |
Do not expose private information in notification previews. |
|
☐ |
Avoid excessive repeated reminders. |
|
☐ |
Record delivery or processing status where implemented. |
27 AI Smart Reminders and Payment Risk
CorporateLandlordWeBuildController@generateSmartReminder can draft a personalised reminder, while @predictPaymentRisk estimates the likelihood of default for an instalment.
|
AI output |
How to use it |
|
Smart reminder |
Review tone, facts, due amount and legal wording before sending. |
|
Payment risk score |
Prioritise outreach and management review. |
|
Risk factors |
Understand the data driving the recommendation. |
|
Revenue forecast |
Support cash planning across projects. |
|
Payment insights |
Review collection trends, payment timing and risk distribution. |
|
|
AI is advisory AI must not automatically shame clients, impose fees, cancel contracts or make final credit decisions without approved human and legal controls. |
28 Phase 10 - Landlord Payout Processing
|
STEP |
Create and Process the Landlord Payout Primary user: System and payout operations |
Figure 5. Payment, fee and landlord payout flow
|
LandlordPayout field |
Purpose |
|
landlord_id |
Receiving landlord. |
|
amount / currency |
Amount intended for payout. |
|
reference |
Unique payout reference. |
|
status |
Pending, processing, completed or failed. |
|
payment_method |
Gateway, bank transfer or wallet credit. |
|
source payment |
Rent, sale, WeBuild, land or other originating payment. |
1. Create the LandlordPayout after the client payment is verified.
2. Fire PayoutRequested where configured.
3. Dispatch ProcessLandlordPayout or ProcessLandlordPayoutJob.
4. Use LandlordPaymentMethodResolver to select the eligible method.
5. Use the primary verified bank account and supported payout gateway when available.
6. Otherwise apply the configured wallet or manual fallback.
7. Move status from pending to processing.
8. Record provider result and update to completed or failed.
9. Create PayoutAudit.
10. Fire LandlordPayoutUpdated.
11. Send PayoutProcessed or ManualPayoutRequired.
|
|
Collection and payout are separate ledgers A client payment can be successful while the landlord payout is pending or failed. Do not represent the payout as completed until the destination confirms it. |
29 Supported Payout Methods and Failures
The supplied payout list includes Embedly, Flutterwave, Revolut, Stripe, PayPal, SEPA, Solaris and landlord wallet credit.
|
Payout outcome |
Required action |
|
Completed |
Store provider reference, completion time and audit evidence. |
|
Processing |
Continue monitoring without duplicating the request. |
|
Failed |
Record reason, determine retry safety and notify operations. |
|
Manual required |
Assign an administrator and preserve the original payout record. |
|
Wallet credited |
Record wallet transaction and resulting landlord balance. |
|
|
Provider capability confirmation Confirm actual payout countries, currencies, bank formats, limits, fees and settlement timing for every configured provider. |
30 Automated Payout Rules
|
STEP |
Configure AutomatedPayoutRule Primary user: Landlord finance administrator |
|
Rule |
Purpose |
|
Balance threshold |
Auto-withdraw when the eligible balance exceeds a value. |
|
Daily schedule |
Processes eligible payouts each day. |
|
Weekly schedule |
Processes on the configured weekday. |
|
Monthly schedule |
Processes on the configured day. |
|
Minimum payout |
Prevents very small payout attempts. |
|
Destination |
Uses the eligible primary account or configured wallet rule. |
|
☐ |
Rule owner and approval are recorded. |
|
☐ |
Minimum and threshold use the correct currency. |
|
☐ |
Bank account is active and verified. |
|
☐ |
Failed automated payout creates an exception, not repeated uncontrolled attempts. |
|
☐ |
Changes are audited. |
31 Phase 11 - Platform Fee Calculation
|
STEP |
Calculate and Record the Platform Fee Primary user: FeeCalculationService |
|
Fee type |
Typical source |
|
rent_payment |
Lease rent payment. |
|
property_purchase_payment |
Property deposit or instalment. |
|
we_build_payment |
We Build For You down payment or instalment. |
|
land_payment |
Land sale payment. |
|
wallet_topup |
Wallet funding transaction. |
calculateFee($amount, $feeType) applies the configured percentage, flat or tiered structure. recordFeeTransaction stores the fee separately.
1. Identify the payment module and fee type.
2. Calculate the fee against the correct base amount.
3. Apply currency and rounding rules.
4. Show the fee before client confirmation where required.
5. Record the fee transaction once.
6. Separate platform fee from landlord payout amount according to the configured model.
7. Include the fee in analytics and reconciliation.
|
|
Fee transparency Do not hide the service fee inside the payment amount when the applicable contract, checkout design or law requires separate disclosure. |
32 Phase 12 - Payment Analytics and Revenue Forecasting
|
STEP |
Review Landlord Payment Analytics Primary user: Landlord management and finance |
|
Metric / tool |
Purpose |
|
getPaymentInsights |
AI view of collection trends and risk distribution. |
|
generateRevenueForecast |
Forecasts future revenue across projects. |
|
predictPaymentRisk |
Estimates default risk per instalment. |
|
exportPaymentSchedules |
Exports upcoming and historical schedules. |
|
total_deposit_collected |
Property-sale deposits received. |
|
total_revenue |
Completed property-sale amounts according to dashboard logic. |
|
active / completed / cancelled purchases |
Sales-application portfolio status. |
|
Collection rate |
Paid obligations divided by defined due obligations. |
|
|
Metric definition Document whether totals use original or converted currency, cash or verified-payment basis, and whether refunds or waivers reduce the figure. |
33 Client Payment Analytics
Mobile\RentPaymentController@getAnnualSummary and Mobile\LeaseController@getPaymentStats provide the client with an annual and lease-level view.
|
Client metric |
Meaning |
|
Total paid |
Confirmed paid amount for the selected period. |
|
On-time rate |
Paid on or before the defined deadline. |
|
Late payments |
Payments after the due date or grace rule. |
|
Overdue amount |
Outstanding amount past due. |
|
Next payment |
Next pending due date and amount. |
|
Transaction status |
Current status for a selected payment reference. |
|
|
Disputed records A client dashboard should distinguish pending verification, disputed bank transfer, refund processing and final paid status. |
34 Phase 13 - Lease Angel Rent Financing
|
STEP |
Manage Rent Financing Payments Primary user: Lease Angel landlord, client and platform users |
Lease Angel separates the landlord rent receipt from the client repayment schedule. The landlord receives full rent upfront while the client repays the platform in instalments.
1. Client applies for financing.
2. Application and fraud controls are reviewed.
3. Approved funding pays the landlord according to the Lease Angel flow.
4. Create the client repayment schedule.
5. Notify the client with LeaseAngelScheduleCreated.
6. Collect card, bank-transfer or configured repayment.
7. Send upcoming schedule reminders.
8. Handle failed payments and proof upload.
9. Alert the landlord when fraud is flagged.
10. Reconcile landlord funding separately from client repayments.
|
Notification |
Meaning |
|
LeaseAngelBankTransferInitiated |
Client bank transfer began. |
|
LeaseAngelBankProofUploaded |
Landlord or operations notified of proof. |
|
LeaseAngelCardPaymentPending |
Card payment has not completed. |
|
LeaseAngelPaymentFailed |
Repayment failed. |
|
LeaseAngelFraudFlagged |
Potential fraud requires review. |
|
LeaseAngelScheduleCreated |
Repayment schedule created. |
|
LeaseAngelScheduleReminder |
Repayment approaching. |
|
LeaseGiftSent / Received |
Rent gift flow notification. |
|
|
Financing distinction Lease Angel repayment is not the same as ordinary lease rent collection. Reports should distinguish funded landlord rent from client financing repayments. |
35 Phase 14 - Multi-Currency Payments
|
STEP |
Handle Payment Currency Conversion Primary user: Currency services and payment flows |
|
Service / method |
Purpose |
|
CurrencyService::getUserCurrency |
Detects client preferred currency. |
|
CurrencyService::getCurrencyFromCountry |
Determines property currency from country. |
|
CurrencyService::convert |
Converts display or transaction amount. |
|
ExchangeRateService |
Fetches current exchange rates. |
|
CurrencyExchangeService |
Supports land and other module conversion flows. |
|
☐ |
Original property or listing currency is retained. |
|
☐ |
Converted display amount is labelled. |
|
☐ |
Rate source and time are available where required. |
|
☐ |
Fees and payout amounts use the correct currency. |
|
☐ |
Rounding is consistent. |
|
☐ |
Refunds use the provider and original-payment rules. |
|
|
Stored amount versus display amount The supplied design states that amounts are stored in the property listing currency and converted for display. Confirm how wallet debits, provider settlements and FX gains or losses are recorded. |
36 Phase 15 - Payment Webhooks
|
STEP |
Receive and Process Payment Webhooks Primary user: Technical operations |
The supplied scenario references CrmWebhookInboundController@handle and @handlePaymentWebhook for asynchronous payment events, with CrmWebhookLog storing inbound and outbound events. Because the controller name is CRM-oriented, confirm the exact production routing before implementation training.
|
Webhook event |
Expected processing |
|
Payment success |
Verify provider event and complete the correct payment once. |
|
Payment failure |
Record failed status and reason without false completion. |
|
Refund processed |
Update refund status and client balance. |
|
Chargeback initiated |
Create dispute or reversal workflow and alert operations. |
|
Retry |
Use retryWebhookLog for failed internal processing without duplicating business actions. |
|
☐ |
Verify provider signature. |
|
☐ |
Use provider event ID for idempotency. |
|
☐ |
Validate reference, amount, currency and destination. |
|
☐ |
Do not log secret or sensitive payment data. |
|
☐ |
Use retry-safe processing. |
|
☐ |
Preserve raw safe metadata for investigation. |
|
|
Webhook naming confirmation Do not assume the CRM webhook controller is the only payment-webhook entry point. Confirm each provider route, signature logic and event mapping in the deployed code. |
37 Phase 16 - Refunds
|
STEP |
Process a Full or Partial Refund Primary user: Authorised finance and payment operations |
1. Open the original verified Payment.
2. Confirm the provider allows a refund and the refundable amount.
3. Enter the amount and reason.
4. Obtain the required approval.
5. Call LeasePaymentGatewayService@refundPayment.
6. Store the provider refund reference.
7. Update Payment.status to refunded or partial_refund.
8. Adjust the client, landlord wallet or bank position according to the configured recovery process.
9. Update payout or receivable records where required.
10. Notify the client.
11. Reconcile provider, bank and ledger impact.
|
|
Refund funding The supplied scenario states that the landlord wallet or bank account is debited. Confirm the exact debit, negative-balance, failed-recovery and already-paid-out handling. |
38 Payment Reference Patterns
|
Payment type |
Reference pattern |
Module |
|
Rent - gateway |
RENT-{leaseId}-{timestamp} |
Lease Management |
|
Rent - wallet |
RENT-MOB-{leaseId}-{timestamp} |
Lease Management |
|
Property deposit |
PROP-DEP-{saleId}-{timestamp} |
Property Sales |
|
Property instalment |
PROP-INST-{saleId}-{timestamp} |
Property Sales |
|
Property payout |
PROP-MOB-PROP-DEP-... |
Property Sales |
|
WeBuild down payment |
WB-DEP-{bookingId}-{timestamp} |
We Build For You |
|
WeBuild instalment |
WB-INST-{bookingId}-{timestamp} |
We Build For You |
|
Land instalment |
LAND-INST-{saleId}-{timestamp} |
Land Management |
|
☐ |
Reference is unique. |
|
☐ |
Prefix identifies the module and payment type. |
|
☐ |
Business ID is stable and correct. |
|
☐ |
Reference is stored before provider initiation. |
|
☐ |
Callback parsing is tested. |
|
☐ |
Retries do not accidentally reuse a completed reference. |
39 Notifications and Events Reference
|
Notification |
Recipient |
Trigger |
|
LeasePaid |
Client |
Rent payment confirmed. |
|
LeasePaymentReceivedNotification |
Landlord |
Rent received. |
|
TenantPaymentConfirmation |
Client |
Detailed receipt. |
|
LeasePaymentReminderNotification |
Client |
Upcoming rent. |
|
LeasePaymentProofUploadedNotification |
Landlord |
Bank proof uploaded. |
|
PropertyDepositReceivedNotification |
Landlord |
Property deposit received. |
|
PropertyDepositConfirmedNotification |
Buyer |
Deposit confirmed. |
|
PropertySaleCompletedLandlordNotification |
Landlord |
Sale completed. |
|
PropertySaleCompletedTenantNotification |
Buyer |
Sale completed. |
|
WeBuildDownPaymentReceivedNotification |
Both |
Down payment confirmed. |
|
WeBuildPaymentReceivedNotification |
Client |
Instalment confirmed. |
|
WeBuildPaymentReceivedLandlordNotification |
Landlord |
Instalment received. |
|
WeBuildPaymentDueReminderNotification |
Client |
Upcoming instalment. |
|
WeBuildOverduePaymentNotification |
Client |
Instalment overdue. |
|
WeBuildLateFeeAppliedNotification |
Client |
Late fee applied. |
|
WeBuildPaymentWaivedNotification |
Client |
Payment waived. |
|
LandPaymentReceivedNotification |
Buyer |
Land payment confirmed. |
|
LandlordPaymentReceived |
Landlord |
Land payment received. |
|
PayoutProcessed |
Landlord |
Payout completed. |
|
ManualPayoutRequired |
Admin |
Manual payout action. |
|
LeaseAngelScheduleCreated |
Client |
Financing schedule created. |
|
LeaseAngelScheduleReminder |
Client |
Upcoming repayment. |
|
LeaseAngelFraudFlagged |
Landlord |
Fraud alert. |
|
Event |
Trigger |
|
PayoutRequested |
Payout created. |
|
LandlordPayoutUpdated |
Payout status changed. |
|
PropertyDepositPaid |
Property deposit paid. |
|
PropertySaleCompleted |
Property sale fully paid and completed. |
40 Payment Control and Reconciliation
Figure 6. Payment control and reconciliation model
Daily reconciliation
1. Compare due obligations with payment attempts.
2. Compare verified gateway transactions with provider data.
3. Compare wallet debits and fee transactions with wallet balances.
4. Compare approved bank transfers with bank statement credits.
5. Confirm each payment is allocated to the correct schedule record.
6. Compare LandlordPayout records with provider, bank or wallet destination.
7. Review pending, failed, duplicate and unknown statuses.
8. Review refunds, reversals and chargebacks.
9. Record unresolved differences and assign an owner.
|
|
One payment, one economic event Repeated callbacks, retries and exports must not create multiple paid records, payouts, receipts or fee transactions for one client payment. |
41 Audit Trail and Evidence Requirements
|
Evidence |
Minimum information |
|
Payment record |
Business IDs, amount, currency, due date, status, method and paid time. |
|
Gateway evidence |
Leaseora reference, provider ID, verified status and safe response metadata. |
|
Wallet evidence |
Before/after balance, wallet transaction and fee record. |
|
Bank transfer |
Uploaded proof, bank statement evidence, verifier and approval time. |
|
Fee |
Fee type, calculation basis, amount and currency. |
|
Payout |
Destination, method, provider reference, status and timestamps. |
|
Refund |
Original payment, amount, reason, approver and provider reference. |
|
Notification |
Type, recipient and processing result where available. |
|
Manual change |
User, timestamp, previous status, new status and reason. |
42 Operational Exception Handling
|
Exception |
Required response |
|
Gateway success but Payment pending |
Reverify provider reference and process idempotently. |
|
Client says paid but provider shows pending |
Keep pending and continue provider review. |
|
Wallet debited but Payment not paid |
Freeze further action, inspect atomic transaction and correct under audit. |
|
Bank proof uploaded but no bank credit |
Do not approve; request clarification or wait for settlement. |
|
Payment paid twice |
Confirm both economic transactions; refund or allocate only under approval. |
|
Payout failed |
Keep client payment successful; retry or route payout separately. |
|
Wrong schedule allocation |
Reverse or reallocate with audit evidence. |
|
Wrong currency |
Stop completion, verify provider amount and apply correction or refund. |
|
Refund failed |
Keep original payment state and record pending or failed refund. |
|
Webhook replay |
Ignore duplicate business action using idempotency key. |
|
|
Do not solve exceptions by deleting records Use controlled status changes, reversals, refunds or reallocation so the history remains available. |
43 Daily, Weekly and Monthly Operating Procedures
Daily
|
☐ |
Review failed and pending payments. |
|
☐ |
Review uploaded bank-transfer proofs. |
|
☐ |
Review failed and processing payouts. |
|
☐ |
Check overdue obligations and reminder status. |
|
☐ |
Reconcile high-value gateway, wallet and bank activity. |
|
☐ |
Review refund and chargeback alerts. |
Weekly
|
☐ |
Review collection rate and average days to payment. |
|
☐ |
Review payment-method performance. |
|
☐ |
Review fee revenue and payout exceptions. |
|
☐ |
Review late fees and waivers. |
|
☐ |
Review AI risk and smart-reminder output. |
|
☐ |
Export and archive exception reports. |
Monthly
|
☐ |
Complete payment-to-bank reconciliation. |
|
☐ |
Reconcile platform fees. |
|
☐ |
Reconcile landlord payouts. |
|
☐ |
Review overdue aging by module. |
|
☐ |
Review refunds, reversals and chargebacks. |
|
☐ |
Validate automated payout rules. |
|
☐ |
Generate management collection and revenue reports. |
44 Month-End Payment Close
1. Confirm the payment cut-off date and time.
2. Process all provider callbacks and webhook retries.
3. Review pending and unknown gateway transactions.
4. Complete bank-transfer verification for the period or carry open items.
5. Reconcile wallet debits and wallet balances.
6. Reconcile fee transactions and fee revenue.
7. Reconcile client payments to schedules and receivables.
8. Reconcile LandlordPayout to destination settlement.
9. Review refunds and chargebacks.
10. Review late fees, waivers and manual paid records.
11. Generate payment-history and collection reports.
12. Provide accounting and finance with reconciled totals and open-item schedules.
|
|
Close only reconciled figures Operational dashboard totals can change after delayed callbacks, refunds or payout failures. Label preliminary figures clearly. |
45 Security and Fraud Controls
|
☐ |
Use authenticated and authorised payment endpoints. |
|
☐ |
Do not store raw card data in Leaseora unless the deployed compliance design explicitly requires and permits it. |
|
☐ |
Verify gateway callbacks server-side. |
|
☐ |
Use idempotency and replay protection. |
|
☐ |
Restrict manual payment, waiver, refund and payout permissions. |
|
☐ |
Log IP, device or risk context where the implementation supports it. |
|
☐ |
Review large or unusual wallet payments. |
|
☐ |
Confirm bank-account changes before payout. |
|
☐ |
Protect receipts and uploaded proof from unauthorised access. |
|
☐ |
Redact secrets and sensitive bank data from logs. |
|
|
High-risk operations Refunds, bank-account changes, bulk marking, waivers and manual payouts should use enhanced approval and audit controls. |
46 Key Backend Models Reference
|
Model |
Purpose |
|
Payment |
Core rent payment obligation and status. |
|
PropertyDevelopmentPaymentPlan |
Development and WeBuild instalment schedule. |
|
LandPaymentPlan / LandPaymentInstallment |
Land payment schedule and due instalments. |
|
LandlordPayout |
Payout from any client payment. |
|
TenantPayout |
Client withdrawal records used by the broader payment environment. |
|
PayoutAudit |
Payout audit trail. |
|
AutomatedPayoutRule |
Scheduled and threshold payout rules. |
|
LandlordBankAccount |
Verified payout bank account. |
|
BankTransferTransaction |
Uploaded proof and manual verification status. |
|
LandlordGateway |
Landlord gateway configuration. |
|
PropertyPaymentGateway |
Property-level gateway availability. |
|
Wallet / WalletTransaction |
Client payment balance and wallet transaction history. |
|
SalesApplication |
Property-sale deposit and cumulative payment status. |
|
WeBuildTenantBooking |
WeBuild booking payment status. |
|
LandSale |
Land purchase and payment-plan context. |
|
Controller |
Purpose |
|
Tenant\RentPaymentController |
Client web rent payment, history and receipts. |
|
Mobile\RentPaymentController |
Mobile initiation, payment, receipts, annual summary and reminders. |
|
Mobile\LeaseController |
Schedule, history, stats and bank-transfer workflow. |
|
LeaseController |
Landlord payment management, marking, verification and export. |
|
PropertyPaymentController |
Gateway setup, late fees, manual payment and reminders. |
|
PropertySaleMobileController |
Property deposit and instalment payments. |
|
LandlordPropertySalesController |
Property purchase payment dashboard and statistics. |
|
TenantWeBuildController |
WeBuild down payment and instalments. |
|
CorporateLandlordWeBuildController |
WeBuild payment management, fees, waivers and AI tools. |
|
TenantLandPurchaseController |
Land payment on web. |
|
LandMobileController |
Land payments and callbacks on mobile. |
|
LandPaymentApiController |
Land wallet, gateway and bank-transfer APIs. |
|
Landlord\LeaseAngelController |
Landlord rent-financing management. |
|
Tenant\LeaseAngelController |
Client rent-financing web flow. |
|
Mobile\LeaseAngelController |
Client rent-financing mobile flow. |
|
LandlordBankAccountController |
Payout bank account creation and primary selection. |
|
CrmWebhookInboundController |
Supplied webhook handler reference; production mapping requires confirmation. |
48 Services, Jobs and Commands Reference
|
Service / job |
Purpose |
|
FeeCalculationService |
Calculates and records platform fees. |
|
CurrencyService |
User and property currency conversion. |
|
ExchangeRateService |
Current exchange-rate source. |
|
CurrencyExchangeService |
Cross-module FX support. |
|
PaymentGatewayFactory |
Resolves the gateway class. |
|
LandlordPaymentMethodResolver |
Selects the payout method. |
|
LandlordPayoutService |
Executes landlord payout logic. |
|
LandlordPaymentGatewayService |
Gateway payment session and verification. |
|
LandlordPaymentRecorder |
Records payment transactions. |
|
LeasePaymentGatewayService |
Recurring, split, auto-collection, late fee and refund. |
|
ProcessLandlordPayout / ProcessLandlordPayoutJob |
Executes landlord payouts. |
|
ProcessTenantPayoutJob |
Executes client withdrawals. |
|
ProcessScheduledWalletPayments |
Processes scheduled wallet payments. |
49 Worked Example - Monthly Rent Payment by Wallet
|
|
Scenario A client pays NGN 1,000,000 monthly rent from a Leaseora wallet. The property and lease currency are NGN. The landlord has a verified Nigerian bank account and Flutterwave payout configured. |
|
Stage |
What happens |
|
1. Schedule |
Lease activation created a pending Payment for the due date. |
|
2. Dashboard |
The client sees NGN 1,000,000 due. |
|
3. Wallet check |
The system checks the wallet is active and has enough for rent plus fee. |
|
4. Fee |
FeeCalculationService calculates the rent_payment fee. |
|
5. Debit |
The wallet deducts the total authorised amount. |
|
6. Fee record |
recordFeeTransaction stores the fee separately. |
|
7. Payment update |
Payment changes to paid and records RENT-MOB reference and paid_at. |
|
8. Payout creation |
LandlordPayout is created for the landlord amount. |
|
9. Resolution |
LandlordPaymentMethodResolver selects the verified bank account and Flutterwave payout. |
|
10. Job |
ProcessLandlordPayout changes the payout to processing. |
|
11. Completion |
Provider confirmation changes payout to completed and PayoutAudit is stored. |
|
12. Notices |
The client receives LeasePaid and receipt; landlord receives payment and payout notifications. |
|
13. Reconciliation |
Finance reconciles wallet debit, fee, payment, provider payout and bank settlement. |
|
|
Failure scenario If the wallet debit succeeds but payout fails, the client Payment remains paid while LandlordPayout remains failed or manual. The two statuses must not be confused. |
50 Implementation and Onboarding Checklist
Infrastructure
|
☐ |
Gateways enabled and tested. |
|
☐ |
Property-level gateway assignments complete. |
|
☐ |
Late-fee and grace rules approved. |
|
☐ |
Auto-collection rules approved. |
|
☐ |
Landlord bank accounts verified. |
|
☐ |
Wallet and payout fallback configured. |
Payment schedules
|
☐ |
Lease schedules generated correctly. |
|
☐ |
WeBuild and development instalments verified. |
|
☐ |
Land-payment plans verified. |
|
☐ |
Property-sale deposit and completion rules confirmed. |
|
☐ |
Opening pending and overdue balances migrated. |
Operations
|
☐ |
Manual payment permissions assigned. |
|
☐ |
Bank-transfer verification owners assigned. |
|
☐ |
Refund and waiver approval limits documented. |
|
☐ |
Payout failure escalation documented. |
|
☐ |
Daily and month-end reconciliation procedures trained. |
51 User Acceptance Testing
|
Test area |
Acceptance test |
|
Gateway setup |
Configure and test each landlord gateway. |
|
Bank account |
Add, verify and set primary payout account. |
|
Lease schedule |
Generate monthly, weekly, bi-weekly and quarterly schedules. |
|
Gateway rent |
Initiate, callback, verify and receipt. |
|
Gateway duplicate |
Replay callback and confirm no duplicate. |
|
Gateway wrong amount |
Reject mismatched amount or currency. |
|
Wallet rent |
Convert, calculate fee, debit and create payout. |
|
Wallet failure |
Simulate debit or record failure safely. |
|
Bank transfer |
Upload, reject and approve proof. |
|
Property deposit |
Pay 10% by each channel. |
|
Property instalment |
Complete sale at full cumulative amount. |
|
WeBuild |
Pay down payment and instalment. |
|
Land |
Pay instalment and update schedule. |
|
Manual payment |
Mark paid and partial with audit. |
|
Late fee |
Apply after grace period. |
|
Waiver |
Waive with approval and notification. |
|
Reminder |
Send upcoming and overdue notices. |
|
Payout |
Complete, fail and manually resolve. |
|
Automated payout |
Test threshold and schedule. |
|
Fee |
Verify each fee type and rounding. |
|
FX |
Test display and processing currency. |
|
Webhook |
Process success, failure, refund and chargeback. |
|
Refund |
Full and partial refund. |
|
Analytics |
Verify collection, revenue and overdue metrics. |
|
Export |
Download receipts and payment histories. |
|
Permissions |
Confirm unauthorised users cannot verify, refund or waive. |
|
|
Pilot recommendation Pilot with one property, one lease, one gateway, one wallet and one verified bank account before enabling all payment modules. |
52 Common Issues and Troubleshooting
|
Issue |
Recommended action |
|
Payment schedule missing |
Confirm lease activation, dates, frequency and generatePaymentSchedule execution. |
|
Client cannot see payment |
Check active lease, pending schedule, property and client relationship. |
|
Gateway option missing |
Check landlord configuration, property assignment and gateway health. |
|
Gateway says paid but Leaseora pending |
Reverify provider and process callback idempotently. |
|
Wallet balance insufficient |
Confirm converted amount plus fee and available balance. |
|
Wallet debited twice |
Stop processing, inspect references and idempotency, then correct under audit. |
|
Bank proof pending too long |
Assign verifier and check actual bank statement. |
|
Bank proof approved but no credit |
Reverse or correct through controlled process and investigate. |
|
Payment marked paid manually without evidence |
Escalate, review audit and reverse if incorrect. |
|
Late fee applied too early |
Review due date, grace period and timezone. |
|
Reminder sent after payment |
Review schedule job timing and payment-status query. |
|
Payout not created |
Check payment completion hook and payout trigger. |
|
Payout failed |
Review bank account, provider, currency and manual intervention. |
|
Fee missing |
Check fee type mapping and recordFeeTransaction. |
|
Sale not completed |
Review cumulative amount, callback reference and application status. |
|
WeBuild instalment still overdue |
Check allocation to the correct PropertyDevelopmentPaymentPlan. |
|
Land balance incorrect |
Review instalment allocation and total-paid calculation. |
|
Refund pending |
Check provider result and landlord fund recovery. |
|
Analytics totals differ |
Confirm period, currency, refund, waiver and verification definitions. |
|
Webhook retry duplicates payment |
Repair event idempotency and unique constraints. |
53 Frequently Asked Questions
Can clients pay in three ways?
Yes. The supplied flows support gateway, wallet and bank transfer with verification.
Can every module use the same payment records?
The modules share services and infrastructure, but leases, development and land use different schedule models.
When is a bank transfer paid?
Only after authorised verification of actual receipt.
Does wallet payment trigger a payout immediately?
The supplied flow creates LandlordPayout and dispatches the payout job after the wallet payment.
What happens when there is no landlord bank account?
The supplied flow allows landlord-wallet credit; confirm the deployed fallback.
Is the property deposit always 10%?
The supplied property-sales flow uses 10%. Confirm configurability.
Can a payment be partial?
Payment includes a partial status, but confirm which controllers and modules support partial allocation.
Can a payment be waived?
Yes in the supplied workflow, with notification and recommended approval.
Are late fees automatic?
Rules can be configured; application depends on the module and scheduled process.
Can Leaseora send reminders automatically?
Yes. Lease, WeBuild and land reminder notifications are specified.
Can AI decide to reject a client?
No. AI risk and reminder tools are advisory.
Can the landlord receive payouts by wallet?
Yes, according to the fallback and configured payout method.
Does payment success mean payout success?
No. Payment and payout have separate statuses.
Can refunds be partial?
Yes, LeasePaymentGatewayService@refundPayment supports a supplied amount.
Are all amounts stored in client currency?
No. The supplied design stores amounts in property/listing currency and converts for display.
Can delayed webhooks update a payment later?
Yes, provided idempotent verification and business-state controls are implemented.
Can the company export payment history?
Yes. Lease and property history exports and payment-schedule exports are specified.
Can Lease Angel be reported with ordinary rent?
It should be distinguished because landlord funding and client repayments are separate flows.
54 Technical Matters to Confirm Before Production
|
Area |
Confirmation required |
|
Payment statuses |
Exact enum, partial, refund and waiver transitions. |
|
Partial payments |
Which modules support them and how they allocate. |
|
Payment references |
Exact production patterns and retry rules. |
|
Deposit rule |
Whether property deposit percentage is fixed or configurable. |
|
Fee rules |
Rate, tiers, currency, rounding, payer and refund treatment. |
|
FX |
Rate source, lock period, markup and accounting treatment. |
|
Wallet atomicity |
Database transaction, balance locking and compensation. |
|
Bank verification |
Who can approve and what evidence is required. |
|
Payout resolver |
Priority, fallback and supported provider/account rules. |
|
Payout timing |
Immediate, queued, scheduled and retry behaviour. |
|
Webhooks |
Actual controllers, provider routes, signatures and retry jobs. |
|
Idempotency |
Unique keys for callbacks, wallet and payout records. |
|
Refund funding |
How landlord bank or wallet recovery works. |
|
Chargebacks |
Dispute, reversal, negative balance and notification flow. |
|
Late fees |
Module coverage, scheduler and grace-period timezone. |
|
Auto-collection |
Mandate, recurring token, retry and cancellation rules. |
|
Notifications |
Queues, templates, delivery channels and failure handling. |
|
Receipts |
Numbering, tax fields, reissue and refund display. |
|
Analytics |
Definitions, currency basis and refund/waiver treatment. |
|
Audit retention |
Logs, uploaded proofs, payout evidence and retention period. |
|
|
Source-derived guide Undefined production behaviour is identified for confirmation rather than silently invented. Compare this guide with the deployed code and configured providers before training external clients. |
55 Quick Reference - 27-Step Payments Operating Flow
1. Configure landlord gateways and property availability.
2. Configure late fees and automatic collection.
3. Add and verify landlord payout bank accounts.
4. Activate a lease and generate Payment records.
5. Generate WeBuild, development and land instalment schedules.
6. Client opens upcoming payments.
7. Client selects gateway, wallet or bank transfer.
8. Create a unique module-specific reference.
9. Apply currency conversion where needed.
10. Calculate and disclose the platform fee.
11. Initiate the gateway session, debit the wallet or create pending bank proof.
12. Verify provider payment or approve bank receipt.
13. Update the correct Payment or instalment record.
14. Record fee and payment transaction details.
15. Generate confirmation and receipt.
16. Create LandlordPayout.
17. Resolve the payout method and destination.
18. Dispatch the payout job and track status.
19. Create PayoutAudit and send payout notification.
20. Run upcoming and overdue reminders.
21. Apply approved late fees or waivers.
22. Monitor property, WeBuild and land balances.
23. Review collection, overdue, risk and revenue analytics.
24. Process approved refunds and chargebacks.
25. Reconcile payment, fee, payout, bank and wallet records.
26. Complete month-end payment close.
27. Review exceptions, audit logs and production controls.
|
|
Business value Leaseora Payments gives a real estate company one traceable operating layer for schedules, collections, platform fees, landlord settlement, reminders, financing repayments, receipts, analytics and reconciliation across the full property lifecycle. |
LEASEORA
PAYMENTS MANAGEMENT
Schedule, collect, verify, pay out and reconcile every real estate payment from one connected platform.
|
|
Support and onboarding For Payments-module setup, payment migration, staff training, gateway onboarding, bank-transfer controls or payout integration assistance, contact Leaseora through support@leaseora.com. |
leaseora.com
Tags
Was this article helpful?
Your feedback helps us improve our documentation.