Client

Our web studio was commissioned to develop a B2B platform for vendors and buyers of refrigeration and air conditioning equipment. On the platform, suppliers can add their products to the catalog, publish articles, advertise their services, and search for clients and contractors for free. We developed the website and implemented the Drupal Commerce framework. But the latter turned out to be an awful waste of time.

How did this happen?

The client asked, among other things, to implement a subscription functionality on the website. The subscription expands the free plan and allows users to publish more articles, attach more files, and post job ads.

The functional spec stated that information about a subscription request should be stored in Lexoffice, a third-party service. However, the client did not specify which tool should be used to implement the functionality on the website itself. Based on the experience, we decided to use Drupal Commerce for this. After installation, questions followed, such as why checkout appeared on the site and so on.

Drupal Commerce is a set of modules that help businesses sell online. With it, the site owner presents products, accompanies the client at all stages of placing an order, tracks invoices, receipts and payments, and arranges delivery.

Role of Drupal Commerce

As the work progressed, details that were missing from the specification began to emerge. It turned out that the payment for the subscription was to be made through a third-party service. Here was what the process looked like: the user selected a plan, clicked Submit, the data was collected from their registration form or profile, sent to a third-party API to verify tax information, and only then to Lexoffice. The site owner saw the order in the Lexoffice admin panel and sent the client an invoice, which he paid through a bank.

However, subscriptions in Drupal Commerce can only be paid for directly on the website. The module cannot process such a complicated path. By default, it doesn’t even have a subscription feature. In this case, Drupal Commerce was used only to store the plan terms, create orders, and send them to Lexoffice. Payments were processed by another service. As a result, the module’s acquiring functionality was not needed here; simple Drupal would be enough.

What could have been done better

The subscription feature could have been realized faster and without resorting to additional Drupal modules. We spent a lot of time integrating the website with Lexoffice (about 80 hours) due to this service’s poor documentation. Another 40 hours were spent changing the Orders entities in Drupal Commerce. Without the module, we would have written a custom service that would send the order to the payment service in 20 hours and call it a day.

But Drupal Commerce can still come in handy! The client is considering expanding the website’s functionality, for example, adding the option to publish 10 more advertisements for an additional fee. In this case, the module will be used for its intended purpose.