Build a Website Custom Peer-to-Peer Sports Betting site API & Front End

The overall functionality of the site can be broken down into the following at a very high level, and modelled against the [login to view URL] application. Please note we DO NOT want a blatant copy of Tailorbet, it is simply mentioned as guide to the workings of peer-to-peer betting and the similar front-end functionalities. 1) Users must be able to register and login to the site before they can add/withdraw funds. 2) Users can add funds to an account preferably via Mobile money,Mpesa,Airtel Money commonly used in east Africa and Africa at Large and debit/credit card or bank transfer using an established payment processor API. 3) Users must be able to search and view a list of football matches (events) from the top tier European football leagues. All of these fixtures will be provided by an XML data-feed which needs to be automatically retrieved/downloaded from an external server. 4) Users must be able to select the type of bet they want to make on that match, set the odds they want to provide in decimal format, and how much money they would like to stake. The TYPES of bet are detailed below. 5) When a user places a bet it (the bet) must be given an ‘open’ status and displayed on the site as an open bet, waiting for another user to oppose (lay) the bet. The bet must display the odds available and the required stake, as a mathematical result of the bet created by the original user. Formula will be provided. 6) When a user places a bet he is charged a flat rate fee that is deducted from his funded account. If his bet is opposed (taken) by another user before the relevant match (event) is finished then this flat rate fee is refunded automatically to the creator. If not, this fee remains with the business. 7) All ‘open’ bets must be searchable and displayed on the front end by clicking on a match (event) that the bet refers to. 8) All ‘open’ bets must have the option to ‘oppose’ available to all other users who have sufficient funds in their accounts. Any users who have less funds then the calculated required stake to oppose a bet therefore cannot oppose the bet. 9) A user who opposes (lays) an ‘open’ bet causes the bet to become ‘closed’, and has the required stake funds deducted from the account. The bet can therefore no longer be cancelled or altered by either party. 10) All users must have money funded to their accounts in order to open (make) or oppose (lay) bets. A user cannot stake more money than they have in their accounts. 11) The result of a bet is derived from an XML feed which delivers results of each match (event) as a set of ‘incidents’, i.e goals/cards/scorers etc… 12) All bet outcomes must be automatically resolved against the xml results feeds as soon as the match (event) concludes. 13) When the result of the bet is known, the winner is allocated the total money that was staked by both users, minus a percentage, which is held by us (the business) as a commission. The bet is then ‘settled’. 14) The commission percentage is a calculated variable depending on the value of the winnings. 15) The winner of any settled bet must have the funds allocated to his account immediately. 16) In order for users to pick specific players for specific bet criteria, a database of teams and their squad players must be made available to users through the front end. This information will be provided for all teams which the xml feeds cover. 17) There must be an online admin interface through which admin can manage any aspect of any bets, database and user accounts. 18) We want the front-end to be decoupled from the back end and served by a custom Rest API, therefore the creation/alteration/retrieval of bets, the retrieval of matches (events), and the user account management, must be achieved through designated API calls (i.e GET POST PUT DELETE etc). This is because we may want several different front-end clients accessing the same API. 19) We want the front-end to be mostly a JavaScript application.