Summary

It’s surprising for a blockchain protocol being in production for several years already, that there are no existing, self-custodial solutions to integrate DOT as payments into any of the major eCommerce platforms.

Like, are we seriously talking about adoption when there’s no readily available tooling to sell material objects for DOTs?

We found it the hard way: we’ve allocated only a week for our shop.kampe.la to go live prior to us announcing Kampela DevKits preorders at Sub0. And we’ve barely made it — having to quickly hack a DOT payments processing system for OpenCart instead of our original plan of “nah, we just deploy the most-used of the existing ones” (there were none; neither there were any for Magento or Shopify).

With this application, we are proposing to fix this. We will build plugins for top 3 eCommerce SaaS platforms and top 5 FOSS eCommerce engines to support seamless and self-custodial DOT payments processing: set price in DOTs or use your platform’s currency converter (providing the exchange rates for that is out of scope for the current application), ask visitor’s wallet extension to sign the transaction (or just provide them an address to pay to if none found), wait for the transaction to finalize — and get your order marked as “paid” in the admin backend of your shop.

Development would require 16 weeks with a team of 4 developers: Rust Backend Engineer, JS/PHP/Ruby Frontend Engineer, an Integrations Engineer/DevOps, and UI/UX Designer.

All work results will be provided as FOSS-licensed repos on Github, with released artifacts being published in relevant plugin marketplaces if applicable — and verbose, easy to follow deployment instructions provided when there is none.

Our expectation is that enabling people receive DOTs as payment in eCommerce will have a positive (even if hard to predict under current market conditions) impact on adoption, while putting DOT in the same league with BTC and ETH (while being significantly more convenient due to short block times and deterministic finality) when it comes to receiving crypto payments without need for trusted intermediaries.

Our team has both the proven track record of shipping Treasury-funded projects in timely manner (Kampela 1 2 3 4, metadata project) and has already developed a first iteration (actually, more of an MVP) of the system for our shop.kamle.la storefront.

Technical details

Instead of building a monolithic plugin, we use a two-component architecture: shop engine plugin and a separate payment processing daemon. This allows a high percentage of code reuse across multiple engines to support, while allowing us to leverage the preexisting logical flows in the shop engines (existing mostly to interact with TradFi payment providers via some external API).

The payment processing daemon is written in Rust and implements the pretty common “derive a unique address for each transaction” payment attribution pattern. Daemon is a self-contained application with zero external dependencies, capable of running in a container in case of a Docker/K8s deployment, and configurable via environment variables (12factor.net style).

The logical flow here is the following:

1. Shop engine registers the payment intent from the user (cart checkout) and generates an internal unique transactionID for it.
2. Shop sends a “pending transaction” info to the daemon, providing both the transaction ID, amount to be paid and possibly some situation-specific flags.
3. Daemon uses the transaction ID to derive a new, transaction-specific, address and reports it back to the shop.
4. Shop uses this transaction-specific address to either compose a transaction in browser with some web3 wallet extension available — or just provides an address and the amount to pay.
5. Daemon subscribes to the balance changes of the freshly-generated address (via a configurable RPC endpoint currently, can be replaced with Smoldot with some additional engineering effort which is out of scope for this application).
6. As the finalized balance on the address reaches the specified payment amount, daemon empties the balance to the pre-configured “shop treasury” account. In case of the amount received being significantly larger than expected, the excessive amount is sent back to the transaction origin.
7. Daemon calls the eCommerce callback URL, reporting that the transaction has been paid and the order status can be adjusted accordingly.

Platform choice

FOSS eCommerce engines

1. WooCommerce
2. Magento
3. PrestaShop
4. OpenCart
5. Solidus

SaaS eCommerce platforms

⚠️ WARNING⚠️ Extension stores for SaaS platforms are fully controlled by their vendors. If the owners don't approve, we can't provide Kalatori plugins. However, we'll still publish all relevant sources on Github under an appropriate FOSS licence and leave it up to each individual SaaS customer to resolve their deployment issues with the vendor.

1. Squarespace online stores
2. Shopify
3. WixStores

Project deliverables and milestones

Milestone 1 (2 weeks): Publish first proof of concept store demo code (OpenCart)

Milestone 2 (8 weeks): FOSS-based stores implementations

Milestone 3 (6 weeks): Proper supply chain safeguards on all published code; SaaS implementations or proposals to overcome encountered blockers

Costs

Due to the easily parallelizable nature of the project, we anticipate all resources being evenly utilized throughout the project's duration.

Rust Backend Engineer: €18 800/month

Frontend Engineer: €17 100/month

Integrations Engineer/DevOps: €17 100/month

UI/UX Designer (part-time): €6 000/month

Total: €236 000

As usual with our treasury applications, the company receiving the funds is Alzymologist Oy, a registered Finnish company (Business ID: 3162030-9). All personnel listed above would be directly employed by Alzymologist Oy, and all relevant Finnish taxes are already included in the figures.

Edited 2023-11-03 renamed at requests of community, the internally used name "Kalatori" is silly indeed.

Edited 2023-11-04 As usual with our Treasury proposals, we're taking a carefully calculated and iterative approach. Therefore, adding support of AssetHub tokens (and USDC in particular), while definitely being on our radar — is out of scope for this pretty minimalistic "Iteration 1" proposal. Other things we're considering further down the road are supporting secondary assets (with automatic price conversions via some secure mechanism of fetching the exchange rates) and on/offramp integrations.