GSoC 2018: Codeless Payment

Implemented by Shivam Kohli as part of GSoC 2018 under the mentoring and guidance of Florian Dold.


Codeless payment is a component that sits between the seller's frontend and the GNU Taler merchant backend. This component has a web interface, where payment buttons are configured. Registered merchants can manage their inventory and simultaneously create a 'Buy Now' button for a specific product. This code can be directly copy pasted on the seller's frontend and can be used for 'Pay with Taler'.

Use Cases

The various use cases and features of codeless payment are:

  • The primary use case is the registration of the merchant. The codeless payment backend provides a secure django authenticated login to the merchant. The registered merchant can add inventory (both digital as well as physical) in their stocks. They can manage inventory and simultaneously create a 'Buy Now' button for the product. The merchant also monitors the orders placed and updates the status of the order which helps in shipment tracking.
  • Merchant has the flexibility to add two types of inventory as follows:
    • The merchant can upload digital inventory (like a PDF or HTML page) via the codeless payments frontend and the user can then purchase it and view the version hosted by the codeless payment frontend.
    • The merchant can add any physical inventory available in his stocks. While adding these inventory, the seller is prompted to add minimum quantity of product that is required to be maintained in the stock. Whenever the stocks run below this limit the seller would be notified (currently this feature has not been added but soon email notification would be added).
  • The buyers will access the seller's frontend where the code for the 'Buy Now' button is present. When this button is triggered, they are redirected to codeless payment backend and eventually redirected to the payment page. After successful payment, the buyer can also track their shipment for physical products or view the digital version hosted by the codeless payment frontend.
  • The other use case of the codeless payment backend is to handle the event when the 'Buy Now' button is triggered on the seller's frontend. To perform the payment the backend communicates with merchant backend api. After successful payment, the users are redirected to the fulfilment page.

Dynamic Merchant Instance

The documentation for the API to dynamically manage merchant instance can be found here.

Use Case Diagram

Link to the contributions made

  • Codeless Payment Backend (Link)
  • Documentation to dynamically manage Merchant Instances (Link)

Future Work

The backend of codeless payment is very robust and can be easily extended as per the requirements. It is adaptive to add new features to this framework. But as per the discussion and the scope of this project, there are various features that will be soon added in the Codeless Merchant Backend. The list of future work is as follows:

  • To send email notification to the merchant when the stocks run below a certain limit. The minimum quantity required to be maintained in the stocks is currently taken from the merchant(specific to each product) but no such notification system is designed.
  • To add API access to the merchant backend via the codeless payment service. Basically, it would be used as a hosting platform for multiple merchants. There would be an additional user interface part in the codeless payment service where a logged-in merchant can generate an API key. This API key can be used to access the functionality of the merchant backend in a controlled way. After requesting an API key, the page would display the generated key and a base URL for the API to use by the seller, which is handled by the codeless payments service.
  • Mapping every seller account to a separate merchant backend instance. This is not required for a simple version of codeless payments, but as soon as API access for sellers, this is a useful feature. The codeless payment service then can also double as a hosting service for merchants.
  • To add various analytics for the merchant. Various analysis could be performed on the orders placed for the respective merchant. Some of the analysis that can be performed are displaying the most frequently purchased product, some insights about the shipment tracking, analysis of products based on delivery location, etc. For this part, dicussions and some more research have to be done before proceeding to the implementation.


Home page

Product page

Shipment Tracking