Basically, let's say i have an account to accept donations, money for purchases of my games, etc. What i want to do, is set up a system, where people (say, in a special thread on my forum) pay, like, 25c, to vote me making a change in my game, or creating and adding a piece of content of a particular nature/theme. And when any such idea gets, say, 20$ total - i act on that and make the change that was voted in. Otherwise, after a certain time has passed, each 50c donation is returned to sender. The question is, say i have 10 forum threads with such voting installed - would i need a separate account for each "tip jar" ? Do i need to talk to a bank manager, or can you just do such things online these days ? Will said bank manager even understand what i want, or be bothered to do such a thing for such small sums ? Or is it really, as i think at the moment, much, MUCH more trouble than it's worth ?

I think it's a very bad idea to design a game by democratic vote.

I think it's a better idea for you as a designer to decide what your future features are going to be, and then allowing users to vote (with money or otherwise), on what ones they want prioritized or implemented first. Or at the very least, to provide them with the options (i.e. "Do you want A or B?").

That said, you weren't asking about design, so I'll leave my thoughts at that.

Basically, let's say i have an account to accept donations, money for purchases of my games, etc. What i want to do, is set up a system, where people (say, in a special thread on my forum) pay, like, 25c, to vote me making a change in my game, or creating and adding a piece of content of a particular nature/theme. And when any such idea gets, say, 20$ total - i act on that and make the change that was voted in.Otherwise, after a certain time has passed, each 50c donation is returned to sender. The question is, say i have 10 forum threads with such voting installed - would i need a separate account for each "tip jar" ?

No, you won't need separate accounts for each thread. When making a purchase, the user sends you the money, and (depending on how the code works on your side of the system), your server will see it's on item #27. Think of a online shopping cart - they don't need a separate bank account for each item they have in the store. Your feature lists are just separate "items".

Don't forget credit card/paypal fees, and so on. If the user sends you 25c and you send them back 21c, they'll think you are ripping them off.

Instead, I'd have players buy "coins" or whatever, in chunks of (for example) $5, $10, and $20, and pay the credit card costs on that.
In your system you can entirely server-side, without involving third parties, take and return coins as many times as you want without paying credit card fees.

How come this forum suddenly doesnt support paragraphs anymore ? My posts come out as solid blocks of text. - I never said i was DESIGNING game by a vote. - >Think of a online shopping cart - they don't need a separate bank account for each item they have in the store. - I dont think it is a good analogy, because in shops - no matter how many items i put in my "basket" - no money actually change hands, until i make the purchase, which is when i pay the whole price in one go. >Instead, I'd have players buy "coins" or whatever, in chunks of (for example) $5, $10, and $20, and pay the credit card costs on that. What would be the title of the software package that will allow me to set it up like that ? Also, what you suggest is, in my mind, more suitable for pre-purchasing, or, say, some limited time exclusivity for a piece of DLC, but not exactly what i want to achieve. What i want is basically what Kickstarter does, except not on Kickstarter, and on much smaller scale.

How come this forum suddenly doesnt support paragraphs anymore ? My posts come out as solid blocks of text.

It does. Sometimes it just gets messed up. I'm not sure what triggers it.

Think of a online shopping cart - they don't need a separate bank account for each item they have in the store.

I dont think it is a good analogy, because in shops - no matter how many items i put in my "basket" - no money actually change hands, until i make the purchase, which is when i pay the whole price in one go.

Regardless, the APIs behind the scene create a transaction where money is taken out of the customer's account and put in your account. What they are buying is handled on your side, so your side is the one that needs to detect what page/item/whatever they were on when they hit "buy".

what you suggest is, in my mind, more suitable for pre-purchasing, or, say, some limited time exclusivity for a piece of DLC, but not exactly what i want to achieve. What i want is basically what Kickstarter does, except not on Kickstarter, and on much smaller scale.

PayPal allows tiny payments like that.

I don't know if they'd like you making transactions, undoing transactions, making transactions, undoing transactions, though, and you'll get better prices (i.e. they'll take a smaller cut) if you group things into bigger payments, which is why I suggested letting customers buy "votes" in bigger bulk. Make it $2.50 then, for 5 votes.

Instead, I'd have players buy "coins" or whatever, in chunks of (for example) $5, $10, and $20, and pay the credit card costs on that.

What would be the title of the software package that will allow me to set it up like that ?

The more you customize your requirements, the less you'll find software packages already available for you. You'll have to go a step lower level, and write your own using PayPal's (or Amazon's, Google's, or Apple's) APIs.

I haven't personally done this, so I can't recommend any higher level software package or low level API.

You might consider using an existing system that supports a bounty system.

There are some companies that provide 'bug bounties' when you report a defect or critical flaw, but there are also systems like "Git Bounty" and "BountySource" that work where people pay to get features implemented or bugs fixed.

Those work as you describe: an issue is opened, people provide information about what they want and what payment they are willing to contribute. Others can add to it, adding their own tiny amount to be paid to whoever implements the feature or fixes the bug in the open source project. When it is in and confirmed, the money is sent to the developer who submitted the change.