Sooner or later it's going to happen. A freelance client is going to want an e-commerce website, and while the programming doesn't scare me, the handling of other people's money does. Thing like this should be done right.
So, successful e-commerce site builders, what did you learn before and after your first e-commerce site to make you comfortable building it?
Most systems developers write should have value to their clients (Otherwise there isn't much point in writing them.).
Some handle clients money, or 3rd-party money, but really all systems have value.
So be professional, write the best code you can, get it signed off by someone, and have the client sign it off.
Then get insurance.
If you're really worried, I would recommend implementing someone else ecommerce solution. Even if you don't need to write much code, they will still want you to template the site, import their data, etc.
Especially with something as sensitive like this, it's nice to know that you're using code that is in production on other sites, and is reviewed by security scanners and is PCI compliant etc. Plus, if other users of the software report bugs, and a patch is released, all you have to do is implement the patch.
If you hand-code an e-commerce solution the day you find a bug is the day all of the customers credit card numbers are stolen or someone manages to buy 5,000 ipods for $0.00 :( (or maybe a week later)
Having worked and built e-commerce systems for a few years I have these suggestions for you:
Store high-resolution transactional data (orders for instance) with complete details about everything (shipping fees, payment fees, vat etc). Make sure that it's easy to verify what you expect to receive in actual money, and what you actually got.
Don't handle any card-data yourself if you don't have to. In order to dodge PCI-compliance needs, never let card-data pass through your system. There are several PSPs that have a good redirect flow in their hosted solutions. Preferrably, choose one that let you "prepare" the paymentprocess server<->server, and redirect customer using a transaction-id. Avoid PSPs that need you to prepare and post a form directly to their servers (that is a lousy way of handling redirects IMO).
IF you build a server-based solution, atleast make sure that you dont STORE card-data, merely let it run through your server during transaction. Most PSPs will give you a transactionID that you can use for any further followups (settlement, reversal, refunds etc).
Always rely on a secure response from your PSP that the transaction went through, they will provide such a feature.