Right now, you should not be solving this problem. Not only is it a problem you do not have, but solving it too early may mean you will never have the problem. Lemme splain.
Lemme sum up. The more you try to reduce the % of fraud, the more it costs to prevent each instance of fraud. This cost is in the time you spend directly preventing fraud, the customers lost as false positives, and the extra effort legit customers must go through for your fraud protection. At a certain point, it makes more sense to instead allow some fraud, reduce the cost of fraud, and try to convert the fraudsters into legit users.
This is a brand new app and you have no customers. You need users and you need them to find your service so valuable they want to pay for it. You need to be focusing on...
- Getting the word out
- Features that people want
- Features that people want to pay for
- Easy sign up process
- Easy upgrade/payment process
All the extra checks you proposed to prevent people from abusing demo accounts (IP address, text messages, credit card imprint) are the opposite. Your users don't want those features and they make log in harder. They reduce the number of new users trying out your thing in a period when you need as many new users as you can get. I don't have numbers, but it would make an interesting A/B test!
This is what I like to call the "what happens when I have a million customers" problem. Solve it when you have it. Until then, focus on having that problem. Because it's a good problem. It means you have tons of potential customers and are so useful that people want to cheat to use your product.
You're trying to solve the problem of how you uniquely identify a single person on the Internet without making the account creation process too involved or invasive. This is a problem nobody has solved and it's one the Internet is incredibly resistant to (I don't mean just the people, I mean the design). Unless you have a walled garden (Google Play, iTunes Store, Steam), the industry and customers have settled on email validation as a compromise. Everything else is either too much work (credit card, SMS validation), has too many false positives (unique IP address), or excludes too many users (credit card, SMS validation).
Let's look at credit cards. First problem: not everyone has one! And I don't mean just 14 year olds, 30% of people in the US do not have a credit card. Second problem: not everyone wants to give it out just to get a free account just to find out if they want to pay for it. Third problem: it complicates the account creation process: credit card number, expiration date, CVV, address, real name... this on top of the usual email address, password, and email validation. Fourth problem: 35% of people in the US have three or more cards and can easily circumvent your protection.
When you have a problem that can't be solved, it's time to think about the problem. "Ensure Users Can't Sign Up For Multiple Accounts"... how does solving that aid your business? They're "stealing" something from you, right? That must be bad? Unless those demo accounts are costing you a lot of computing, storage or customer support, they're not stealing anything. What do you really want? You really want those users who are abusing the demo accounts to pay for an account. "Entice users to pay for an account rather than make multiple demo accounts". Bingo. That's the problem to solve.
These people like your product so much that they're willing to go through the effort to circumvent the system to continue using it for free. These aren't criminals to be punished, they're enthusiast cheap-skates. There's several solutions to the problem...
- Increase the effort to make a second demo account.
- Decrease the value of a demo account.
- Increase the value of a paid account.
Make it not worth the effort to cheat the system by working at both ends. If the user gets a lot for $5/month they'll be less likely to take the effort to create multiple email accounts to keep renewing demos.
- If they're a low percentage of your users, ignore them.
They don't want to pay? Fine. Don't try to get blood from a stone. Just make sure you're not spending much resources on those demo accounts.
- Make the free users valuable to the system.
This is exemplified by the freemium model where a very small percentage of the users pay most of the money. Everyone else plays for free. Free users "pay" by providing content for the paying users. This works best in social applications and multiplayer games. TechCrunch has a good break down.
- Make the transition from free to paid subtle.
Instead of cutting the user off and demanding money at an arbitrary time or feature limit, coax the user deeper and deeper into the system and provide them with soft limits they can eliminate with money. For example, in Rift, a Warcraft-like MMO, instead of having a level limit free users have limited inventory and can't use the Auction House. Freshbooks, an invoicing site, limits free customers to only three clients. These limits allow the user to get invested and decide when they're read to eliminate them.
The UX hump is getting the user's payment information. Once it's in your system, they can buy things with just a few clicks and the barriers to spending money have fallen. Spending just $5 in Rift unlocks a lot of small but important features, like the Auction House. In Freshbooks, if I have a lot of clients I'm making money so paying for an invoicing system seems natural.