The better way to integrate Ethereum payments into web application

Question

I'm trying to find the best solution to integrate Ethereum-based payments into web application and I'm looking for advice from someone who already faced this task.

My case: Online-gambling solution where users can deposit money on their account and make bets.
Requirements: Payments should be Ethereum-based i.e. users transfer ETHs and get some game money (tokens) or see their balance directly in ETHs.

Solutions I'm seeing and their issues:

1) User transfers ETH to the address of app owner and gets tokens(we add tokens to user in app database). This looks to me as not good solution because it's not easy to identify what user made the money transfer. To do this we should store user's addresses in app database and analyze transactions of address of app owner.

2) Create something similar to Token contract. In this case user will be able to transfer ETHs to some address and get tokens (stored in the blockchain).
Issue: identify the user - is again an not so easy (the same issue as described above).
I know it's possible to use MetaMask, in this case user identification isn't necessary, but in this case game logic must be placed in smart-contract. Using MetaMask and fully decentralized app aren't acceptable, it will be too expensive. Firstly, because the games are very dynamical with a lot of state changes (game in progress, money in game, etc), a lot of gas will be required. Secondly, actions depends on state, so state changes must be available momentarily, it's not acceptable to wait while transaction will be mined.

3) Create new ethereum address for each registered user(save private keys in database). In this case some sync logic on app backend (ETH to internal currency[tokens in app database]) will be required.
For example, user transfers ETHs to created address then goes in app and clicks 'Sync' button, then app checks amount of ETHs on created for user address, transfers this ETHs to the address of app owner and adds tokens(internal currency) for this user in app database.

4) Create smart-contract for which users will be able to transfer ETHs with additional data(some unique identifier). In this case some complicated sync logic is required too.
Example: when user wants to get tokens(internal currency), app provides him contract address and generated unique identifier and saves this identifier in app database(one-to-many user/identifiers). User transfers ETHs to provided contract address and adds additional data(generated unique identifier), contract saves how much ETHs was transferred using this unique identifier, app backend uses this information to add tokens(internal currency) in app database[call of functions that doesn't change state are free].

As for me options 3 and 4 looks more acceptable, but I'm not sure my thoughts are correct, because I'm newest in blockchain development. Maybe there are better and more correct solutions.

a) Am I correctly understand described flows?
b) Are there any better or more correct solutions for my case?
c) What solution should I choose?

Answer 1

Before going any further... You must understand what a hot wallet is, and what a cold wallet is, and how to use them and keep them secure. It is incredibly easy to operate sites like these and lose everyone's money and go to jail for a long time. If you aren't confident in your knowledge of these crypto concepts, stop reading, do some more research, and come back here later.

So... to answer your actual question... There's actually a lot at play here...

1) The proposed value of allowing users to know your company is liquid. You might think users care about this, but cryptocurrency exchanges and other bitcoin betting sites usually go with your #1 proposed solution because in the end all users really want to do is trade/gamble. #1 reduces blockchain fees, so long as you operate your wallet efficiently, which brings me to my next point...

2) The proposed cost of operating your wallet efficiently. Really, you could run this wallet any old way and probably be fine, but the most efficient way to operate this wallet would be use algorithms which effectively take up the remaining coins in each input/output, minimizing dust. It might not be a bad idea to keep all your coin in a few addresses (one address would be cheapest, but multiple adds to security). The "cost" here is the research and/or development in finding existing Ethereum wallet software to correctly handle transaction inputs and outputs, minimizing fees and dust.

3) The proposed value in operating your wallet anonymously. Sending money back and forth between different ethereum addresses can help increase the anonymity regarding your site. Keep in mind this in direct contrast with #1. If law enforcement might be bothering you, you'd want to do some type of CoinJoin or similar ethereum service.

I would not recommend adding a smart contract to the equation. There are some very successful sites like these that do not use any special feature of Ethereum. If you wanted to use special Ethereum features, integrate your site with something like Augur or Gnosis.