It really depends on your business model.
If you accept the transfer, and then it is reversed, how significant of a problem is that? (For example, with a web hosting service, the provider can simply shut the service off if/when the payment is reversed).
Do you have any identifying information about your customers that would discourage fraud? (For example, if you are shipping them a product, you have their address).
Can you respond quickly enough to a significant increase in fraud to prevent problematic losses if the fraud rate suddenly increases? (For example, if you find that typically 1 out of every 10,000 transactions are reversed, and then suddenly 80 out of 100 transactions are reversed)
Without confirmations, there is always a risk that someone could get a conflicting transaction confirmed in place of the one they sent you. This is the reason that confirmations exist, and is one of the problems that Satoshi solved with this distributed consensus concept. You have to decide for yourself how significant that particular risk is to your business.
Cheers Danny,
-Unfortunately, reversals would be a huge problem, rendering our model non-viable.
-We considered taking registered user accounts/KYC, and this is still a possibility. However, we wanted to make the site with simplicity in mind (end user experience).
-Our engineer(s) will write Safe Guards and Permissions to near best industry standards. But I want to negate the problem altogether.
Thanks again for your input mate : )
