Sharetribe & React Developer at SoftwareSupp
A reverse marketplace is an unusual type of service. The difference from a regular marketplace is that the sellers are bidding for a particular offer. The creator of the tender can then choose whom to pay for the services.
Building a reverse marketplace with Sharetribe Flex seemed difficult, because here, at pickSaaS, we have an environment where experts are bidding for specific job offers. The tool does not provide any help for this type of feature. The creator of the tender (called “listing” in Sharetribe) cannot be the same person paying for the service. In other words, only the owner of the listing can receive payments. At first, we thought about it as a huge challenge to solve, but as you will see, the solution is quite simple.
The only way for the expert to receive payments was for him to have a listing. We did not want to lose the possibility for the users to post their job propositions. The only solution was to add a category to the data. The listing can now have one of two types: job or expert. The best way to do this is to create an additional public data field called “category” and set it at the beginning of the listing creation.
The best choice to accomplish this is to create two separate URL routes that redirect you to:
Of course, both of the listing types will have different data. Inserting the category variable right at the commencement gives us the occasion to exhibit different paths for the user. In our case, this decision was crucial because the buyer can see all the fundamental data about the expert who applies for the job.
In Sharetribe Flex, payments work within the transaction process. There is practically no possibility to transfer data between users outside the transaction. Because of this, the solution to make the platform work was to connect two transaction paths.
Here is where the reverse marketplace changes back to the regular one. Here the user can pay for the seller’s services, get a refund, etc. The default Sharetribe Flex transaction process is a perfect example of how such a path can look.
When the bidding is coming to an end, and the client decides to accept one of the provided bids, he needs to make an action. For example, every transaction can have an accept button that redirects to a particular seller profile. For that to occur, the other-party bidder profile needs to get fetched. You can either choose to do this every time you open a transaction page or store the necessary seller’s information in the transaction’s private data. The second solution is vulnerable to every change in the bidder’s listing data.
From here now on, there are many possibilities to finish the bidding. You can either choose to close every other bid, allow to chose multiple offers, close the listing, etc. It all depends on the service you are providing.