\input texinfo   @c -*-texinfo-*-
@setfilename codeless.info
@include doc/version.texi
@include doc/syntax.texi
@documentencoding UTF-8
@settitle The GNU Taler Codeless Merchant Manual @value{VERSION}
@paragraphindent 0
@exampleindent 4

@copying
This manual is for the GNU Taler Codeless Merchant.

Copyright @copyright{} 2014-2018 Taler Systems SA

@quotation
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.3
or any later version published by the Free Software Foundation;
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover
Texts.  A copy of the license is included in the section entitled "GNU
Free Documentation License".
@end quotation
@end copying


@titlepage
@title The GNU Taler Codeless Merchant Manual
@subtitle Version 1.0
@author Shivam Kohli (@email{kohlishivam05@gmail.com})
@page
@vskip 0pt plus 1filll
@insertcopying
@end titlepage

@summarycontents
@contents

@ifnottex
@node Top
@top The GNU Taler Codeless Merchant Manual
@insertcopying
@end ifnottex


@menu
* Introduction::
* Installation::
* Inventory Tracking::
* Common Usage::
* Limitation::
* Future Work::



Appendices

* GNU-AGPL::                    The GNU Affero General Public License says how you
                                can copy and share the code of the `GNU Taler Exchange'.

Indices

* Concept Index::               Index of concepts and programs.
@end menu

@node Introduction
@chapter Introduction

This manual is an early draft that still needs significant editing
work to become readable.


@section About GNU Taler

GNU Taler is an open protocol for an electronic payment system with a
free software reference implementation.  GNU Taler offers secure, fast
and easy payment processing using well understood cryptographic
techniques.  GNU Taler allows customers to remain anonymous, while
ensuring that merchants can be held accountable by governments.
Hence, GNU Taler is compatible with anti-money-laundering (AML) and
know-your-customer (KYC) regulation, as well as data protection
regulation (such as GDPR).

@section About this manual

This tutorial targets system administrators who want to install and
operate a GNU Taler Codeless Merchant.
A component that sits between the seller's frontend and the GNU Taler 
merchant backend. This component should has a web interface, where 
payment buttons can be configured. Additional Component include 
inventory management, where the seller can configure the available 
stock for an item and will get notified when their stock runs low.
Currently, to accept payments with GNU Taler, people have to write 
their own code. By using this the merchant will be able to communicate 
with the merchant’s backend via a simple API.

@section Architecture overview

For the implementation the part MTV(Model-Template-View) pattern is
followed. 
The following three components has been included.

@itemize
@cindex frontend
@item A frontend which interacts with the customer's browser. The
  frontend enables the customer to place an order. Upon payment, 
  it redirects the user on the shipment detail form where the user
  adds his shiment details. Moreover, the frontend is a complete portal 
  where the merchant has the abality to create and manage his account.
  He has the flexibilty to manage his inventory.
@cindex Backend
@item The backend of codeless payment is very roboust and can be easily
  extended as per the requirements. The backend provides a lot of operations
  namely manage incoming and outgoing inventory, service for handling,
  payments, managing singup and singin for the merchant, and handle all the 
  url requests. This tutorial will describe how to integrate such a component
  to handle payments managed by Taler and also manage the inventory for the 
  merchant.
@cindex Database
@item A SQL which stores the order history for the Merchant backend and 
  keeps a track of the inventory. For now, the reference implemenation only 
  supports sqlite, but the code could be easily extended to support another DBMS
@end itemize

The following image illustrates the various interactions of these key components:

@c @center @image{doc/interaction, 1in, 1in}

@node Installation
@chapter Installation

Please install the following packages before proceeding with the codeless
payment backend compilation.

@itemize

@item
GNU autoconf @geq{} 2.69

@item
GNU automake @geq{} 1.14

@item
Django = 1.8

@item
requests@geq{} 2.19
@end itemize

There are no other dependencies required for the codeless payment backend to 
run.

@example
$ git clone https://git.taler.net/codeless.git/
$ cd codeless/
$ ./bootsrap
$ make
# make install
@end example


@node Inventory Tracking
@chapter Inventory Tracking

This chapter includes various sections on specific topics that might
be helpful to understand how inventory tracking operates.

@menu
* Database Schema::
* New inventory::
* Shipment Tracking::
* Order Creation::
@end menu

@node Database Schema
@section Database Schema

The following image illustrates the database schema used for inventory tracking:

@c @center @image{doc/database, 1in, 1in}

@node New inventory
@section New inventory

The Merchant can add two types of inventory
@itemize
@item Digital Inventory
  The seller 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.
  A large number of uploading format is accepted. The content-type
  of the uploaded file is determined by a self defined function in
  the backend.The stock for digital purchases doesn't run out.
@item Normal Product
  In this kind of product the seller has a flexibilty to add any
  product. While adding these inventory, the seller is promted to
  add MinimumQuantity of Product that is required to be maintained
  in the stock. Whenever the stoxks run below this limit the seller
  would be notified(Curently this feature has not been added but 
  soon email notification would be added). Whenever user purchases 
  a product from the seller, after successful payment they will be
  redirected to the fullfillment page. On the fullfillment page
  the user can track his shipment. The status of the order is
  updated by the merchant and on this basis the user is
  updated about his shipment on the fullfillment page. For now there
  are five paramters that have used for tracking.
@end itemize


@node Shipment Tracking
@section Shipment Tracking

Whenever user purchases a product from the seller, after successful
payment they are redirected to the fullfillment page. For digital
inventory the fullfillment page would be the direct display of the
digital inventory(like pdf). But for actual product shipment tracking 
makes sence. Therefore on the fullfillment page the user can track
his shipment. The status of the order is updated by the merchant
and on this basis the user is updated about his shipment of fullfillment
page. For now there are five paramters that have used for tracking, but
this is extensible and can be modified according to the requirement. The
initial status of order is marked as 'Pre Processing'.

@node Order Creation
@section Order Creation

The pay_url that is used while making contract is handled by the 
codeless payment backend. While handling this function the crsf
token is exempted and this function returns the json request. The 
order creation depends on the json format. If the json response status
is 200 only then an order will be created and also the quantity of the
same product is used to update the inventory on hand. For digital
inventory the inventory on hand remains zero. Untill and Unless a response
code of 200 is recieved, the inventory won't be updated. Similarly, all
the orders purchased are added in the Order table in the database. The
status for each order has to be updated buy the Merchant manually. The initial
status of order is marked as 'Pre Processing'.

@node Common Usage
@chapter Common Usage

The following image illustrates the various use case of codeless payment:

@c @center @image{doc/UseCaseDiagram, 1in, 1in}

There are three parties for which codeless payment backend serves
@itemize
@item Merchant
The Merchant has the ability to access the codeless payemnt backend
by logging in the platform. Codeless is a platform for the merchant
where they can manage their inventory and simultaneously create a
'Buy Now' button for the specific product. This code can be directly
copy pasted on the seller's frontend and can be used for 'Pay with Taler'.
@item Buyer
The Buyer will access the seller's frontend where the code
for 'Buy Now' button is copy pasted. The buysers clicks on the payemnt
button to pay with Taler. They enter their shipment details and redirected
to the payment page. After successfull payment the buyer can track his
shipment for physical products or view the digital version hosted by the
codeless payment frontend.
@item Admin
The Admin of the project has all the rights to access the admin page and
perform all the task that a Merchant can perform.
@end itemize

@node Limitation
@chapter Limitation

There are certain limitations that exists in thecodeless payment
baackend. The reset password works only when the backend is running
locally. Untill and unless, the backend is backend is deployed
on the server it won't work. Anothere limitation that exist is the
email notification when the stocks run below a certain limit. The
minimum number of products required to be maintained in the stocks
is currently taken from the seller but no email notification is send.

@node Future Work
@chapter Future Work

The backend of codeless payment is very roboust and can be easily
extended as per the requirements. It is adaptive to add new features
to this framework. But as per the dicussion 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 a s follows:

@itemize
@item
To send Email notification to the Merchant wwhen 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.
@item
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 used
by the seller, which is handled by the codeless payments service.
@item
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.
@item
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 has to be done before procedding to the implementation. 
@end itemize

@c **********************************************************
@c *******************  Appendices  *************************
@c **********************************************************

@node GNU-AGPL
@chapter GNU Affero GPL
@cindex license
@include doc/agpl.texi

@node Concept Index
@chapter Concept Index

@printindex cp

@bye