1) Broadleaf is agnostic about the presentation layer. You can use whatever presentation layer approach you like as long as you can communicate with the Broadleaf Spring service layer. In addition, it's on our roadmap to finalize our webservice approach, which would expose other possibilities for communication...
2) Unfortunately, the current database schema and supporting code support a single store only. Building out the schema to support a "multi tenant" architecture is also on our feature roadmap.
3) The Broadleaf payment architecture allows for pretty much any time of payment (and in any combination per order
) given that there is a payment module to support the transaction. For example, from a CyberSource perspective, we have elaborated three types of payment represented in the CyberSourceMethodType enumeration (Credit Card, Bank Draft and PayPal). CyberSource support these (and likely more) through their API, but we have currently only built out support for credit card payment. Bank Draft and PayPal still need to be built out as Broadleaf payment services under the CyberSource payment module umbrella.
Google Checkout is definitely something we've thought about, but the requirements and payment flow are different enough that it will be a bit of a larger effort than the others. Still important, though.
As you can tell, there's still work to be done building out some of these integrations (payment, shipping, tax). We currently have functional support for CyberSource credit card payment, CyberSource tax calculation and USPS shipping pricing. We definitely anticipate tackling others, but at the moment, we're focusing all our effort on the 1.5 release and the completely re-done administrative platform.
If you're curious about upcoming releases and features, take a look at our high-level product roadmap at:
http://www.broadleafcommerce.org/jira/s ... dmap-panel