diff options
author | shivam kohli <kohlishivam5522@gmail.com> | 2018-08-09 10:32:02 +0530 |
---|---|---|
committer | shivam kohli <kohlishivam5522@gmail.com> | 2018-08-09 10:32:02 +0530 |
commit | 6f1b508db9940fb09357b8901f1f2c9b0cc6ffcd (patch) | |
tree | 27722484076e4cbba7644fec7e165fca34a5896b | |
parent | 53fbbf0cc0c13c4eb5913e76f76366e61b77e5da (diff) | |
download | codeless-6f1b508db9940fb09357b8901f1f2c9b0cc6ffcd.tar.gz codeless-6f1b508db9940fb09357b8901f1f2c9b0cc6ffcd.tar.bz2 codeless-6f1b508db9940fb09357b8901f1f2c9b0cc6ffcd.zip |
typos in doc
-rw-r--r-- | doc/codeless.texi | 111 |
1 files changed, 55 insertions, 56 deletions
diff --git a/doc/codeless.texi b/doc/codeless.texi index 0a8b80c..ee9f3ec 100644 --- a/doc/codeless.texi +++ b/doc/codeless.texi @@ -86,12 +86,12 @@ regulation (such as GDPR). 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 +merchant backend. This component should have 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 +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 @@ -105,21 +105,21 @@ The following three components has been included. @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. + adds his shipment details. Moreover, the frontend is a complete portal + where the merchant has the ability to create and manage his account. + He has the flexibility to manage his inventory. @cindex Backend -@item The backend of codeless payment is very roboust and can be easily +@item The backend of codeless payment is very robust 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 + payments, managing signup and singing 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 + keeps a track of the inventory. For now, the reference implementation 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: @@ -185,25 +185,25 @@ The following image illustrates the database schema used for inventory tracking: The Merchant can add two types of inventory @itemize @item Digital Inventory - The seller can upload Digital Inventory (like a PDF or html page) + 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. + 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 + In this kind of product, the seller has the flexibility to add any + product. While adding these inventory, the seller is prompted 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 + 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). Whenever user purchases a product from the seller, after successful payment they will be - redirected to the fullfillment page. On the fullfillment page + redirected to the fulfilment 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. + updated by the merchant and on this basis, the user is + updated about his shipment on the fulfilment page. For now, there + are five parameters that have used for tracking. @end itemize @@ -211,40 +211,40 @@ The Merchant can add two types of inventory @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 +payment they are redirected to the fulfilment page. For digital +inventory, the fulfilment page would be the direct display of the +digital inventory(like pdf). But for actual product shipment tracking +makes sense. Therefore on the fulfilment 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 +and on this basis, the user is updated about his shipment of fulfilment +page. For now, there are five parameters 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 +The pay_url that is used while making the 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 +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 +inventory, the inventory on hand remains zero. Until and Unless a response +code of 200 is received, 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'. +status for each order has to be updated by the Merchant manually. The initial +status of the order is marked as 'Pre Processing'. @node Testing @chapter Testing The codeless backend can be well tested by the use of various test cases -that has been implemented for the current scenario. Two test cases have -been implemented to check the functionality. For the implemtation part a +that have been implemented for the current scenario. Two test cases have +been implemented to check the functionality. For the implementation part, a selenium script has been written which uses geckodriver to run the script. -Selenium automates browsers. It create robust tests. +Selenium automates browsers. It creates robust tests. A process to check the registration part as well the login part has been written. To run the test follow: @@ -263,16 +263,16 @@ The following image illustrates the various use case of codeless payment: There are three parties for which codeless payment backend serves @itemize @item Merchant -The Merchant has the ability to access the codeless payemnt backend +The Merchant has the ability to access the codeless payment 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 +for 'Buy Now' button is copy pasted. The buyers click on the payment button to pay with Taler. They enter their shipment details and redirected -to the payment page. After successfull payment the buyer can track his +to the payment page. After successful payment, the buyer can track his shipment for physical products or view the digital version hosted by the codeless payment frontend. @item Admin @@ -283,38 +283,37 @@ perform all the task that a Merchant can perform. @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 +There are certain limitations that exist in the codeless payment +backend. The reset password works only when the backend is running +locally. Until and unless the backend is backend is deployed +on the server it won't work. Another limitation that exists 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. - +is currently taken from the seller but no email notification is sent. @node Future Work @chapter Future Work -The backend of codeless payment is very roboust and can be easily +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 dicussion and the scope of this -project there are various features that will be soon added in the +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 a s follows: @itemize @item -To send Email notification to the Merchant wwhen the stocks run below a +To send an 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. @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 +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 +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. @item Mapping every seller account to a separate merchant backend instance. @@ -327,8 +326,8 @@ 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. +of products based on delivery location, etc. For this part, discussions and +some more research has to be done before proceeding to the implementation. @end itemize @c ********************************************************** |