Get Ready for the Token Sale!

Unikname Development Report #17 – Make vs Buy

2 September 2021 | News

Logotype Unikname Bleu

Guillaume Nicolas


Welcome to the 17th edition

Every month we share a short summary of what happened during the last four weeks within the Unikname ecosystem with our community. This month has been particular with the publication of a brand new website: The Unikname Shop. Therefore, we decided to give you a detailed feedback on our choices, the reasons behind them, and the development process.
Welcome to the 17th edition!

A few months ago, the Unikname team started thinking about a new tool to add to its arsenal. We wanted to start selling Unikname products to our community members.

Let’s begin with the why

The Unikname Network blockchain hosts Non-fungible UNIKNAME tokens fueled by $UNIK utility tokens. Currently, protocol tokens are created to reward each new block. Only Unikname Network delegates benefit from these tokens.

Some delegates have started sharing their rewards with their supporters, spreading $UNIK tokens among UniknameID owners. But, this operation is voluntary. A lot of community members have expressed their wish to get a shorter UniknameID to have a better experience.

Unfortunately, at the moment, the only way to get a shorter UniknameID is to buy it with $UNIK tokens. So we wanted to offer our community the possibility to get short UniknameID through other cryptocurrencies.

Another goal was to accelerate network economy by injecting it with more protocol tokens, thus increasing liquidity. These tokens could be used to create activity in the network (vote, get UniknameID, customize UniknameID, claim badges,…).

As you might have guessed, we wanted to create our own e-commerce website.

Technical requirements

If we merge these features in a technical architecture picture we have this:

The basic components of DID architecture

The picture above is a non-exhaustive illustration of our technical needs: 

  • a web server to deliver all user pages and back-office dashboard,
  • a backend server to manage our shop: products, orders, customers, emails, coupons, payment, cards,…
  • a payment service, or multiple ones interfaced with our backend server,
  • a database, to persist shop data: products, orders, customers,…

The “make vs buy” dilemma

To build this new project we were faced with a choice: build from scratch or buy an existing product.

In fact, it’s a very common dilemma faced by a lot of organizations. Here is an article that explains this predicament very well.

In our situation, important factors were time, costs, and human resources.

On the topic of time. We are still at an early stage of development but we already have a huge ecosystem (a blockchain, as well as multiple daily-used apps and websites) with a small IT team. And we couldn’t dedicate our time to this new product. We have to continue to improve apps, manage the network, and do support tasks.

Another deciding factor was team experience. None of us had any prior experience working on an e-commerce solution, neither technically nor as a business expert. So it would require some time to learn all business specific use-cases and rules. But even after learning all of that, there is no substitute for experience when trying to build a good product.

The final factor was cost. Is it worth it to recruit new collaborators or involve dedicated team members on a new project, without knowing if it’ll be accepted by the community? We had to compare solutions economically: time (and money) spent on building the foundations of this new platform vs money spent buying, configuring, and supporting an existing product. We couldn’t answer this question without an e-commerce product market overview.

These considerations led us to make the current choice: use an existing e-commerce product and spend time configuring and customizing it.

The final setup

For now, two of our websites are built on top of WordPress: and The others are built with Javascript frameworks. Basically they use the same frameworks that these products are build on.

You might wonder why we chose to use different tools for these two particular websites. Because both deliver static content that is updated very frequently by our communication team (rewording, images, sections,…) according to evolving business strategies. So we chose to set-up easy-to-use tools to reduce IT-dependency for our non-technical team members.

Our WordPress instance is deployed on one of our cloud providers’ server as a PHP application.
We use Bedrock as dependency in a Composer PHP project to manage our WordPress application. With this architecture, we can easily manage the version of WordPress (and its plugins) that we are using and set up a development flow similar to other web projects thanks to git version control system. The cloud provider application is listening to git updates in order to deploy new versions. And we can easily rollback to previous version when something wrong happens.
In parallel of this PHP application, WordPress requires a MySQL server to persist all website data (like pages, users, plugin configuration and so on… ). This database is managed by the same Cloud provider, encrypted, and communicates with the WordPress application through an internal network.

To decrease page building difficulty, we chose the Divi plugin which is free and provides a graphical interface to build pages (similar to building a presentation document). This tool is powerful but it has some drawbacks. For instance, it consumes a lot of both browser and server resources during builds.

So which product could fit perfectly with our current architecture and e-commerce requirements?

We chose WooCommerce for many reasons:

  • it’s completely free, reducing cost of “buying” a ready-to-use product,
  • it’s highly customizable, thanks to themes and plugins,
  • it can provide all identified features,
  • it has a lot of users and a big community (top 1 of 2021 market shares), so we know it is reliable,
  • it’s very easy to use (from a non technical point of view).
  • it works on top of WordPress.

WooCommerce is a WordPress plugin, so we simply had to look for this plugin in the plugin marketplace, add it and then activate it from our WordPress back-office. After a 5-mn configuration we had our first version of the Unikname Shop. This initial version already includes lot of previously identified features. By default, initial configuration creates 3 new pages with default templates: a Cart page, an Account page, a Products page, and a Checkout page.

We did it!

The basic components of DID architecture

That’s not all folks

Default WooCommerce configuration is good, but we had to manually supply content and do some UI customization to fit our needs.

First, we obviously needed to manually register every products. Then WooCommerce dynamically fills each product page with related content.

We then created an “All Products” page to gather products by category and add category information.

Some WooCommerce pages are harder to customize because of how the plugin is built. Let me explain. WooCommerce comes with pre-built “template” pages used by default (for example, the default pages quoted above and created after plugin configuration). These templates contains WooCommerce components that are referenced using WordPress “shortcode”. Shortcodes are simple “tags” you can put in your page (like [My_Component]). When rendered, your component plugin will be called by page rendering to get the related html code. Some shortcodes can take arguments in order to be customized. Depending on how components are built, customization techniques are different.

For example, to customize the product page, we had to create a dedicated page layout to be applied when the product page is queried. Then, we could build our own product page, only adding the required WooCommerce components (like WooImage, WooTitle, WooAddToCard,…). We could even add a “WooUpsell” component at the bottom of the page to show more products to customers, or specific shipping information. This one was easy.

But, for other pages like “MyAccount”, WooCommerce main component (called [woocommerce_my_account]) couldn’t be customized from the back-office. This component has static html which makes it impossible to update from the outside (like replace or remove words). So we had to duplicate the component into a WordPress child theme. Child themes are a way to extend current themes with small changes, keeping the current parent theme customization. With that, you can keep parent theme configuration from your back-office while adding new behavior in the child theme. It’s a pretty good practice but it has some drawbacks, like you have to keep track of parent theme updates in order to replicate theme into child theme overwrites. We simply copy/paste the “WooCommerce/myaccount/dashboard.php” file into our child theme repository and then update the file, removing unwanted parts. We used the same technique for Account profile edition.

To continue customization, we’ve added some WooCommerce plugins:

Using a child theme is a good way to customize appearances and overwrite components but it can also be used to add logic during default WooCommerce or WordPress flows (like account creation, order submission or mail content).

To be able to buy on our platform, customers should be connected with their UniknameID. We naturally used the Unikname Connect WordPress plugin to manage and secure our WordPress instance accounts (admins, content managers and customers). By the way, that’s one reason we had to update the MyAccount page: to disable password edition fields.

We added conditions on Unikname shop access: every customer should be connected with an active UniknameID and have been whitelisted on our HUB (see announcement). To do so, we had to interfere with the default WordPress user registration flow. WordPress is good enough to enable developers to add custom code at a lot of point of execution without modifying the source code nor restarting the server. This feature is called “Hook” and can be of two types: actions or filters. To sum-up, “Hooks” are callback functions called at runtime (with or without arguments) by WordPress (see reference) or by plugins (like WooCommerce) and used by developers to interact with or modify the UI, or update input data.

We used “action” Hooks to block customer registration and redirect to 403 page if their UniknameID doesn’t meet our criteria. We also used “action” Hook to add payment information to email sent to customer after payment has been received (like on-chain transaction id, reception date or amount received).

The basic components of DID architecture

Final step, payment

WooCommerce comes with pre-installed payment plugins:

  • Direct bank transfer
  • Check payments
  • Cash on delivery
  • PayPal

These 4 classical solutions are ready to be configured to start receiving fiat currencies directly to your bank account.

At Unikname, our first priority was to enable payment using decentralized currencies. They reflect our convictions and are heavily requested by our community. We chose Ethereum for its simplicity, popularity, and community (not for its fees 😉 ).
We therefore had to choose a WooCommerce Payment plugin accepting Ethereum currency.

What does a WooCommerce cryptocurrency payment plugin do?

  1. it provides a new payment option in the checkout page,
  2. it provides a specific payment page to show payment instructions to user,
  3. it watches on-chain transactions and looks for user payments (several techniques are possible),
  4. it notifies WooCommerce that payment has been received in order to update the order state.

A lot of plugin do the work, but not in the same way:

  • some plugins are centralized at different levels (from step 2 or 3),
  • some provide automatic cryptocurrency exchange and let user pay in Bitcoin while sending shop owner equivalent Ethereum amount,
  • some apply KYC (Know-Your-Customer) processes during the payment process which add friction for customers,
  • some only provide the infrastructure to listen to on-chain transactions or provide APIs to do it by yourself,
  • and some do everything directly in the customer browser (which is highly sensitive to customer environment and behavior).

Every solution has advantages and drawbacks. We chose to go the API road and simply listen to on-chain transactions to start the shop with our first customers.

The good news is that it’s very easy to switch between multiple payment plugins or to provide multiple payment medium at the same time. So what’s available today will probably change based on customer feedback.

Now we can conclude

In this article we tried to give you many insights into the development of Unikname Shop, answering “Why” and “How” we’ve created this new website.

For now we’re satisfied by the current result and we think that we’ve made the right choice (“buy”).

Using existing products gave us time to focus on the features we wanted to include instead of the foundations of how to build an e-commerce platform. It gave us enough flexibility to add custom requirements. And it gave us free time to work on other products and do several iterations with all teams.

From a financial standpoint, it’s also pretty worth it because of the free plans of the chosen plugins and the pretty “low” prices of pro plans (compared to the time spent on implementing the same feature by ourselves).

We would be happy to get your feedback on this article and on the final results on our Discord server.