Technical idea of how to organize cryptocurrency payment on the site

One day I was interested in the question of how payer identification technically happens, because crypto is inherently encrypted and confidential. And, for example, let's take this hangout. If we turn on receipt of payments by crypto, as well as online stores fiat, then how to understand from which login the payment occurred?
In principle I didn't make a long guess and came to the following: the amount of payment. The final algorithm is as follows:
1.    Offer the payer a few coins to choose from. For example, he chose Bitcoin (BTC).
2.    2. Let's assume that the amount of payment is $100. According to the rate at the moment of this writing, it's 0.00603 BTC.
3.    The payer clicks to pay, gets the amount payable in bitcoins and a purse number. At the same time "payment request" is placed in the base, which contains the payer's login, payment cryptocurrency and amount in crypto. 
4.    Every minute, or by pressing the "I paid" button, the blockchain checks if there is a transaction for that amount.
5.    If there is - we activate it, if not - we check it further by timer.
I.e. once again, the identification of the payment occurs on a coin-amount pair. And technically it is much easier to implement than to raise from scratch processing on fiat.

Here the following problems will arise:
1.    Several people at a time will make the payment for the same amount during one minute.
2.    2. You need a refund function.
The person may not send the whole amount. Or in parts.
4.    The person will send the payment to the wrong blockchain.
And their solution:
1.    Split the payment into two transactions, dividing its proportions in the way it wasn't divided before (just look in the base to see if there are such parts). From the example above, we split the amount 0.00603 into two: 0.00299 and 0.00304. The other person is 0.00198 and 0.00405. Then this problem is eliminated.
2.    To do refunds by hand. In myAlpari the payer sends the refund request and the operator gives the refund note with the hash of the transaction. Or by API, depending on where the funds are stored.
3.    Depending on the financial policy of the company accepting the payment. Either a refund by timeout, or recalculation of the service (if it is a service and accepts payment for the duration of the subscription), or continuing to wait for the full amount to arrive.
4.    My own fault.
And not a little important point, it is to fix the rate before payment in case of return request. Imagine the situation that occurred payment, the next day the coin gave X and the man under a farfetched pretext requires a return of the same coin. Just speculation, to pull back payment, sell it, make half profit and pay for access again in USDT. In that case, either stipulate that there is no refund at all, or specify in the offer that the refund is refunded in USDT at the exchange rate at the time of the transaction. I.e., if the coin was $100, you return $100 and not $150-200 at the new exchange rate.