I've added both Bitcoin and Stripe now, and can do invoicing and orders across both the Bitcoin Currency and CAD.
Read More + Comments
The process to get e-commerce in full was fairly big, and really required multiple things, so I thought I'd break it all down.
1. Inventory and Products
The basis of any sales is going to be Inventory and Products, without that you can't have sales. Lucky for me I only sell digital products and services at this time, so the Inventory stuff is a bit light, while the products is pretty full fledged. There is Warehouse, Products and Inventory tables, in order to track the Items, where they are and the information about the locations. It's pretty simple, but the basics are there.
Since I deal in digital products exclusively, I don't need to worry about Warehouse or Inventory, I just create things on demand, so it could use some more maturity to become a full fledged product, but for now it works for me. I've set up the ground-work to extends it into a full featured product soon.
2. Bitcoin Integrations
Bitcoin is integrated with BitcoinJ, a wonderful library for integrating bitcoin into your Java applications. In it's current integration a wallet is created for each organization. Bitcoin isn't supported as a native currency, however it is supported via a conversion mechanism @ bitcoin charts Api. The server polls Bitcoin charts every ten minutes or so, get's the updated BTC prices, and then uses it to do the conversion from CAD->BTC. Every transaction receives a unique wallet address, and payments that are made to that address get reflected against the users Cart. The Bitcoin price quote is persisted with the order and is good for the limited lifespan of the cart.
There is a special integration for QR Codes, Bitcoin QR is simple, you just define a bitcoin:// payment URI that has the wallet address and amount, e.g. bitcoin://kdfajs43l23UIDS?amount=0.1
On android it is able to follow that URI scheme and launch the wallet application, or be read by the camera of the wallet application. This means that payment integrations on android are very simple, easier and more secure then traditional money. In fact, you can use this mechanism to accept anonymous payments online.
3. SSL Integration
I wanted real money integration so bad, but the initial design was http only. Https has overhead, not so much performance, but certificate overhead. Each domain needs a certificate, You can use Server Alternate Names and Wildcard domains to expand on it, but it still requires you to verify ownership of every domain. Additionally, I wasn't that experienced with SSL in the past, I was slow to get started, and I didn't want to put real money integration until I had a green bar.
The path I took to resolve these issues started with StartSSL. With StartSSL the domain verifications are free, you just need to use the automated system. I only needed to be verified once as a person, a process that took less then a day and cost about $60, and now I had certificates. However, going along this path didn't turn out ideal. Once of my original requirements was that I support any and all domains pointed at the server. WHile this is still true, there are limits to the Cert I can deliver. Java and Jetty have limitations that make it difficult for me to rotate through keys in the keychain, so it just chooses the first. I had to make the trade/off acceptance that I would have to lock in a certificate and accept that SSL will only work on those domains that can be predefined (wild cards allowed however). So I decided to make everything on my main server @ *.metalrain.ca. Even now you can go and view this page over SSL at https://adamhammer.metalrain.ca
In the future I might generate a more versatile certificate that gives SSL access on not just the root domain, but on www.adamhammer.ca, etc. It will work as is, but you will get the unverified warnings from the incorrect signing.
For large clients that require SSL, they'll likely bring their own certs to the table, and luckily the future of Java does hold solutions to these limitations, and I might be able to even get by them nowadays with some work. Mostly it comes down to Server Name Indication (SNI) support, the ability for the client to tell the server early on the domain, so a certificate can be chosen from the store.
For now though, SSL is done and in there, it's secure and verified and I can't praise StartSSL enough. However, they have been a bit slow to generate a test-domain cert that I wish to include with the platform. I purhased simpletest.ca, which I use for internal testing and I want others to as well. I never plan to put anything on that domain, however I do want people to have a working out of the box ssl setup for developers. Things like Payments, even in test mode, will not work over HTTP, it will lock the user out from doing those insecure things.
4. Stripe Integration
I don't want to go over why I didn't choose other payment providers, in the future I may add additional providers. I avoided paypal howe due to their politics. I feel they put to much risk on small and digital startups, often putting unreasonable holds and being poor communicators about it, so I chose to actively avoid them. The rest of the players I'm overall neutral to.
In the future I might integrate Square POS as well, since that's a very convenient in-person channel.
5. Messaging Improvements
The Messaging system needed some improvements. Well, it still does, but the current incarnation lets me do somethign cool. It'll send push notifications, so the clients can stay up to date and have realtime communications with their customers. For example, if you place a order on www.simpleplatform.ca, it'll create a cart and send me a message, and I'll be able to then respond, which will automatically create a user, notify the purchaser, and allow two way realtime communication between the purchaser and me, while having full accountability in the system about the order.
Once ready, invoices can be sent with https to the client using the Orders UID, and payments can be directly made via bitcoin or credit direct the invoice.
Overall I am happy with this iteration. I wouldn't call it release ready for the general public yet, but it's definitely becoming the full featured platform I want. I hope to bring it to the public soon.