Bayit

Client

In Israel, a vaad bayit collects money from residents and pays for a building's ongoing expenses. The client already operated a live WordPress-based property-management and payment service that scheduled resident charges, processed payments, sent reminders through WhatsApp and automated voice calls, and produced financial reports.

The problem was not that the service failed to work; it had outgrown its technical foundation. Financial data lived in generic CMS storage, there was no API for a separate frontend, and duplicate-payment prevention needed stronger application-level safeguards. The new platform also had to take over while the legacy system continued processing real resident payments.

Key Highlights

Challenge

This was a live financial-system migration, not a standard CRUD rebuild. The platform needed to process recurring resident charges, preserve existing payment relationships, support Israeli payment methods and right-to-left documents, and transition from WordPress without interrupting day-to-day collection.

• Prevent duplicate payments. Keep every payment traceable through confirmation and status changes while preventing the same transaction from being recorded twice.
• Keep third-party funds out of the platform. Route payments through merchant accounts belonging to each committee.
• Preserve existing payment tokens. Residents should not have to re-enter card data during migration.
• Support local requirements. Bit, instalment payments (tashlumim), and masav bank orders each required a different integration flow, while reports and documents had to support right-to-left Hebrew.
• Migrate without downtime. Move data from the legacy system while both platforms remained operational.

Solution

We rebuilt the service around an explicit financial domain model and separated payment, reporting, messaging, administration, and migration concerns into dedicated modules.

• Separate-merchant payment model. Each committee is registered with the payment provider and receives funds directly.
• Multiple payment methods. Integrated card payments, Bit, instalment payments, and standing bank orders through the relevant payment providers, while keeping each method isolated within the payment architecture.
• Tokenized card payments. Card details are entered inside the payment provider's secure flow; the application stores only the provider token and limited display metadata, allowing saved cards to continue working after migration.
• Duplicate prevention at application level. Gateway confirmation, payment persistence, and charge-status updates are coordinated inside a database transaction, with a unique transaction identifier as an additional safeguard.
• 15-module backend. Payment, reporting, messaging, and other domains are isolated through the in-house modular framework so new payment strategies can be added without rewriting unrelated logic.
• Documented REST API. Built a dedicated API layer for the SPA frontend, with 65 documented endpoints available through the admin panel.
• Generated admin panel. Module configuration defines back-office screens, reducing repeated controller/template work.
• Parallel migration. Imported records carry external identifiers and import metadata so migration can be re-run safely while the legacy system remains active.
• Immutable expense history. Reports read historical snapshots rather than mutable current expense records.

Process

The implementation sequence followed the financial risk of the product: payment behavior and migration safety were addressed before convenience features.

1. Map the domain. Mapped the vaad bayit domain, including expense types, resident debts, local payment methods, and reporting rules.
2. Build payment safeguards first. Built merchant onboarding, card tokenisation, charging, Bit and instalment payment flows, callback handling, transaction confirmation, and duplicate-prevention safeguards first.
3. Automate collection. Added nightly charge generation and collection processes with dedicated success/failure logging and notifications.
4. Run the staged migration. Ran the legacy importer in stages — committees, residents with payment tokens, debts and payments, then historical expenses — while both systems continued operating.
5. Add account features. Added self-service registration, a 30-day trial, Google sign-in, account lifecycle rules, and traceable support impersonation.
6. Finish reporting and deployment. Completed RTL reporting, cache invalidation, deployment automation for development/stage, and frontend integration against the documented API.

Result

• Data migrated without re-entry. Committees, residents, debts, payment history, and provider payment tokens were migrated; residents did not need to re-enter card details as part of the move.
• Scheduled collection with failure tracking. Recurring charge generation and collection can run through scheduled processes, with failed transactions recorded together with the payment provider response.
• Multiple payment options. Residents can pay by card, saved card, Bit, or instalment-based payment flows, while committees can use standing bank orders for their own subscription payments.
• Full payment traceability. Every recorded payment has a traceable relationship to the resident, committee, charge, amount, method, and provider response.
• Stable historical reporting. Past reports are built from immutable snapshots, so historical periods remain stable when current expense data changes.
• Independent API layer. A documented REST API with 65 endpoints gives the frontend a stable integration layer independent of the legacy WordPress implementation.