I designed and developed a multi-tenant invoicing and payment platform for businesses operating across transport, restaurants, online payments, employee billing, and general invoicing.
Keep invoice, booking, refund, dispute, and payment records consistent while Stripe sends related webhook events almost simultaneously across multiple workers.
The platform enables each tenant to manage customers, invoices, installments, payments, refunds, disputes, and payment workflows while keeping its data fully isolated from other tenants.
I was responsible for the complete development of the system, including architecture, database design, APIs, payment integrations, webhook processing, background workers, tenant isolation, deployment, and production reliability.
The business needed one invoicing platform capable of supporting multiple organisations, each with its own users, customers, payment settings, and operational workflows.
The largest technical challenge was maintaining data consistency when multiple Stripe webhook events arrived almost simultaneously for the same payment or invoice.
The system uses schema-based multi-tenancy with PostgreSQL and django-tenants. Each organisation has its own isolated PostgreSQL schema while shared platform-level information remains available in the public schema.
Invoices can be created for standard customer payments, taxi and dispatch bookings, restaurant bookings, website orders, employee-generated transactions, manual payments, and installment plans.
A payment request does not immediately mark an invoice as paid. The invoice is updated only after the relevant Stripe webhook confirms that the payment has successfully completed.
Stripe can send several related events for the same payment within a very short time, including payment intent, charge, invoice, refund, and dispute events. In a multi-worker environment, those events may be picked up by different workers at the same time.
The platform processes Stripe dispute events and links each dispute to the relevant invoice or invoice installment. Missing webhook fields do not overwrite existing dispute values, which protects previously stored information during partial webhook updates.
Webhook events are queued and processed outside the HTTP request to avoid timeouts and improve reliability.
Invoice status changes are based on Stripe webhook confirmation rather than only client responses.
Redis locks prevent concurrent workers from updating the same payment, invoice, trip, or installment.
Every event can be processed safely more than once without producing duplicate business actions.
Each organisation operates inside its own PostgreSQL schema while shared platform data remains centralised.
Payment processing is centralised while transport, restaurant, website, employee, and general invoice logic remains modular.
The final system provides a reliable payment foundation for multiple products and business workflows. The queue-based architecture significantly improved reliability by preventing long-running webhook requests and reducing race conditions during concurrent payment events.