I want to build an online multiplayer board game with players stats, premium members payment etc, like chess.com or bridgebase.com , in slightly scaled down version.


1. webpage,
2. networking,
3. to write to the database,
4. to handle credit card payments.
5. Finally a good web and database hosting site.

1. Anything will do. Really. If you want tried-and-true that lets you get going quickly, go with PHP and perhaps some PHP framework (although some people say PHP is a framework in itself). You could even write it in J2EE if that's what you know, but I'd recommend against it. If you're adventurous, you might want to look into new-fangles systems like Node.js and Redis and whatnot, but I don't think that's needed in your particular case.
Btw: given the cost structure of Oracle, I would never use that for a web-based business. MySQL is tried-and-true. BigTable (Google) or SimpleDB are highly scalable and redundant service-based offerings, easy to use via HTTP. Key/value stores like Membase, RIAK, CouchDB or Redis are more of a specialty area, and probably not necessary for your particular use case.

2. Networking of WHAT? You can build networking on top of HTTP, as long as your command rate is low and you're OK with paying HTTP request header overhead. You can build a simple TCP-based messaging system in a few hours on top of winsock. You can use a pre-built library like Enet (free) or RakNet (combined free/pay-for) or something else. You have to be more specific in your requirements. Do you want to build matchmaking yourself or get it in the library? How about player chat? Lobbies? NAT punch-through?
Is this an installable application? For what operating systems? Or does it run in a web browser? As a plug-in? Using what technology?

3. PHP can write to the database. As can almost any other application server language. More interesting question: Who decides what to write? How will you avoid player cheating, like attaching to your game with a debugger and making it send packets it wouldn't otherwise send?

4. Morass. Warning! Beware! Users will steal credit cards and use on your site. Users will "borrow" cards from their friends or parents and use on your site. Users will use their own cards, and then change their minds. In each case, they will call their bank, saying "I didn't pay for that," and you will get a charge-back, which costs money, and if you get too many of them, you'll be dropped from the credit card provider. If you want to do this as a business, you need to hire people who know how to deal with this.
That being said, there are two ways to go: managed provider (Google Checkout, PayPal, Amazon Checkout, etc), or merchant bank. Managed providers charge higher fees, make it easier to get going, but ultimately add little value (and may in fact make it harder to pre-screen for fraud). Merchant banks charge lower fees, require integration (typically through some SOAP or XMLRPC callback) and let you do most of the front-end work, such as collecting billing addresses and whatnot.
You can choose various e-commerce packages from various web hosting providers, and my general feeling is that they are all terrible, and you're better off doing your own if that's the way you want to go.
Expect to spend at least 50% of your time on this part of the system, both when building, and when operating the system.

5. You get what you pay for. For "shared hosting," I've always been okay with DreamHost, at around $10/month. I wouldn't run a commercial site on that kind of plan, though. This means you have to pay for specific capacity. There are three options:
- virtual private servers -- many webhosts have these (including DreamHost)
- self-managed servers -- no virtualization; you get the real hardware! interserver.net and serverbeach.com are two of many possible hosts; Interserver has a "starter" option for about $39/month which is an Atom-based, 1 GB RAM host.
- cloud-based servers -- Rackspace and IBM and Microsoft have "offerings," but really, you want to be on the Amazon Cloud. If you don't tie yourself to a single availability zone, you won't be hit by outages like the one they had the other week. Google App Engine might be an option, but they charge by the "user," in a way that is more aimed at enterprise IT than public services AFAICT. Expect to pay several hundred dollars a month in hosting fees just to get started with a properly replicated, scalable, robust cloud solution. Then again, you'd get a properly replicated, scalable, robust solution :-)

If you want more specific answers, I suggest you write up a more specific, precise, question -- or hire someone to consult :-)