Easiest way to accept BTC and test

[jlp]

Yes that will be a hot wallet. But I'd cron it to transfer a certain amount out every hour.

There's nothing stopping you from using coinbase either

Even though our game is skill-based, there is an element of chance.  Hence, it will be deemed as gambling.  Coinbase will not help us because of this.

Building a hot wallet on our server seems like more work than using Blockchain.info's "receive payment API", isn't it?  We don't know how popular bitcoin will be with our users.  Therefore, it seems that it will be easier to use Blockchain.info first and if it gets traction, then we build the hot wallet.  Please do not hesitate to tell me otherwise as I welcome any additional input and appreciate your suggestion of the hot wallet.  That is good to know and hopefully, we'll get to the stage where we need it.  Thanks.

[1713561786]

1713561786

[1713561786]

1713561786

[1713561786]

1713561786

[bitpop]

Yes that will be a hot wallet. But I'd cron it to transfer a certain amount out every hour.

There's nothing stopping you from using coinbase either

Even though our game is skill-based, there is an element of chance.  Hence, it will be deemed as gambling.  Coinbase will not help us because of this.

Building a hot wallet on our server seems like more work than using Blockchain.info's "receive payment API", isn't it?  We don't know how popular bitcoin will be with our users.  Therefore, it seems that it will be easier to use Blockchain.info first and if it gets traction, then we build the hot wallet.  Please do not hesitate to tell me otherwise as I welcome any additional input and appreciate your suggestion of the hot wallet.  That is good to know and hopefully, we'll get to the stage where we need it.  Thanks.

Ok keep it simple, use a hot wallet all around. Minimum viable product. Until it gets to an amount you can't insure, move on. I'm available for consulting and programming.

There's also mtgox which probably won't care if you don't do fiat. Or btce. Exchanges might be better since withdrawing is more separated.

[jlp]

Ok keep it simple, use a hot wallet all around. Minimum viable product. Until it gets to an amount you can't insure, move on. I'm available for consulting and programming.

There's also mtgox which probably won't care if you don't do fiat. Or btce. Exchanges might be better since withdrawing is more separated.

Sorry, I'm confused.  I thought using Blockchain.info's "receive payment API" is simpler.  How is the hot wallet simpler than Blockchain?

Thanks for suggesting MtGox.  I found this:  https://www.mtgox.com/merchant  and I sent them an inquiry on whether they will work with gambling sites and for more information on how to use their Payment Gateway.

What is "btce".  I found https://btc-e.com/ which is an exchange but doesn't seem to provide payment processing.

[bitpop]

Ok keep it simple, use a hot wallet all around. Minimum viable product. Until it gets to an amount you can't insure, move on. I'm available for consulting and programming.

There's also mtgox which probably won't care if you don't do fiat. Or btce. Exchanges might be better since withdrawing is more separated.

Sorry, I'm confused.  I thought using Blockchain.info's "receive payment API" is simpler.  How is the hot wallet simpler than Blockchain?

Thanks for suggesting MtGox.  I found this:  https://www.mtgox.com/merchant  and I sent them an inquiry on whether they will work with gambling sites and for more information on how to use their Payment Gateway.

What is "btce".  I found https://btc-e.com/ which is an exchange but doesn't seem to provide payment processing.

That's the btce but I guess there's no api. By blockchain hot wallet I mean holding the coins in their wallet too. The receive api can be pointed anywhere including their own.

[bit gambler]

The best idea would be using the bitcoin API call list.
you can also use blockchain.info but if you should know that sometimes they fail to send the notification or send it much later then the actual transaction took place,
so basically using a blockchain is a single failure point.

[jlp]

The best idea would be using the bitcoin API call list.
you can also use blockchain.info but if you should know that sometimes they fail to send the notification or send it much later then the actual transaction took place,
so basically using a blockchain is a single failure point.

Thanks for your input and warning.  We don't know how popular bitcoins will be with our players, so we want to build the minimum viable product initially.  Besides, it seems that using the bitcoin API call list seems much more complicated.  With Blockchain.info, I assume that you are referring to our callback URL that they will post to.  Would you know how often Blockchain.info has failed or been late in sending the notifications to the callback URL?  Have you had experience in using Blockchain.info's "receive payment API"?

[bitpop]

You should be aware that security is pull only. So even if they push a notification, you must also pull. You can also bulk pull hourly to catch missed payments.

[jlp]

You should be aware that security is pull only. So even if they push a notification, you must also pull. You can also bulk pull hourly to catch missed payments.

I'm not sure what you mean by "security is pull only".

How do we pull?  I checked out the following from Blockchain.info:

• JSON API:  https://blockchain.info/api/blockchain_api
  
• Query API:  https://blockchain.info/q

The closest or most relevant thing to what you are talking about, that I can find is their "Single Address" JSON API, or specifically:  http://blockchain.info/address/$bitcoin_address?format=json  I think it shows the following as their JSON response?

{
   "hash160":"660d4ef3a743e3e696ad990364e555c271ad504b",
   "address":"1AJbsFZ64EpEfS5UAjAfcUG8pH8Jn3rn1F",
   "n_tx":17,
   "n_unredeemed":2,
   "total_received":1031350000,
   "total_sent":931250000,
   "final_balance":100100000,
   "txs":[--Array of Transactions--]
}

However, I do not see how the above enables me to pull security.

[bit gambler]

The best idea would be using the bitcoin API call list.
you can also use blockchain.info but if you should know that sometimes they fail to send the notification or send it much later then the actual transaction took place,
so basically using a blockchain is a single failure point.

Thanks for your input and warning.  We don't know how popular bitcoins will be with our players, so we want to build the minimum viable product initially.  Besides, it seems that using the bitcoin API call list seems much more complicated.  With Blockchain.info, I assume that you are referring to our callback URL that they will post to.  Would you know how often Blockchain.info has failed or been late in sending the notifications to the callback URL?  Have you had experience in using Blockchain.info's "receive payment API"?

I am talking about the "callback url" field at the blockchain.info (as you mentioned... ).
I worked with blockchain for a while and I cant tell you exactly how often they fail to send notification but it happens sometimes, so you can't trust it for 100%.
using bitcoin API calls it is more complicated but you can try to look for open source implementation of higher level (C# maybe..) if you don't want to implement it by yourself or buy from some one for a few bitcoins maybe... and use it.
Or at least try to use some other service for payment notifications to make 2 points of failure.
because otherwise you'll have some very disappointment customers and that cant be good especially for a new site.. :-)

[bitpop]

You should be aware that security is pull only. So even if they push a notification, you must also pull. You can also bulk pull hourly to catch missed payments.

I'm not sure what you mean by "security is pull only".

How do we pull?  I checked out the following from Blockchain.info:

• JSON API:  https://blockchain.info/api/blockchain_api
  
• Query API:  https://blockchain.info/q

The closest or most relevant thing to what you are talking about, that I can find is their "Single Address" JSON API, or specifically:  http://blockchain.info/address/$bitcoin_address?format=json  I think it shows the following as their JSON response?

{
   "hash160":"660d4ef3a743e3e696ad990364e555c271ad504b",
   "address":"1AJbsFZ64EpEfS5UAjAfcUG8pH8Jn3rn1F",
   "n_tx":17,
   "n_unredeemed":2,
   "total_received":1031350000,
   "total_sent":931250000,
   "final_balance":100100000,
   "txs":[--Array of Transactions--]
}

However, I do not see how the above enables me to pull security.

You would use https://blockchain.info/q/getreceivedbyaddress and loop through transactions making sure you got them all. Set it to a few confirmations.

Your cron would loop through all your player addresses, then loop through all their payments and make sure you got them all. Database is easy due to transaction ids.

Your ipn would trigger the second part.

On registration you assign an address with the receive api. But remember this address has to work forever in case they store it, so forward it knowing that.

[jlp]

You would use https://blockchain.info/q/getreceivedbyaddress and loop through transactions making sure you got them all. Set it to a few confirmations.

Your cron would loop through all your player addresses, then loop through all their payments and make sure you got them all. Database is easy due to transaction ids.

Your ipn would trigger the second part.

On registration you assign an address with the receive api. But remember this address has to work forever in case they store it, so forward it knowing that.

Thanks.  You wrote "Your ipn would trigger the second part.".  What is ipn?  instant payment notification?  What second part are you referring to?  The "cron"?  If so, why would the ipn trigger the cron if the cron is supposed to run every hour?

You wrote: "On registration you assign an address with the receive api."  Are you referring to my registration with Blockchain?  I don't know what you mean by "forward it".

[bitpop]

You would use https://blockchain.info/q/getreceivedbyaddress and loop through transactions making sure you got them all. Set it to a few confirmations.

Your cron would loop through all your player addresses, then loop through all their payments and make sure you got them all. Database is easy due to transaction ids.

Your ipn would trigger the second part.

On registration you assign an address with the receive api. But remember this address has to work forever in case they store it, so forward it knowing that.

Thanks.  You wrote "Your ipn would trigger the second part.".  What is ipn?  instant payment notification?  What second part are you referring to?  The "cron"?  If so, why would the ipn trigger the cron if the cron is supposed to run every hour?

You wrote: "On registration you assign an address with the receive api."  Are you referring to my registration with Blockchain?  I don't know what you mean by "forward it".

IPN i mean the callbackurl.
By triggering cron I mean the cron script, a subset of it, not an actual cron.

No on player registration. The receive api forwards bitcoin, it doesn't store it.

[jlp]

IPN i mean the callbackurl.
By triggering cron I mean the cron script, a subset of it, not an actual cron.

No on player registration. The receive api forwards bitcoin, it doesn't store it.

When I wrote "cron", I was referring to your statement about cron:  You wrote: "Your cron would loop through all your player addresses, then loop through all their payments and make sure you got them all."  Aren't you referring to a cron script?  Why would the ipn trigger the cron script if the cron script is supposed to run every hour?

Why would I assign an address to players upon their registration on our site?  Assign the address to whom?  I don't know what you mean by "On registration you assign an address with the receive api".  My understanding of how the Blockchain.info's Receive Payment API works is this:  When my player wants to deposit bitcoin, I call the Blockchain API, providing my receive address.  The API returns a receive address (that belongs to Blockchain), that I show to my player, so that my player can send bitcoin to that address.  After the player sends bitcoin to that address, Blockchain forwards the bitcoin to my receive address.  The next time the same player wants to deposit money again, I call the Blockchain API again, providing my receive address, and the API provides another (different) receive address (which belongs to Bockchain), which I show to my player.  So, each time a player wants to send bitcoin to me, the player is sending to a different address provided by Blockchain.

[bitpop]

Well you will have a "cron" script that is cronned. But that same script can be called manually EXTRA TIMES and telling it to just check one address, the ipn one. You wouldn't listen the the ipn, just use it to call the cron script manually. Watch out for differences in confirmations between ipn and cron though.

For simplicity, you might want to assign one permanent address to each player. This will make it easier to cron, less queries. Second, even if you change it everytime, people will reuse, if not only the first time by sending 2 transactions. So using new ones each time doesn't give you an excuse not to check each one every time which increases queries. But yes, best practices says to use a new one each time.

Depending on how many players, you may hit blockchain api limits. Thankfully, you can transition to your own bitcoin abe at that time and still use the receive api.

[moocoin]

So we recently went through this when developing MooCoin.

Let me save you some heartache.

First, don't use the blockchain API.  You'll end up using it for a while, fighting with it, not getting support when it goes down, then moving to your own wallet anyway.  The API goes down all the time, and if you're accepting bitcoin deposits, their realtime address subscription websocket is REALLY unstable.  We spent weeks trying to get it running before giving up and moving to our own wallet on our own servers.  It's really not as hard as you think to do that.  Especially because I can help answer questions you might have since we just did it 

Second, start by really understanding the bitcoin account system in the reference client, and using it.  You may want to move away from it to an offline ledger at some point, but it's totally usable for an MVP.  It will simplify everything.  When you're reading about the account system, realize that you're the bank, and each of your players has an account. 

If you want a place to start, look at the walletnotify and blocknotify options in the bitcoin.conf.  Those will tell you when a deposit has come in to one of your addresses (accounts), and when you have confirmations of those deposits.

Use the testnet.  There are faucets out there that will give you testnet coins, and it's as easy as running your client with testnet=1 in your bitcoin.conf.  You're going to be doing SO many transactions that the network fees become expensive.  And, you're going to want to test a 50 BTC wager at some point and you likely don't want to mess that up on the main net.

Even if you don't build cold-storage capabilities at first, at least think through how you will do it in the future.  It has some architectural implications that you'll want to get right the first time to avoid re-working large parts of the app.

Go play around with MooCoin.  Check out what we did to get some ideas about what's possible.  We're happy to help. 

Lastly, and it pains me to say this, be careful who you trust around here.  The Bitcoin community is really turning a corner for the better, but there's still a large portion of people that are remnants of the bad old days.  Hacking attempts, scams, etc are rife in this community.  Just be careful.

Good luck!  The community needs some more cool and unique playthings amongst the rabble of dice games.  Go build something awesome and let us know if you need help!

Thanks,
The MooCoin Team

[jlp]

So we recently went through this when developing MooCoin.

Thanks for your posting.  It is very interesting, as your experience is similar to what I'm trying to do.  Your suggestions sound very good.

To simplify our lives, we would rather use Bitpay or Coinbase.  Even though our game requires skill, there is still an element of chance, hence it can be deemed as gambling.  Therefore, Coinbase and Bitpay won't help us.  Am I correct to assume that your game is deemed as gambling and that's why you had to use bitcoind or Blockchain?

How much extra work was it to get bitcoind and wallet running on your server, versus Blockchain.info's API?

Have you ever looked at using MtGox or any of the "Merchant Services" (payment processors) listed at https://en.bitcoin.it/wiki/How_to_accept_Bitcoin,_for_small_businesses and https://en.bitcoin.it/wiki/Merchant_Howto?

Second, start by really understanding the bitcoin account system in the reference client, and using it.

When you say "bitcoin account system", are you referring to the "Original Bitcoin client/API calls list" (https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list)?

Did you start with this tutorial?:  https://en.bitcoin.it/wiki/PHP_developer_intro

look at the walletnotify and blocknotify options in the bitcoin.conf.

I don't have bitcoin.conf on my Mac, but I do have bitcoin-temp.conf.  I do not have walletnotify or blocknotify in my bitcoin-temp.conf, but I found this:  https://bitcointalk.org/index.php?topic=203438 which explains how to use walletnotify, but it sounds complicated.

I checked out MooCoin.  What is the difference between the address in the personal URL and the public account ID?

Unlike MooCoin, our users are already registered with usernames.  Am I correct to assume that we should assign a different bitcoin address to each user for them to make deposits to, and re-use the address when the user wants to make subsequent deposits?  (I assume that when our users wants to withdraw, we should prompt him/her for his/her bitcoin address, store it and use it for future withdraws.)

The Bitcoin community is really turning a corner for the better, but there's still a large portion of people that are remnants of the bad old days.  Hacking attempts, scams, etc are rife in this community.  Just be careful.

The users on the bitcoin forums seem like they are trying to be helpful.  What are they are trying to scam or hack?

[moocoin]

So we recently went through this when developing MooCoin.

Thanks for your posting.  It is very interesting, as your experience is similar to what I'm trying to do.  Your suggestions sound very good.

To simplify our lives, we would rather use Bitpay or Coinbase.  Even though our game requires skill, there is still an element of chance, hence it can be deemed as gambling.  Therefore, Coinbase and Bitpay won't help us.  Am I correct to assume that your game is deemed as gambling and that's why you had to use bitcoind or Blockchain?

How much extra work was it to get bitcoind and wallet running on your server, versus Blockchain.info's API?

We started with blockchain.  The experiences I mentioned above around lack of support and reliability led us to investigate something else.  We decided on our own wallet for three reasons:
1)  We already had the blockchain integration, which is basically the exact same as the bitcoind integration, so it was less work.
2)  We had a bad taste in our mouth about outsourcing that incredibly critical part of the stack. 
3)  We want local wallet performance.

Once you have the blockchain/bitcoin integration (again, they're basically the same), the effort of moving to a local wallet is:
1)  Install the client and configure it to run as a server (minimal work)
2)  Understand the security implications of having a local wallet, cold storage, etc.  You'll have security work with an outsourced partner as well, so I don't think this work is really incremental.

Have you ever looked at using MtGox or any of the "Merchant Services" (payment processors) listed at https://en.bitcoin.it/wiki/How_to_accept_Bitcoin,_for_small_businesses and https://en.bitcoin.it/wiki/Merchant_Howto?

Yes, but we wanted a tighter integration with the network. We don't consider ourselves a merchant.  The goals are different.  We don't care about fiat prices, exchanging for USD, physical terminals and QR codes, etc.  Our integration is basically the "Pre-generating Bitcoin addresses" option in the document you linked.

Second, start by really understanding the bitcoin account system in the reference client, and using it.

When you say "bitcoin account system", are you referring to the "Original Bitcoin client/API calls list" (https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list)?

Yes.  Here is a better article:  https://en.bitcoin.it/wiki/Accounts_explained
Having a local wallet and an account for each user lets you move money around between users in the system without incurring confirmation delays or network costs.  Depends on your needs, but that was critical for the head-to-head aspect of our games.

Did you start with this tutorial?:  https://en.bitcoin.it/wiki/PHP_developer_intro

No, but it looks like a fine article.  Our technology stack is node.js on the backend.  There's a node-bitcoin package that we use to integrate with the json-rpc API.  We just used that and the Original API document you referenced above.

look at the walletnotify and blocknotify options in the bitcoin.conf.

I don't have bitcoin.conf on my Mac, but I do have bitcoin-temp.conf.  I do not have walletnotify or blocknotify in my bitcoin-temp.conf, but I found this:  https://bitcointalk.org/index.php?topic=203438 which explains how to use walletnotify, but it sounds complicated.

If you have the client installed, your bitcoin.conf should be in ~/Library/Application Support/bitcoin.conf.  If it's not there, create it and then you can use the following options to control the client:  https://en.bitcoin.it/wiki/Running_Bitcoin

For walletnotify, it's easy.  It just says that whenever a transaction hits the wallet (a deposit, for example), call your command line.  What we do is use curl to post the transaction to our node.js webserver, which then handles the transaction.

I checked out MooCoin.  What is the difference between the address in the personal URL and the public account ID?

The address in the URL is a private address.  If you give that to someone, they can put it in their own URL and be playing as you, including withdrawing funds.

The public account ID is something you can share with others in public forums without fear of someone logging in as you.  In fact, our referral program uses the public ID as an ID to refer others publicly.

Unlike MooCoin, our users are already registered with usernames.  Am I correct to assume that we should assign a different bitcoin address to each user for them to make deposits to, and re-use the address when the user wants to make subsequent deposits?  (I assume that when our users wants to withdraw, we should prompt him/her for his/her bitcoin address, store it and use it for future withdraws.)

There are differing schools of thought on this.  The "purists" point to the fact that bitcoin's anonymity and plausible deniability come from the way it never re-uses addresses.  The "pragmatists" point that that it's a lot easier to re-use them in cases where anonymity isn't required.  I'm in the first camp, but for reasons of simplicity, MooCoin reuses addresses.  Each user has a dedicated address.

The Bitcoin community is really turning a corner for the better, but there's still a large portion of people that are remnants of the bad old days.  Hacking attempts, scams, etc are rife in this community.  Just be careful.

The users on the bitcoin forums seem like they are trying to be helpful.  What are they are trying to scam or hack?

I was talking about the Bitcoin community - not the community on this board.
I guess it's harsh to call them unsavory.  Opportunistic is probably more accurate.  Sites that hold bitcoins, or credentials that have access to bitcoins, are a huge target for hackers.  The things that make bitcoin great, for example, anonymity, immediacy, virtuality, are also things that make it very easy to steal without repercussion.  Know that your server will be attacked, your faucet will be drained, your games will be botted, your service provider will let people in to your datacenter to install VKMs, etc.  All of these things have happened and will continue to happen.  Be prepared as you become the steward of the trust and currency of the folks on your website.

[jlp]

Once you have the blockchain/bitcoin integration (again, they're basically the same), the effort of moving to a local wallet is:
1)  Install the client and configure it to run as a server (minimal work)
2)  Understand the security implications of having a local wallet, cold storage, etc.  You'll have security work with an outsourced partner as well, so I don't think this work is really incremental.

It was suggested to me that when users withdraw, I should send bitcoins to users manually from an offline wallet.  I was thinking of using Armory to do this and to install an Armory Watching-only wallet (https://bitcoinarmory.com/about/using-our-wallet/) on the server.  Have you looked into this?  Did you use Armory's offline wallet for your "cold storage"?

Did you automate the sending of bitcoins to users?

I read up on https://en.bitcoin.it/wiki/Accounts_explained.  It states: 

Wallet backups are an issue; if you rely on a good backup of wallet.dat then a backup must be done every time an address is associated with an account and every time the 'move' command is used.
The accounts code does not scale up to thousands of accounts with tens of thousands of transactions, because by-account (and by-account-by-time) indices are not implemented. So many operations (like computing an account balance) require accessing every wallet transaction.
Most applications already have a customer database, implemented with MySQL or some other relational database technology. It is awkward at best to keep the bitcoin-maintained Berkely DB wallet database and the application database backed up and synchronized at all times.

Armory claims that one backup of their wallet is good enough forever.  I wonder if their wallet backups have the same issue as stated above.

If the accounts code does not scale up to thousands of accounts, then what are you going to do if you get thousands of customers?

Do you try to synchronize your database with Bitcoin's wallet database?

Thanks for your help and suggestions.  I think I got my work cut out for me.  I will do the following:

• Install Armory
• Add walletnotify and blocknotify options in bitcoin.conf
• Get Testnet coins from faucets
• Run Bitcoind with testnet=1 in bitcoin.conf
• Try executing Bitcoin API and Account commands and send Testnet coins to myself

https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list shows a list of "Typical Uses".  It doesn't explain how to send bitcoins to a customer, to enable the customer to withdraw.  Do you use sendtoaddress?

According to https://bitcointalk.org/index.php?topic=300632.0, we should do this:

• Create a new account for each user to accept deposit from with getaccountaddress
  
• Then have a daemon that checks listsinceblock for any deposits.
  
• If deposit is found, use move to transfer the balance to the "bank" account and credit the user.
  
• Then the next time listsinceblock is called, they will show up as 0.
  
• All outgoing withdraw is sent via move from "bank" account to withdraw address.

Is the above what you did?  Am I correct to assume that you use walletnotify and blocknotify instead of "a daemon that checks listsinceblock for any deposits"?

I cannot find out anywhere how blocknotify tells me that a particular transaction is confirmed.  Am I correct to assume that I will receive data from blocknotify once I test with Testnet coins and this data will contain the transaction ID (from which I can use gettransaction <txid> to get the customer's account, address and amount)?

Do I need SSL to run Testnet or main Bitcoin network?

According to http://www.ideaexcursion.com/2013/09/18/developing-against-bitcoind/:  "working with Bitcoin can be EXCRUCIATINGLY difficult" and there are a lot of things to do when using it.  I think the adoption of Bitcoin for consumers and sellers of services/goods will be much more widespread if Bitcoin was easier.  Hopefully, I can ask you more questions if I run into difficulty.

Know that your server will be attacked, your faucet will be drained, your games will be botted, your service provider will let people in to your datacenter to install VKMs, etc.

What are VKMs?  Virtual Knowledge Managers?  What harm can they do?

[moocoin]

It was suggested to me that when users withdraw, I should send bitcoins to users manually from an offline wallet.  I was thinking of using Armory to do this and to install an Armory Watching-only wallet (https://bitcoinarmory.com/about/using-our-wallet/) on the server.  Have you looked into this?  Did you use Armory's offline wallet for your "cold storage"?

Did you automate the sending of bitcoins to users?

We wanted withdrawals automated, so we don't use a watch-only wallet.

I read up on https://en.bitcoin.it/wiki/Accounts_explained.  It states: 

Wallet backups are an issue; if you rely on a good backup of wallet.dat then a backup must be done every time an address is associated with an account and every time the 'move' command is used.
The accounts code does not scale up to thousands of accounts with tens of thousands of transactions, because by-account (and by-account-by-time) indices are not implemented. So many operations (like computing an account balance) require accessing every wallet transaction.
Most applications already have a customer database, implemented with MySQL or some other relational database technology. It is awkward at best to keep the bitcoin-maintained Berkely DB wallet database and the application database backed up and synchronized at all times.

Armory claims that one backup of their wallet is good enough forever.  I wonder if their wallet backups have the same issue as stated above.

If the accounts code does not scale up to thousands of accounts, then what are you going to do if you get thousands of customers?

Do you try to synchronize your database with Bitcoin's wallet database?

We solve the wallet backup problem by keeping a copy of the private keys in the database.  For now, we're using the account system with thousands of accounts and tens-of-thousands of transactions without issue.  We have a secondary ledger than uses walletnotify and blocknotify to stay in sync.  We still use the bitcoin account system as the place of record, but our side-by-side tests have been perfect so far.  We could move off of the built-in account system if we needed to.  But you asked the easiest way to do some testing - not the most robust 
FWIW, this is also our cold-storage strategy.  When a user logs in, we push funds from the holding account into their account so they can play.  When they logout, we move it back to the holding account.  Then, we only keep a percentage of the total funds in teh holding account to support the numebr of people on the site at any given time.  This means if we got a rush of users, we would need to turn some away.  If only that would happen 

I'm not familiar enough with the armory system to comment on their wallet.  Perhaps they create a large number of addresses instead of the 100 (default) created by the reference client?  Not sure...

Thanks for your help and suggestions.  I think I got my work cut out for me.  I will do the following:

• Install Armory
• Add walletnotify and blocknotify options in bitcoin.conf
• Get Testnet coins from faucets
• Run Bitcoind with testnet=1 in bitcoin.conf
• Try executing Bitcoin API and Account commands and send Testnet coins to myself

That sounds about right.  Note that you can do all of that without writing any software.  *notify can just be echos to a text file.  Also, bitcoind is a commandline version of the api, so you can do bitcoind getinfo, or bitcoind listtransactions, etc. to test out the api.

https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list shows a list of "Typical Uses".  It doesn't explain how to send bitcoins to a customer, to enable the customer to withdraw.  Do you use sendtoaddress?

We user sendFrom so they funds are removed from the users account, rather than the wallet.

According to https://bitcointalk.org/index.php?topic=300632.0, we should do this:

• Create a new account for each user to accept deposit from with getaccountaddress
  
• Then have a daemon that checks listsinceblock for any deposits.
  
• If deposit is found, use move to transfer the balance to the "bank" account and credit the user.
  
• Then the next time listsinceblock is called, they will show up as 0.
  
• All outgoing withdraw is sent via move from "bank" account to withdraw address.

Is the above what you did?  Am I correct to assume that you use walletnotify and blocknotify instead of "a daemon that checks listsinceblock for any deposits"?

Pretty close.  We create a new account for the user, then use walletnotify to watch for deposits.  When a deposit comes in, it's "unverified".
We then use blocknotify to watch for new blocks.  When a block comes in, we check the balance of the users account with 0 confirmations, then again with 4 confirmations.  The delta is their "unconfirmed" balance.
We don't do the sweep currently on the live site, but that's how we handle cold storage.

I cannot find out anywhere how blocknotify tells me that a particular transaction is confirmed.  Am I correct to assume that I will receive data from blocknotify once I test with Testnet coins and this data will contain the transaction ID (from which I can use gettransaction <txid> to get the customer's account, address and amount)?

It's not obvious. 
You can call getbalance and pass in the number of confirmations you want.  So if a user has 10 confirmations on their first 1btc deposit, and 2 confirmations on their second 5btc deposit:
getbalance 0 confirmations = 6btc
getbalance 4 confirmations = 1btc
From that, we can calculate that they have a balance of 1btc, and an additional 5btc unconfirmed.

So then blocknotify is only used to say, "A new block was received, and users' confirmations may have changed." 
We just use it to trigger a re-check of the users that have unconfirmed funds.  If the confirmed and unconfirmed balances are the same, we can stop checking their account with each new block.

Do I need SSL to run Testnet or main Bitcoin network?

According to http://www.ideaexcursion.com/2013/09/18/developing-against-bitcoind/:  "working with Bitcoin can be EXCRUCIATINGLY difficult" and there are a lot of things to do when using it.  I think the adoption of Bitcoin for consumers and sellers of services/goods will be much more widespread if Bitcoin was easier.  Hopefully, I can ask you more questions if I run into difficulty.

Only run on testnet.  There's no need to run on mainNet until you're getting close to launch. 
I'm happy to answer questions.  Just know that you're only getting one team's opinion.  There are a million ways to do things 

Know that your server will be attacked, your faucet will be drained, your games will be botted, your service provider will let people in to your datacenter to install VKMs, etc.

What are VKMs?  Virtual Knowledge Managers?  What harm can they do?

Virtual Keyboard and Mouse.  A well known bitcoin casino had their data center's maintenance site hacked.  Someone put in an order to have a VKM installed.  The machine rebooted and the attackers attempted to use the vkm to get console access.  Thankfully, the casino used full-disk encryption, so reboots required a manual password step. 
Attackers in this space are really, really clever.

[bitpop]

What are VKMs?  Virtual Knowledge Managers?  What harm can they do?

Virtual Keyboard and Mouse.  A well known bitcoin casino had their data center's maintenance site hacked.  Someone put in an order to have a VKM installed.  The machine rebooted and the attackers attempted to use the vkm to get console access.  Thankfully, the casino used full-disk encryption, so reboots required a manual password step. 
Attackers in this space are really, really clever.

lmao