Coworking Portal Development: Booking, Access Control, Memberships

A coworking administrator spends up to 3 hours daily coordinating bookings, keys, and tariffs. N+1 phone calls, double bookings, forgotten NFC tags — typical pain points. A coworking portal solves these problems: automates booking, integrates with access control systems (ACS), and manages memberships. According to industry research, double bookings occur in 15% of cases without a system. Without automation, these issues grow with scale.

We develop coworking portals on a stable stack: Laravel, React 18, TypeScript, PostgreSQL, Redis. Hot Desk, Fixed Desk, meeting rooms and offices are supported. Each type has its own booking rules, minimum period, and price. For a 200-seat coworking space, we implemented visual floor plans — residents choose a desk on the map, the system checks availability and blocks double bookings. This reduces administrator time by 70% and eliminates human error.

What Problems We Solve

Double Bookings

Without real-time synchronization, two residents can occupy the same spot. The portal uses database-level locks and conflict notifications. For example, when trying to book an already occupied desk, the system shows alternatives from the same cluster. Loss from a single double booking per month can reach 15,000 rubles per workspace.

Complex Tariffs

Hot Desk, Fixed Desk, meeting rooms — each type requires its own rules. We implement a flexible tariff grid with automatic cost calculation and package support. For instance, a "10 visits" tariff is active for 30 days, while "Unlimited" auto-renews via Stripe Billing.

Access Control

ACS integration via API (Perco, SKAN, Parsec) or server-side QR code generation. The resident receives a code upon booking, valid only during active membership. When the tariff expires, the code is deactivated instantly.

How We Do It

Stack: Laravel 11 (PHP 8.3), React 18, TypeScript, PostgreSQL, Redis. For interactive floor plans — SVG with interaction library. Payments — Stripe Billing with webhooks for status synchronization. Example: for a 200-seat coworking space, we implemented Hot Desk with visual desk selection, meeting rooms with calendar (Google Calendar sync) and Parsec integration via REST API. Time from start to first resident — 3 months.

Work Process

1. Analytics — study business processes, load, ACS requirements.
2. Design — prototype booking, tariffs, personal account.
3. Development — back-end and front-end, integrations.
4. Testing — load testing (1000 simultaneous bookings), scenario verification.
5. Deployment and training — deploy on VPS or cloud, train administrators on panel usage.

Optimizing Coworking Costs

Automation of routine operations reduces time spent on booking and access management by 70%. Residents book spots, renew tariffs, and gain access on their own — without staff involvement. The administrator only monitors and handles non-standard situations. Investment in the portal pays off within 6–12 months due to reduced workload and fewer errors. Saving administrator time can save up to 1.5 million rubles per year.

ACS Integration: Benefits

ACS eliminates physical key handover. Upon booking, a unique QR code or access code is generated and passed to the control system. At entry, the resident scans the code or taps an NFC card — if membership is active, the turnstile opens; if expired, access is blocked. All in real time. ACS implementation cost ranges from 300,000 to 500,000 rubles depending on the number of turnstiles.

Custom Development: Flexibility for Your Business

Note: when a standard solution doesn't cover specifics — non-standard tariffs, unique access rules, integration with existing equipment. We design the portal for your business, not fit it to a template.

Dynamic Pricing and Tariff Grids

The tariff grid must account for peak loads and seasonality. We offer dynamic pricing based on occupancy, increasing revenue by 15-20%. Residents appreciate transparent rules and automatic renewal.

Timeline and Scope

Cost is calculated individually — depends on tariff complexity, number of integrations, and required performance. If the timeline works for you, leave a request for a preliminary assessment.

What's Included

• Portal source code (GitHub repository)
• Admin panel for managing bookings, tariffs, and members
• API and deployment documentation
• 3-month warranty + post-production support
• Access to servers and payment provider

Comparison: Custom Development vs Off-the-Shelf CRM

Custom portal offers flexibility but requires investment. Off-the-shelf solutions are faster but rarely cover all scenarios.

Contact us to discuss your project. Get a consultation from an engineer and a preliminary development plan. We will help automate your coworking space.

Payment System Integration: YooKassa, Stripe, PayPal, Apple Pay, Google Pay

Conversion dropped by 12% immediately after the redesign. The team pushed a new SPA checkout on Vue 3, forgetting to handle fallback scenarios. Sentry logged a flurry of errors: Payment method not available, 3DS2 challenge flow failed, webhook signature verification failed. Users abandoned carts at the payment method selection stage. Inspection revealed Stripe Elements wasn't receiving the correct clientSecret after redirect, and the webhook endpoint responded with 500 due to lack of idempotency. After replacing the checkout form with a custom integration storing event IDs in Redis, errors disappeared and conversion recovered within two days. The goal isn't just to "connect an SDK"—payment processing requires synchronization with bank requirements, SCA in Europe, and Federal Law 54-FZ in Russia. Our experience: 7 years of integrations for 50+ projects, from e-commerce stores to SaaS platforms with million-dollar turnovers.

What's Included in Turnkey Work

• Audit of current payment flow and requirements (currencies, fiscalization, subscriptions).
• Provider selection based on geography and business model.
• Backend integration (Laravel/Node.js/Go) with webhook handling, idempotency, and retries.
• Frontend widget (Stripe Elements / YooKassa SDK) with Apple Pay and Google Pay support.
• Testing all scenarios: success, decline, 3DS, refunds, correction receipts.
• Monitoring of first transactions and documentation.

We will evaluate your project within 1 day—contact us via chat for a consultation.

Provider Comparison: Which to Choose

Stripe wins on flexibility: 135+ currencies vs. YooKassa's single currency. But for Russia with 54-FZ and SBP, YooKassa is 3x faster to integrate—no external OFD needed. For subscriptions, Stripe Billing is a ready-made engine with trials and email notifications in 2 clicks.

How to Choose the Right Provider?

Three key points. Where do your clients live? Only Russia → YooKassa; globally → Stripe. Do you need 54-FZ fiscalization? Yes → YooKassa; otherwise Stripe + cloud OFD. Do you plan subscriptions? Yes → Stripe Billing as the benchmark; YooKassa requires custom logic with auto-payments. Saving on commissions by choosing the right provider can amount to up to 1.5% of turnover. For a project with 2 million RUB per month, that's 360,000 RUB per year.

Where the Real Difficulties Lie

Setting up a test mode takes an hour. Properly handling all scenarios takes weeks.

Webhook reliability. A webhook may not arrive—server unavailable, timeout, network issues. The provider retries with exponential backoff (Stripe up to 3 days). The handler must be idempotent: if payment.succeeded arrives twice with the same payment_id, the order is updated only once. This is implemented by storing event IDs in Redis with a TTL.

3DS2 and redirect flow. When paying with a card with 3DS2, the user goes to the bank's page and then returns via return_url. During this time, the session may expire or the cart may be cleared. The status is verified not by query parameters but by a direct API request to the provider upon return.

Partial refunds and receipts. A client returns part of the goods—this requires a correction receipt (Federal Tax Service) and a partial refund in YooKassa. Stripe natively supports partial_refund. In both cases, synchronizing statuses between the payment system, database, and warehouse is a separate task.

Currency limitations. YooKassa only handles rubles. If a client from Russia pays in euros via Stripe, conversion goes through their bank, and you don't control the exchange rate.

Why Do Webhooks Require Idempotency?

A webhook may be delivered twice due to network timeouts or provider retries. Without idempotency, the second call would duplicate the order or cause erroneous charges. The solution is to store a unique event ID (e.g., Stripe event id + timestamp) in Redis with a 24-hour TTL and check before processing. If the ID already exists, return 200 without executing business logic. Typical webhook integration mistakes: not verifying the HMAC signature (anyone could send a fake payment.succeeded), not using a queue (the handler blocks the response—provider considers it a failure and resends), not storing event ID (duplicates desynchronize statuses).

How We Build the Integration

Architecture. We never store card data—only tokens from the provider. Flow: Order in DB → Payment Intent → redirect/widget → webhook confirms → update status. The source of truth is the status in the payment system.

For Laravel we use stripe/stripe-php or yookassa-sdk. Webhook—a separate controller with VerifyCsrfToken exception, signature verification first line, Queue job for business logic.

For Next.js/React—@stripe/stripe-js + @stripe/react-stripe-js. PaymentElement includes Apple/Google Pay automatically. Example:

const stripe = await stripePromise;
const { error } = await stripe.confirmPayment({
  elements,
  confirmParams: { return_url: 'https://example.com/order/thank-you' },
});

Testing. Stripe CLI: stripe listen --forward-to localhost:8000/webhook. Test cards for all scenarios (3DS, decline, insufficient funds). Cypress checkout flow test in CI—mandatory stability guarantee.

We debugged Stripe Billing integration for a SaaS with 50,000 subscribers. The issue was handling invoice.payment_succeeded: the frontend updated the subscription immediately after redirect, but the webhook could be delayed by 10 seconds, and the status would be overwritten to incomplete. Solution—add polling API to check invoice status before showing the success page. This reduced erroneous cancellations by 18%.

Process and Timeline

Audit → provider selection → backend → frontend → tests → deploy → monitoring.

Pricing is custom. Order integration and your checkout won't crash on the next update.

Links:

• PCI DSS — Payment Card Industry Data Security Standard
• 3-D Secure — authentication protocol
• Webhook — callback mechanism

We guarantee: 7 years of experience, 50+ successful integrations. Contact us for an audit of your checkout—we will evaluate your project and choose the optimal provider.