It sounds like getting it fully automated might be easier on you.  Bitcoin is fully capable of that, but I don't know how easy it will be for your situation.  Is Python good for you?  Where is the user's information normally stored?

For ATITD we store everything on the server, which is a C++ program that periodically (every 3 minutes) writes its state to a checkpoint file. The server can pretend to be a web browser - we should be able to run bitcoin as a daemon and use JSON-RPC to generate an address for each payment.

In detail, we would:
1. Have the user request to pay by Bitcoins, using the game client.
2. Have server contact the daemon and asks for a new address.
3. Store that address in the player's record as an unconfirmed payment.
4. Tell the player the address to send the Bitcoins to.
5. Periodically poll the daemon for any recent payments, and change any unconfirmed payments to confirmed.

Here are the problems that I see: (Still wrapping my head around some of this!)
1. Suppose the server crashes after we've generated the address, but before the checkpoint has completed writing (so, up to 3+3=6 minutes), a payment could show up but we'd have no way of knowing what character it was for.
2. A running daemon is one more thing that could fail.

Have I overcomplicated the process? It's too bad that there's no way to embed a message in a payment; if there was, the process would be:
1. User sends payment to the one address that we publish, and writes his character name in the message field. Easy for the user and no game UI required.
2. Periodically poll the daemon for any recent payments, crediting accounts based on the message field.

In this scenario, the daemon would still need to be running for the credit to show up in the user's account, but not for the user to make a payment. In no event would the payment get lost.

Now, practically speaking, the server crash scenario isn't a problem for ATITD, because we're a small game and Bitcoin payments will be a tiny fraction of all payments. But PayPal became popular because it was *so* easy for both merchants and users to understand the "send money to an email address" metaphor.

"Send money to this weird looking address" isn't that much harder to grasp. "Send money to a different address every time", or "send money to an address that I'll tell you in a minute but which will be unique for you" is a bigger leap though.

I don't understand the data structure of "a bitcoin" enough yet to suggest a solution.

Although you need a unique BA for each user, you don't necessarily need to regenerate a new BA for every user's transaction.  You can issue a single BA for each user and then keep tallies (in your database) on the amount received from this ongoing BA.

This sounds like it would work.

You could...

1. Issue a new BA to ALL users and set a tally value to 0 for each user's BA.
2. Email these BA's to your users.
2. Poll these BA's from the daemon every 10 minutes.
3. If the amount received from a BA is greater then the tally value then count the difference as a new deposit and increment the tally.

Or something similar to that.  This could be done in a separate process too.