How to build a reverse marketplace with Sharetribe Flex

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 SoftwareSupp, 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.

Step 1: Divide listing types

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:

• the buyers create an offer page
• the seller’s create profile page

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.

Step 2: Configure the transaction process

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.

1. The expert applies for the job: This transaction process starts when the specialist types in the quote of the service and send it to the buyer. Before it can occur, the marketplace needs to examine if the user applying has a seller profile. This operation can be managed in the user.duck file by fetching all current user listings and filtering them by the “expert” category. Setting up the price in the transaction is also tricky because, by default, the price is set based on the listing. One can solve this issue in two ways: set the private data of the transaction or fix the negotiated total value. The chosen method is not significant in this step because no payment is happening. The only reason is to preserve the price data. All the transitions in this path need to be configured based on the marketplace owners’ needs.
2. The buyer accepts the particular expert offer:

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.

Step 3: Connect both processes

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.