The real difficulties in providing crypto payment options is that users are generally not educated enough to use it properly.
I built Bitcoin and Stellar payment systems for a client. In both cases, I generated an address for each customer and associated that address with the customer ID. By not reusing addresses, I never had the problem of not knowing who had paid and who had not. You cannot trust most people to provide a memo correctly.
Of course, I generated a QR code for each payment request, so mobile users had no trouble. However, desktop users had to copy paste, and some people have trouble with even basic computer tasks...
The biggest challenge was having people under-pay. Depending on the wallet a person used, the wallet might show them a fiat currency amount instead of a crypto amount. If I said to pay 100 XLM, they might put that into their wallet and see an incorrect (or inaccurate) conversion and adjust the number down (or up, but that rarely happened).
I gave a locked in quote price when the order was placed, and I would let that price stay fixed until the order was paid. That was better than updating the to-pay amount after the order was placed, since the user might have been busy going off to buy or transfer the exact amount. We noted that if the conversion rate fluctuated greatly, the user could simply cancel the order and re-place it to get the current rate.
Another problem was that people would pay directly from an exchange "wallet", and the exchange might take a fee out for the transfer. So that 100 we requested might arrive as 90. I did allow up to 3% under-pay, but in cases where the difference was greater I had to leave the order open as partially paid (and request the buyer pay the missing difference). Then we found that if that difference was small, some people couldn't transfer that small amount from their exchanges (there were often minimum transfer limits).
Then on the company side, we've got crypto that we had to decide whether to sit on or convert to fiat. Obviously if the crypto market is on a bull run, it's beneficial to keep the money in crypto. But it's really a gamble (obviously a losing gamble in the last 10 months). So normally we would convert the crypto back to fiat every couple of days.
The technical aspects of all this were not really difficult, and it was nice being in charge of refund decisions (unlike when taking credit cards or paypal where a bad actor can cause immediate and long term problems for the merchant).
1) Bitcoin needs time to transfer. How did you approve the transaction? Instantly in hoping it will go through or had the costumer to wait?
2) The problem with new Stellar addresses is, that they need to be "funded". Your sending wallet has to recognize if this address is empty to run the right function (it's not a normal transaction). Most of the wallets can't do that. They wouldn't be able to transfer any funds. Have you had problems with that?
1 - I ran a bitcoin node, and I had a script which would poll the node every few seconds to get the status of the addresses which I knew had open orders. Any that had received a payment would get marked accordingly so I could show on the order status page. But I didn't mark the order as paid until there were 2 confs.
2 - I pre-funded each Stellar address before providing it to the buyer. Periodically later if orders never got completed I would sweep the old addresses. But it wasn't much as Stellar was only about $0.2 USD at the time.
Regarding this, to clear up a common misconception, regular debit/checking takes at least one day to clear (US ACH), usually 2-3 business days, while Bitcoin transactions are validated within 1-2 hours, regardless of standard regional business hours.
I built Bitcoin and Stellar payment systems for a client. In both cases, I generated an address for each customer and associated that address with the customer ID. By not reusing addresses, I never had the problem of not knowing who had paid and who had not. You cannot trust most people to provide a memo correctly.
Of course, I generated a QR code for each payment request, so mobile users had no trouble. However, desktop users had to copy paste, and some people have trouble with even basic computer tasks...
The biggest challenge was having people under-pay. Depending on the wallet a person used, the wallet might show them a fiat currency amount instead of a crypto amount. If I said to pay 100 XLM, they might put that into their wallet and see an incorrect (or inaccurate) conversion and adjust the number down (or up, but that rarely happened).
I gave a locked in quote price when the order was placed, and I would let that price stay fixed until the order was paid. That was better than updating the to-pay amount after the order was placed, since the user might have been busy going off to buy or transfer the exact amount. We noted that if the conversion rate fluctuated greatly, the user could simply cancel the order and re-place it to get the current rate.
Another problem was that people would pay directly from an exchange "wallet", and the exchange might take a fee out for the transfer. So that 100 we requested might arrive as 90. I did allow up to 3% under-pay, but in cases where the difference was greater I had to leave the order open as partially paid (and request the buyer pay the missing difference). Then we found that if that difference was small, some people couldn't transfer that small amount from their exchanges (there were often minimum transfer limits).
Then on the company side, we've got crypto that we had to decide whether to sit on or convert to fiat. Obviously if the crypto market is on a bull run, it's beneficial to keep the money in crypto. But it's really a gamble (obviously a losing gamble in the last 10 months). So normally we would convert the crypto back to fiat every couple of days.
The technical aspects of all this were not really difficult, and it was nice being in charge of refund decisions (unlike when taking credit cards or paypal where a bad actor can cause immediate and long term problems for the merchant).