TECHNICAL FIELD

[0001] The present disclosure relates generally to the field of enabling purchase and recovering receivables in a cashless manner and more specifically to a system that verifies the credit/overdraft limit of a purchaser and locks an amount, put hold on amount for the purchase based on analysis of the purchaser’s bank data and details.

BACKGROUND

[0002] The background description includes information that may be useful in understanding the present invention. It is not an admission that any of the information provided herein is prior art or relevant to the presently claimed invention, or that any publication specifically or implicitly referenced is prior art.

[0003] E-commerce is becoming increasingly popular in a variety of commercial trade operations. The term "e-commerce" refers to online purchasing for consumers using browser and server software in a commercial trade environment on the open Internet. A business operation model for online transactions and electronic payments between merchants and a variety of business, trading, financial, and associated integrated service activities.

[0004] Many banks and businesses now provide online payment services, allowing clients to make payments via terminals such as computers and mobile phones. Customers may appreciate the simplicity of online payment. Most monies are directly paid using existing funds or credit cards in the debit card, or credits in existing funds or credit cards are directly transferred to a third party institution as a guarantee for the transaction, once the merchant has not given the products, in the online payment process. The security of funds is difficult to guarantee when the service is poor or there is a customer dispute. New payment systems, methods, devices, and servers are clearly required that allow surety of transfer of funds while also ensuring adequate quality of service/goods provided.

[0005] There are various solutions available in the art that address such problems with payment and service delivery. One such application is provided by the PCT application WO2016173055A1 that discloses a cross-funds management server-based payment system, and a method, device and server, belonging to the field of e-commerce. The method comprises: a second funds management server receives payment request information sent by a client end; the sum of a credit overdraft limit, a credit loan limit and a funds balance of the client end is compared with a payment amount, and it is determined whether an electronic commitment payment certificate can be opened; if so determined, the second funds management server respectively freezes the credit overdraft limit, the credit loan limit and the funds balance within a client end account, the credit overdraft limit, the credit loan limit and the funds balance corresponding to the payment amount; the electronic commitment payment certificate for the second funds management server to commit to pay funds according to an agreed condition is generated, and the electronic commitment payment certificate is sent to a merchant end to perform a credit commitment payment on behalf of the client end, and synchronised to an information centre server. The method supervises both parties in a transaction, reduces financial risk, and ensures the interests of both parties in the transaction.

[0006] Another solution is provided by US7580884B2 that discloses Transaction data is uploaded from client machines running a software application such as an accounting or financial software application. Uploaded data describes transaction history with respect to subject companies. A central server aggregates the uploaded data to generate and distribute reports and/or alerts containing credit worthiness assessments of the subject companies.

[0007] However, the existing solutions fail to provide a reliable system to enable a cashless transaction between two entities/users that allows for realization of the payment at a later date while also allowing the user receiving a service to ensure quality of service before allowing disbursement of the amount. So, to resolve the above-mentioned problems,

[0008] There is a therefore a need in the art to address these limitations and other disadvantages faced in the bustling e-commerce rich marketplace of the day.

SUMMARY

[0009] The present disclosure relates generally to the field of enabling purchase and recovering receivables in a cashless manner and more specifically to a system that verifies the credit/overdraft limit of a purchaser, trade receivable balance of a purchaser in central directory and locks an amount/put hold on amount for the purchase based on analysis of the purchaser’s bank data and details.

[00010] The instant case concerns a technique and system for conducting safe online transactions. It is more specifically concerned with a system and method for providing indemnity for credit-based business transactions. A central or cloud-based central directory is included in the system/method, which collects data. The person/entity requesting/asking for a credit-based purchase's transaction/bank history (a) purchaser), gives the information to the person or entity wanting to make a credit-based purchase, (a seller) so that the seller can make informed decisions, such as whether to sell or not to sell, and to complete the transaction. When the seller requests it, he or she conducts commercial transactions and transacts the monetary worth.

[00011] The subject matter of the instant disclosure relates to a method and system for secure online transactions. More particularly, it relates to a system and method for providing indemnity to business transactions that require credit. The system/method incorporates a central or cloud based central directory, which collects transaction/bank history of the person/entity asking/requesting for a credit-based purchase (a purchaser), transfers the information to the person/entity making to perform a credit-based sell (a seller) so that said seller can make calculated decisions, i.e., to sell or not to sell, to do the business transactions, and transacts the monetary value whenever requested by the seller. Besides, the proposed system defers debiting/liquidating his/her/its bank accounts as soon as a purchase is made, and it also ensures guaranteed recovery of funds to the seller by putting hold on purchaser’s bank overdraft limit, by putting hold on purchaser’s trade receivable balance in central directory. This way, the purchaser can make a purchase even if he/she/it does not have the balance/credit in his/her/its bank account for the purchase. Accordingly, the proposed system helps both sellers & purchasers and infuses/boosts the confidence to perform credit-based transactions.

[00012] A system for enabling a cashless purchase and recovery of receivables is disclosed. The system comprises one or more mobile computing devices associated with one or more users and one or more first centralized servers, each of the centralized servers can be associated with an entity. Each of the users can be required to be registered with at least one of the entities that are also registered on the centralized server. The data input by the users and the entities are stored on the second server which can be configured with a memory and a processor. The each of the one or more users can be associated with the one or more entities by a unique id. The system can further comprise the second server in communication with the one or more mobile computing devices. When a user wants to make a purchase, he may trigger purchase request sent in the form of a first set of data packets that can be a received by the second server. The request for token transfer by the user mobile device wherein the request for token transfer can be made from a first requesting user to a second user where the second user can be the purchaser. The request can also be made where the first requesting user is the purchaser and a request for transfer of tokens is made. On receipt of request for token transfer, the second server authenticates the requesting users by a third authentication server wherein said third authentication server verifies an identity of the user by co-relating with the data stored on the second server. On successful authentication of the user, the third server transmits a second set of data packets to the second server, said second set of data packets pertain to a user token balance of the second user. On receipt the second set of data packets by the second server, the second server transmits a third set of data packets from the second server to the first centralized servers being associated with said entities wherein the third set of data packets consist a token lock information to lock/put hold on a pre-defined number of tokens mentioned in the request for token transfer against the user in favour of the registered entity which can be a bank or a financial institution. The second server then displays, to the second user on his mobile computing device, a notification to approve transfer of said locked token to the first requesting user. On approval by the second user, the second server transmits a third set of data packets by the user to release the locked tokens/to release hold from tokens to the requesting entity and thereby allowing transfer the tokens from the second user to the first requesting user.

[00013] In an aspect, the registered entity can be any or a combination of a financial institution, a bank, a lending service, banking company, a store, a depository such that each of the at least one user registered has an enrolment with at least one of the entities registered to enable a transfer of the tokens between one or more users enrolled with one of the entities.

[00014] In an aspect, the token can be any or a combination of credit balance in a bank account, an overdraft balance, funds, bonus points that are transferable from one user to another user, trade receivable balance of user in centralized directory.

[00015] In an aspect, the registration includes collection of data pertaining to a name, contact number, address, location, user id, bank details, user identity details and the like. These details can be stored on the second server. In an aspect where the user is registered with a bank, the data regarding credit limit, overdraft limit may be collected from the user at the time of registration and stored on the second server.

[00016] In an aspect, the authentication can include image capturing by a camera and voice capturing by a microphone to verify an identity of the users involved in the purchase and a display of the stored data of user from the server on the mobile device of the user carrying out the purchase.

[00017] In an aspect, the transmission of the first set of data packets pertaining to a request for token transfer received by the user mobile device are triggered on pressing a specific payment button available on e-commerce sites, scanning a user QR code on a seller’s outlet or on manual selection of token transfer. [00018] In an aspect, data input by the registered user being stored on the database of the second server includes a maximum threshold for transferring tokens, putting hold on tokens or locking tokens from the registered user’s account on the registered entity.

[00019] In an aspect, the processor configured with the server, during authentication can be configured to compare the received second set of data packets with data stored on said first server to evaluate a number of tokens available for transfer in the second user’s account with at least one of the registered entities to determine if the number of tokens available for transfer is lesser than the number of tokens in the request for tokens, allow the locking of tokens when the number of tokens in the request for tokens being less than the maximum threshold for transfer, cancel the request and send a notification on the one or more mobile computing device of the second user to indicate a failed transfer.

[00020] In an aspect, a method for enabling a cashless purchase and recovery of receivables, the method can comprise, registering, one or more users on a first centralized server, registering, one or more entities on a second server, requesting, by a second user at one or more mobile computing devices associated with said second user, a first set of data packets pertaining to a request for token transfer by a first requesting user, authenticating the first requesting user and the second user by a third authentication server wherein said third authentication server verifies an identity of the users by co-relating data stored on the first server and the second server, transmitting a second set of data packets to the second server, said second set of data packets pertaining to a user token balance of the second user and, transmitting a third set of data packets from the second server to the first centralized servers being associated with said entities wherein the third set of data packets consist a token lock information to lock/put hold on a pre-defined number of tokens mentioned in the request for token transfer against the second user in favour of the registered entity, displaying a notification to approve transfer of said locked token to the first requesting user at one or more mobile computing device of the second user. On approval by the second user, transmitting a third set of data packets by the one or more mobile computing device of the user, wherein the third set of data packets pertain to information to release the locked tokens to the first requesting user and thereby allowing transfer the tokens from the second user to the first requesting user.

BRIEF DESCRIPTION OF THE DRAWINGS

[00021] In the figures, similar components and/or features may have the same reference label. Further, various components of the same type may be distinguished by following the reference label with a second label that distinguishes among the similar components. If only the first reference label is used in the specification, the description is applicable to any one of the similar components having the same first reference label irrespective of the second reference label.

[00022] FIG. 1 indicates a network implementation 100 of a system, which facilitates a user to make a cashless purchase in accordance with an embodiment of the present disclosure.

[00023] FIG. 2 illustrates exemplary functional components of the proposed system in accordance with an embodiment of the present disclosure.

[00024] FIGs. 3A-B illustrates flowcharts indicating the steps involved in the cashless purchase and recovering receivables.

[00025] FIG. 4 illustrates a flowchart indicating the flow of transactions in an embodiment of the present disclosure.

[00026] FIG. 5 illustrates an exemplary computer system to implement the proposed system in accordance with embodiments of the present disclosure.

DETAILED DESCRIPTION

[00027] In the following description, numerous specific details are set forth in order to provide a thorough understanding of embodiments of the present invention. It may be apparent to one skilled in the art that embodiments of the present invention may be practiced without some of these specific details.

[00028] Embodiments of the present invention include various steps, which may be described below. The steps may be performed by hardware components or may be embodied in machine-executable instructions, which may be used to cause a general-purpose or specialpurpose processor programmed with the instructions to perform the steps. Alternatively, steps may be performed by a combination of hardware, software, firmware and/or by human operators.

[00029] Embodiments of the present invention may be provided as a computer program product or mobile application, which may include a machine-readable storage medium tangibly embodying thereon instructions, which may be used to program a computer (or other electronic devices) or mobile devices, to perform a process. The machine-readable medium may include, but is not limited to, fixed (hard) drives, magnetic tape, floppy diskettes, optical disks, compact disc read-only memories (CD-ROMs), and magneto-optical disks, semiconductor memories, such as ROMs, PROMs, random access memories (RAMs), programmable read-only memories (PROMs), erasable PROMs (EPROMs), electrically erasable PROMs (EEPROMs), flash memory, magnetic or optical cards, or other type of media/machine-readable medium suitable for storing electronic instructions (e.g., computer programming code, such as software or firmware).

[00030] Various methods described herein may be practiced by combining one or more machine-readable storage media containing the code according to the present invention with appropriate standard computer or mobile hardware, along with a computer application or Android or IOs application, to execute the code contained therein. An apparatus for practicing various embodiments of the present invention may involve one or more computers (or one or more processors within a single computer) and storage systems containing or having network access to computer program(s) coded in accordance with various methods described herein, and the method steps of the invention could be accomplished by modules, routines, subroutines, or subparts of a computer program product.

[00031] While embodiments of the present invention have been illustrated and described, it may be clear that the invention is not limited to these embodiments only. Numerous modifications, changes, variations, substitutions, and equivalents may be apparent to those skilled in the art, without departing from the scope of the invention, as described in the claim.

[00032] The subject matter of the instant disclosure relates to a method and system for secure online transactions. More particularly, it relates to a system and method for providing indemnity to business transactions that require credit. The system/method incorporates a central or cloud based central directory, which collects transaction/bank history of the person/entity asking/requesting for a credit-based purchase (a purchaser), transfers the information to the person/entity making to perform a credit-based sell (a seller) so that said seller can make calculated decisions, i.e., to sell or not to sell, to do the business transactions, and transacts the monetary value whenever requested by the seller. Besides, the proposed system defers debiting/liquidating his/her/its bank accounts as soon as a purchase is made, and it also ensures guaranteed recovery of funds to the seller by putting hold on purchaser’s bank overdraft limit and by putting on hold purchaser’s trade receivable balance on central directory. This way, the purchaser can make a purchase even if he/she/it does not have the balance/credit in his/her/its bank account for the purchase. Accordingly, the proposed system helps both sellers & purchasers and infuses/boosts the confidence to perform credit-based transactions. [00033] Further, a system for enabling a cashless purchase and recovery of receivables is disclosed. The system comprises one or more mobile computing devices associated with one or more users and one or more first centralized servers, each of the centralized servers can be associated with an entity. Each of the users can be required to be registered with at least one of the entities that are also registered on the centralized server. The data input by the users and the entities are stored on the second server which can be configured with a memory and a processor. The each of the one or more users can be associated with the one or more entities by a unique id. The system can further comprise the second server in communication with the one or more mobile computing devices. When a user wants to make a purchase, he may trigger purchase request sent in the form of a first set of data packets that can be a received by the second server. The request for token transfer by the user mobile device wherein the request for token transfer can be made from a first requesting user to a second user where the second user can be the purchaser. The request can also be made where the first requesting user is the purchaser and a request for transfer of tokens is made. On receipt of request for token transfer, the second server authenticates the requesting users by a third authentication server wherein said third authentication server verifies an identity of the user by co-relating with the data stored on the second server. On successful authentication of the user, the third server transmits a second set of data packets to the second server, said second set of data packets pertain to a user token balance of the second user. On receipt the second set of data packets by the second server, the second server transmits a third set of data packets from the second server to the first centralized servers being associated with said entities wherein the third set of data packets consist a token lock information to lock/put hold on a pre-defined number of tokens mentioned in the request for token transfer against the user in favour of the registered entity which can be a bank or a financial institution. The second server then displays, to the second user on his mobile computing device, a notification to approve transfer of said locked token to the first requesting user. On approval by the second user, the second server transmits a third set of data packets by the user to release the locked tokens to the requesting entity and thereby allowing transfer the tokens from the second user to the first requesting user.

[00034] In an embodiment, the registered entity can be any or a combination of a financial institution, a bank, a lending service, banking company, a store, a depository such that each of the at least one user registered has an enrolment with at least one of the entities registered to enable a transfer of the tokens between one or more users enrolled with one of the entities. [00035] In an embodiment, the token can be any or a combination of credit balance in a bank account, an overdraft balance, funds, bonus points that are transferable from one user to another user, trade receivable balance of user in central directory.

[00036] In an embodiment, the registration includes collection of data pertaining to a name, contact number, address, location, user id, bank details, user identity details and the like. These details can be stored on the second server. In an aspect where the user is registered with a bank, the data regarding credit limit, overdraft limit may be collected from the user at the time of registration and stored on the second server.

[00037] In an embodiment, the authentication can include image capturing by a camera and voice capturing by a microphone to verify an identity of the users involved in the purchase and a display of the stored data of user from the server on the mobile device of the user carrying out the purchase.

[00038] In an embodiment, the transmission of the first set of data packets pertaining to a request for token transfer received by the user mobile device are triggered on pressing a specific payment button available on e-commerce sites, scanning a user QR code on a retail outlet or on manual selection of token transfer.

[00039] In an embodiment, data input by the registered user being stored on the database of the second server includes a maximum threshold for transferring tokens or locking/putting hold on tokens from the registered user’s account on the registered entity.

[00040] In an embodiment, the processor configured with the server, during authentication can be configured to compare the received second set of data packets with data stored on said first server to evaluate a number of tokens available for transfer in the second user’s account with at least one of the registered entities to determine if the number of tokens available for transfer is lesser than the number of tokens in the request for tokens, allow the locking of tokens/putting hold on tokens when the number of tokens in the request for tokens being less than the maximum threshold for transfer, cancel the request and send a notification on the one or more mobile computing device of the second user to indicate a failed transfer.

[00041] FIG. 1 indicates a network implementation 100 of a system 102, which facilitates a user to perform cashless purchase without having to instantly transfer an amount during the purchase.

[00042] According to a network implementation, the proposed system 102 (referred to as system 102, hereinafter) can facilitate a user or to locate a store for availing a good or a service. Although the present subject matter is explained considering that system 102 is implemented as a mobile application on a server 110, it may be understood that system 102 may also be implemented in a variety of computing systems, such as a laptop computer, a desktop computer, a notebook, a workstation, a server, a network server, a cloud-based environment and the like. It would be appreciated that the system 102 may be accessed by multiple users 108-1, 108-2... 108-N (collectively referred to as users 108, and individually referred to as the user 108 hereinafter), through one or more first mobile computing devices 106-1, 106-2... 106-N (collectively referred to as user devices 106, or first devices 106 and individually referred to as user device 106, or first device 106 hereinafter), or applications residing on the user devices 106. Further, the system can be accessed by multiple entities Users 108 can be patients with various health-related concerns or issues, and users 108 can also avail the system for other patients associated with them.

[00043] In an embodiment, system 102 can register the users 108 and the entities (not shown in the figure) as registered users 108 and registered entities, upon a positive verification of their registered mobile devices 106, and 112, respectively. The system 102 can request and receive, upon a first communicative coupling (or first-time registration) of the user mobile devices 106 with the servers 110, 112 and 114, first details of the corresponding user 108 from the mobile devices 106 of users 108, and correspondingly registers the users 108 as the registered user upon a positive verification of the corresponding first details. Further, system 102 can request and receive, upon a first communicative coupling of the entity mobile devices with the server 110, second details of the corresponding entity from the mobile devices, and correspondingly registers the entities as the registered entity upon a positive verification of the corresponding second details. The mobile devices are communicatively coupled with a centralized server that hosts a processor and a database. Additionally, an entity server 114 to store entity information and transaction information may be provided. Further, an authentication server 112 to compare the data from the entity in real time and verify the details stored on the entity server may be provided.

[00044] In an exemplary embodiment, the first details of user 108 can comprise name, photo, age, gender, mobile number, location, biometrics details, transaction history of the registered users, medical history of the registered users 108. Further, the second details of the entities can comprise company name, age, gender, mobile number, location, photo, financial details, and records of the user registered with the entity.

[00045] System 102 can be operatively coupled to a website and so be operable from any Internet-enabled user device 106 and/or entity device. Examples of user devices 106, and entity devices may include, but are not limited to, a portable computer, a personal digital assistant, a handheld device, and a workstation. The user devices 106, and entity devices can be communicatively coupled with system 102 through a network 104.

[00046] In one implementation, network 104 can be a wireless network, a wired network or a combination thereof. Network 104 can be implemented as one of the different types of networks, such as an intranet, local area network (LAN), wide area network (WAN), the internet, and the like. Further, network 104 may either be a dedicated network or a shared network. The shared network represents an association of the different types of networks that use a variety of protocols, for example, Hypertext Transfer Protocol (HTTP), Transmission Control Protocol/Internet Protocol (TCP/IP), Wireless Application Protocol (WAP), and the like, to communicate with one another. Further, network 104 can include a variety of network devices, including routers, bridges, servers, computing devices, storage devices, and the like. In another implementation the network 104 can be a cellular network or mobile communication network based on various technologies, including but not limited to, Global System for Mobile (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA), Long Term Evolution (LTE), WiMAX, and the like.

[00047] In an embodiment, system 102 can facilitate providing an easy, fast, pictorial and objective mechanism to the users 108 for selecting their problem that is closest to their complaints. System 102 facilitates providing an easy and efficient mechanism to communicate an exact token amount to entity while simultaneously providing detailed multi- step coverage of entity services, (e.g., health services, goods for sale etc.).

[00048] In an embodiment, the users may be individuals, shop keepers, wholesalers, distributors, manufacturers, consultants and retailers and the entities may be banks, financial institutions and organizations of the like where the registered users have enrolled accounts.

[00049] In an implementation, user 108 can access system 102 through an application residing on the user device 106 or through a website. User 108 can register with system 102 using user information such as name, age, gender, mobile number, address, and medical status.

[00050] In an embodiment, system 102 may facilitate entity to receive the request for purchase as received from user 108. System 102 may enable the user’s request to be transferred via the network to the multiple entities 110. Entity 110 may be using an associated device 112 via the application or website, receive a request from user 108. The request may provide a detailed overview of request of the user 108 and that includes such basic information, transaction details, request, photographs, video, duration and additional information, and so forth. [00051] In an embodiment, when an entity subscribes to the application he may provide a reply to the related user 108. The reply may be related to such as the hold free balance tokens, hold free balance coupons, hold free cash balance in the user’s account, hold free credit balance in the user’s account, hold free trade receivable balance in the user’s account and so forth. Entity may also get a chance to communicate about his specialty goods and services to the user 108.

[00052] In another implementation, the users, 108 (patient) may receive rewards/digital cash/reward points from the entities or by redeeming coupons or codes from various connected websites.

[00053] FIG. 2 illustrates exemplary functional components of the proposed system 102 in accordance with an embodiment of the present disclosure.

[00054] In an aspect, system 102 may comprise one or more processor(s) 202. The one or more processor(s) 202 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, logic circuitries, and/or any devices that manipulate data based on operational instructions. Among other capabilities, one or more processor(s) 202 are configured to fetch and execute computer-readable instructions stored in a memory 204 of the system 102. The memory 204 may store one or more computer-readable instructions or routines, which may be fetched and executed to create or share the data units over a network service. The memory 204 may comprise any non-transitory storage device including, for example, volatile memory such as RAM, or non-volatile memory such as EPROM, flash memory, and the like.

[00055] System 102 may also comprise an interface(s) 206. The interface(s) 206 may comprise a variety of interfaces, for example, interfaces for data input and output devices, referred to as I/O devices, storage devices, and the like. The interface(s) 206 may facilitate communication of system 102. The interface(s) 206 may also provide a communication pathway for one or more components of the system 102. Examples of such components include, but are not limited to, processing unit(s) 208 and database 210.

[00056] The processing unit(s) 208 may be implemented as a combination of hardware and programming (for example, programmable instructions) to implement one or more functionalities of the processing unit(s) 208. In examples described herein, such combinations of hardware and programming may be implemented in several different ways. For example, the programming for the processing unit(s) 208 may be processor-executable instructions stored on a non-transitory machine -readable storage medium and the hardware for the processing unit(s) 208 may comprise a processing resource (for example, one or more processors), to execute such instructions. In the present examples, the machine-readable storage medium may store instructions that, when executed by the processing resource, implement the processing unit(s) 208. In such examples, system 102 may comprise the machine-readable storage medium storing the instructions and the processing resource to execute the instructions, or the machine-readable storage medium may be separate but accessible to system 102 and the processing resource. In other examples, the processing unit(s) 208 may be implemented by electronic circuitry.

[00057] The data 210 may comprise data that is either stored or generated as a result of functionalities implemented by any of the components of the processing unit(s) 208 or system 102.

[00058] In an exemplary embodiment, the processing unit(s) 208 may include an information requisition unit 214, authentication unit 212, a notification unit 216, and other unit(s) 218. Other unit(s) 218 can supplement the functionalities of the processing unit 208 or the system 102.

[00059] In an embodiment, the information requisition unit 214 enables the users to provide their respective information to the system. System 102 may receive information from the user after completion of a sign-in process and registration of his mobile number and verification with a provided one-time password (OTP). Password may then be set by the user for accessing the application installed on the user-associated device. User 108 may then provide his basic information to system 102. User 108 may select from a number of services and goods being offered by other users.

[00060] Further, the additional options for other problems may be provided in a hierarchical form for the user to choose from, and are provided in regards to the option as selected by the user. Also, as can be appreciated by those skilled in the art, the options being provided are in an objective form and help the users to clearly convey their problems to the entity.

[00061] In an embodiment, the information requisition unit 214 sends out a “buy now pay later mi” request that is received by the provider of the goods on his mobile computing device. The users 108 may register themselves with the application or website, and then receive and send requests to other users 108 for goods and services. Based on the received requests, the processor verifies the buyer and seller involved in the transaction by the authentication unit which authenticates the registration data relating to combination of the permitted cash withdrawal limit, credit limit and over draft limit of each user that stored on the databases by extracting the real-time data from the entity (a bank) and trade receivable balance of each user that is stored on the central directory and comparing those to determine the real-time status of the buyer user’s status. 108 based on such as a tentative problem statement, required tentative treatment options, tentative treatment cost, and additional investigations or additional information, and so forth. Further, based on the retrieved user information, the notification unit provides notifications on the display of the mobile communication device that indicate the rejection, inability to proceed, successful completion or the current status of the purchase transaction.

[00062] FIG. 3 is a flowchart of an exemplary embodiment of the present invention in accordance with the present disclosure. FIGs. 3A-B illustrates flowcharts indicating the steps involved in the cashless purchase and recovering receivables.

[00063] As illustrated, in an embodiment, a user may send a request to buy something either on e-commerce site, sellers own selling site, e-commerce mobile application, sellers own mobile application etc, using users any computable device having camera, microphone, processer and the like hardware, to the processor connected to the server. The processor configured with the server may verify the source of the buying request to identify a source as a third party site, applications (i.e. e-commerce web site, web application, mobile application etc). If third party source is detected, then the processor connected to the server may be configured to retrieve get the seller details like seller unique id, name, email id, mobile number and buying amount from that e-commerce web site, web application, mobile application.

[00064] And if the buying request is detected as not coming from a third party site (i.e. e-commerce web site, web application, mobile application etc), that in case of P2P transactions applications then the processor can send a prompt to the user to scan the QR code of the seller. The processor may search the seller’s unique id, retrieved from QR code, in the server database.

[00065] In an embodiment, if the scanning and retrieving the data from the QR code failed the processor send prompt to scan again up to three times. After three failures, the processor may prompt the user to do the authentication of seller using device mobile camera and microphone and check if that seller user exist in data base (i.e. in third party server data base like Microsoft Azure). If seller user found, then get the unique id associated to that seller in database i.e. in azure database. If seller user not found, then get seller details and save that seller authentication details in database i.e. in azure database and get the unique id associated to that seller. Then server processer may search that retrieved unique id (i.e. id assigned to seller details in azure database) of seller in the server database. If seller found in server database then move to the step of authentication else open seller user registration form having content like Seller unique id on azure database, seller name, mobile number, email id, location and save data in server data base.

[00066] In case of P2P transactions if the QR code scan is successful, then the processer may display the seller’s photo image, shop name assigned to the QR code and prompt user to input the buying amount. If needed, the Buyer user may verify to see if the actual person and shop name as displayed are same. If a mismatch is found on visual inspection by the buyer, then buyer may cancel the transaction and bring the same to the notice of the seller.

[00067] If the seller photo and shop name do not match with the actual seller, the buyer user is given a notification to choose between validating the seller as correct or incorrect. In an embodiment, on the buyer choosing “INCORRECT”, the processer may return to adding the details of the seller into the database.

[00068] If the buyer user chooses “CORRECT” - then the processer may send out a prompt to the user to do the authentication of the buyer user using device mobile camera and microphone and check if that buyer user exists in the data base(i.e. in third party server data base like Microsoft Azure). If the buyer details are found in the database, then get the unique id associated to that buyer user in third party database i.e. in azure database.

[00069] If the buyer user is not found registered in third party database i.e. in azure database, the server exits the process while displaying a warning message to the user. In an embodiment, the warning message may read “You are not authorized to use this service, please do your registration first”.

[00070] In an embodiment, the processor connected to the server may check whether buyer and seller’s bank accounts are located in the same country. If the buyer and seller are located in the same country, the processor retrieves the unique ids corresponding to each user and entity involved and identifies the unique id with the third party data base to that buyer user. Then search that unique id in the second server database and get the unique id associated to that buyer user in the second server database. The processor then retrieves the existing account balance excluding trade receivable balance, existing total trade receivable balance, bank account number of the buyer user from the server database and gives an API call to the centralized server and get existing (hold free) cash/credit balance, overdraft/loan limit sanctioned, unused (hold free) overdraft limit/loan balance on buyer users bank account, that is linked to the buyer users account on the second server database directory. [00071] The Server processer may compare both the amounts and as per the stored threshold, if there are any mismatches, then Mark that buyer user account for audit purpose. This may be for fraud prevention measure precaution taken, because all the users buying using this platform are must have to pay sellers through this platform only. Because on this platform seller user can initiate pay me request any time for the trade receivables or an automatic payment links may be generated after a specific interval of time. So to avoid duplicate payments outside this system direct payment outside this platform is prohibited.

[00072] The server may check, by comparison, whether existing (hold free) cash/credit balance on buyer user account, obtained from server is zero. On receipt of the existing (hold free) cash/credit balance on buyer user account as zero, the server may check whether existing (hold free) unused overdraft limit/loan balance on buyer user account, obtained from server is zero. On receiving the unused overdraft limit/loan balance as zero, the server may check whether existing trade receivables balance on buyer user account, obtained from server is zero. On receiving existing trade receivables balance on buyer user account as zero, server sends a notification on the display device of the user indicating ineligibility to engage in transaction. In an exemplary embodiment, the notification displayed on display of the mobile computing device of the buyer user may be “user not eligible to complete transaction under ‘buy now pays later mi’” and then the processor exits the process.

[00073] The processer may check whether existing (hold free) cash/credit balance on buyer user’s bank account, linked to the buyer account on the system, is equal to or greater than the “specific amount” i.e. the buying amount.

[00074] If the existing cash/credit amount is greater than the request amount, the server processer may call API request to the server to put hold (lock) on the existing (hold free) cash/credit balance equal to the “specific amount” i.e. buying amount, of the buyer user’s bank account linked to the buyer users account on the system.

[00075] If the cash/credit balance is found to be lesser than the “specific amount” i.e. buying amount, then the server processer may check the existing (hold free) unused overdraft limit/loan balance and existing (hold free) cash/credit balance from server. Processer may check the existing trade receivables balance of buyer user from server. Then make sum of all obtained figures and check whether resulting figure/total is greater than the “specific amount” i.e. buying amount. If the sum of all the available balances is still lesser than the buying amount, the transaction is rejected and the processer may notify the buyer user “user not eligible to complete transaction under buy now pays later mi” and then exit process. [00076] If the sum of all the available balances is greater than the buying amount, the processer may call API request to the server to put hold on the existing (hold free) cash/credit balance and or on the existing (hold free) unused overdraft limit/loan balance of the buyer user bank account linked to the buyer users account on the system, put hold on existing trade receivables balance of buyer user on server equal to the “specific amount” i.e. buying amount fully and or partially. After putting hold equal to buying amount, the processor gives confirmation to the buyer that “you can complete the buying transaction without using any payment method” and updates on the server database according to the transaction taken place.

[00077] Fig 3B. Illustrates an exemplary embodiment of the claimed invention illustrating a request sent by a User seller being a request for release of payments for the trade receivables to the server processer. On receipt of request from seller user server may check whether the request is come from third party site, applications (i.e. e-commerce web site, web application, mobile application etc.).

[00078] If the request is received from a third party site, then the processor connected to the server may get the seller details like seller unique id, name, email id, mobile number from on that e-commerce web site, web application, mobile application.

[00079] The server displays an interface on the mobile device of the seller to input the figure that the seller wants to recover from the trade receivables. Then server processer may prompt user seller to do the authentication using device mobile camera and microphone and server processer may check if that seller user exist in data base (i.e. in third party server data base like Microsoft Azure). If Seller user is found, then get the unique id (i.e. third party database unique id of that seller user) associated to that Seller user in third party database i.e. in Microsoft’s azure database.

[00080] If the seller user is not found in third party database then i.e. in azure database the processor exits the process and displays a warning message to the user. In an embodiment the warning message may be “You are not authorized to use this service”.

[00081] On successful verification and authorization of the seller user’s unique id associated with the server, the processer prepares a chronological list of all trade receivables (i.e. the list of buyers who was bought from that seller under “buy now pays later mi” and buyer and sellers bank account are in same country.) of seller user. The processor makes a separate second list from the retrieved data of the first list, using specified age criteria, of the trade receivables. Based on the second list, the processor dynamically prepares the final list of which total value should be equal to the requested amount. Processor may identify the total number of buyers i.e. trade receivables and if the total amount of trade receivable retrieved is calculates to be equal to zero or less than zero then the processor exits the system. If the total amount of trade receivable retrieved is greater than zero, the server processer may create a separate secret key for each buyer i.e. trade receivable account. The server may make an API call to the server and share the secret key.

[00082] In an embodiment, a method for enabling a cashless purchase and recovery of receivables, the method can comprise, registering, one or more users on a first centralized server, registering, one or more entities on a second server, requesting, by a second user at one or more mobile computing devices associated with said second user, a first set of data packets pertaining to a request for token transfer by a first requesting user, authenticating the first requesting user and the second user by a third authentication server wherein said third authentication server verifies an identity of the users by co-relating data stored on the first server and the second server, transmitting a second set of data packets to the second server, said second set of data packets pertaining to a user token balance of the second user and, transmitting a third set of data packets from the second server to the first centralized servers being associated with said entities wherein the third set of data packets consist a token lock information to lock/put hold on a pre-defined number of tokens mentioned in the request for token transfer against the second user in favour of the registered entity, displaying a notification to approve transfer of said locked token to the first requesting user at one or more mobile computing device of the second user. On approval by the second user, transmitting a third set of data packets by the one or more mobile computing device of the user, wherein the third set of data packets pertain to information to release the locked tokens to the first requesting user and thereby allowing transfer the tokens from the second user to the first requesting user.

[00083] The processer may make request to generate and share a payment link for each buyer i.e. trade receivable account using the secret key. If the requested payment links not received from server within a stipulated time, then the server processer may send a reminder API call to the server and request to send the payment links. Payment links may contain details like debit account, credit account, trade receivable amount, charges amount and the like.

[00084] On receipt of all the payment links from server for all the requested buyers i.e. trade receivable accounts server may forward the payments links using whatsapp, sms email to the buyers i.e. the trade receivable accounts. The system may keep record of each transaction with the date and time stamp to take the follow-up till the link get paid. After forwarding the payment links to the buyer i.e. trade receivable accounts, the processer may make an automated call to the buyer user to remind them to pay links in time. If the automated call fails, then the server may be configured to repeat the process. After a specific time, the server processer may give an API call to the server and check the payment status of the generated links. On identification of the payment status as not paid, the processer may delete the old links data and generate new payment links with the new details. If the response received is paid then the server processer may make data entry in server database and send confirmation to each user through sms.

[00085] In an embodiment, the server may make a chronological list of all trade receivables (i.e. the list of buyers who bought from each seller under “buy now pays later mi”) of all seller user. The Processor may dynamically identify the total number of buyers i.e. trade receivables.

[00086] FIG. 4 illustrates a flowchart indicating the flow of transactions in an embodiment of the present disclosure.

[00087] In an embodiment, a method 400 for enabling a cashless purchase and recovery of receivables, the method can comprise, registering 402, one or more users on a first centralized server, registering 404, one or more entities on a second server, requesting 406, by a second user at one or more mobile computing devices associated with said second user, a first set of data packets pertaining to a request for token transfer by a first requesting user, authenticating 408 the first requesting user and the second user by a third authentication server wherein said third authentication server verifies an identity of the users by co-relating data stored on the first server and the second server, transmitting 410 a second set of data packets to the second server, said second set of data packets pertaining to a user token balance of the second user and, transmitting a third set of data packets from the second server to the first centralized servers being associated with said entities wherein the third set of data packets consist a token lock information to lock/put hold on a pre-defined number of tokens mentioned in the request for token transfer against the second user in favour of the registered entity, displaying 412 a notification to approve transfer of said locked token to the first requesting user at one or more mobile computing device of the second user. On approval by the second user, transmitting 414 a third set of data packets by the one or more mobile computing device of the user, wherein the third set of data packets pertain to information to release the locked tokens/tokens on hold to the first requesting user and thereby allowing transfer the tokens from the second user to the first requesting user. [00088] FIG. 5 illustrates an exemplary computer system to implement the proposed system in accordance with embodiments of the present disclosure. A bus 520 may establish a connection between a processor 570 coupled with a memory 530.

[00089] Those skilled in the art would appreciate that, though embodiments of the present disclosure are explained in terms of users and entities, the same may refer to a user, a store and a bank respectively.

[00090] While the foregoing describes various embodiments of the invention, other and further embodiments of the invention may be devised without departing from the basic scope thereof. The scope of the invention is determined by the claims that follow. The invention is not limited to the described embodiments, versions or examples, which are included to enable a person having ordinary skill in the art to make and use the invention when combined with information and knowledge available to the person having ordinary skill in the art.