Introduction
We implemented a system that allows multiple co-working spaces to list their properties and allow renters to book seats at these co-working spaces.
We used Stripe Connect to implement payments including distributing the payment to the vendor/space owner after deducting a configurable platform share.
There are a number of important issues we handled in implementing this as a robust system that can work well in the real world with multiple edge case scenarios being handled.
We used an open-source npm package developed by our team to implement large parts of the payment system.
Before we dive deep in different modules, let us first discuss the types of users in our system:
- User/Renter – They are the main users of the system; they can book any co-working space available for booking in our system.
- Provider – These users can list their properties for renters to book, they also get the ability to preview the booking status of their listed properties in the system.
- Sub Provider – These users are invited by providers to manage their listed properties in the system.
- Admin – They are the moderators of the system. Users, providers, and sub-providers can contact admin regarding any query.
Credits
Huddlespot is just a platform and its ultimate goal is to connect the renter and the provider seamlessly. Sometimes users may face unsatisfactory experience with his/her booking made through our system. The system has to rely on the provider for co-working space booking experiences. Sometimes, to compensate for the unsatisfactory experiences faced by any events outside the system, the administrator can add credits to the user’s account which can be redeemed in their next booking made through the Huddlespot app. Credits can also be earned by inviting new users to Huddlespot platform. Referrer gets a fixed amount of credit set by the administrator which is credited to their Huddlespot account at the initiation of the invitee’s first booking. There is a weekly settlement of accounts by the system admin. This is to compensate the providers when credits are used by the renter towards paying for any booking of their property by the user.
cancellations
After booking a co-working space from the system, there may be situations where the user may want to cancel the booking due to some reason. Considering both the user and the provider, cancellation charges change dynamically depending on the time left for the booking starting to start at the time of cancellation. The cancellation charge is deducted from the total booking amount and the remaining balance is refunded to the user using the stripe refund module. If the booking involved credits, then after deduction of cancellation charge the remaining credit is reverted back to the user account. To simplify this, we have divided it into 4 categories –
The booking cancellation time is less than 24 hours than the starting time – In this scenario, if the user cancels the booking, then he/she will face high cancellation charges as it is not possible for the provider to get a replacement in such a short period.
The booking cancellation time is more than 24 hours but less than 48 hours than the starting time – In this scenario, if the user cancels the booking, then he/she will face cancellation charges but less than the previous one. Even though it is difficult for the provider to get a replacement, the system is designed to consider on behalf of both the user and the provider.
The booking cancellation time is more than 48 hours but less than 1 week than the starting time – In this scenario, if the user cancels the booking then he/she will face low cancellation charges and the provider gets sufficient time to get replacement as well as a part of the actual booking amount in form cancellation charges.
The booking cancellation time is more than 1 week than the starting time – In this scenario, if the user cancels the booking then no cancellation charge is applied while cancellation.
This doesn’t stop here, booking cancellation charge percentage changes depending on the type of duration opted for while booking the seats at the coworking space.
The above scenarios are based on if the user cancels the booking. The system also accepts cancellation which can be initiated by the administrator or the provider/sub provider of the property. In such cases, the booking amount is fully refunded to the user. In addition, the system admin may reward credits to the user as a token for the convenience caused to them by a short notice cancelation by the provider.
Booking Modifications
There can be circumstances when a user wants to modify the date and type of booking. In those cases, cancelling the current booking and making a new one just to modify the date and type may be cumbersome and levying the cancellation charges make some users unhappy too. To avoid this poor experience for the user, we allow the user to request for a booking modification through Huddlespot app. Booking modification is a two-way process which is designed to handle such incidents.
The user can modify a booking if the booking start time is more than 24 hours. User can open the booking, select modify and enter the details of the new desired booking i.e. Starting & End date and time, number of seats, space type on the same property. The user cannot change the property through this workflow. If there is availability as per the desired booking parameters, the booking modification request is submitted by the user. To prevent ill-usage of this feature, cancellation of booking is blocked while booking modification is in the requested state. Huddlespot administrator gets the booking modification request issued by the user, the administrator previews the modification request and gets 12 hours to either accept or reject the modification request. Administrator may add a penalty charge at the time of approval if required. If the administrator fails to respond within 12 hours, the modification request will be automatically rejected. By approving the modification there can be 3 situations:
Previous booking amount and modified booking amount remains the same
- When the administrator accepts the booking modification, the previous booking is cancelled and the new booking is created.
Previous booking amount is more than the modified booking amount
- When the administrator accepts the booking modification, the previous booking is cancelled and the new booking is created.
- The remaining amount will be credited to the user as credit, while the extra balance will be added as a debit for the provider and will be adjusted (if possible) when the weekly payout is generated. If it is not adjusted in this week’s payout, the balance will carry forward to the next week.
Previous booking amount is less than the modified booking amount
When the administrator accepts the booking modification, a new booking is created with pending payment status.
Users can see this pending payment booking in Huddlespot User App. The user gets 12 hours to make the due payment.
If he/she makes the payment within the due time, the previous booking is cancelled and the new booking is confirmed.
If he/she fails to make the due payment. The modified booking will be cancelled and the previous booking will remain active and unchanged.
Seats for both, the previous booking and the new requested booking are blocked till user pays or their 12-hour period ends.
Weekly reconciliation of accounts
Bookings made through the system includes credit as a payment method. Since credit is a virtual balance only recognizable in the Huddlespot platform, the provider needs to get its share for the booking if credit is used. At the time of making a booking, if credit is used for the booking, the system notes the credit amount and creates a due transaction under the provider. Every week a detailed weekly payout report is generated for the administrator to clear all the due payout to the provider.
Conclusion
While popular and successful applications make handling a marketplace very simple and obvious, implementing a system like this required careful consideration of various scenarios and the strategy had to be reworked as new scenarios are introduced after user inputs. The current system is a robust, scalable solution, capable of handling different real world situations with ease. Stripe Connect is a powerful library that makes implementing this system relatively easy. There are a lot of other conditions to be considered which may vary from system to system and will depend more on policy, users, and other circumstances.
