Hi Brian,

Right now the Store is setup with two payment providers: PayPal and Authorize.Net.  The Store requires the admin to select one of these options.  I would like to see this handled differently.  For instance, not every person with an Authorize.Net account can accept Discover or Amex.  You have to add this separately.  Also, if you select Authorize.Net you will not be able to accept payments via PayPal.  I would like to see this setup so that you define payment options(Visa, MC, Amex, Disc, PayPal, Check, Fax, Phone, PO, Account, etc.) then define how each of these options are processed. 

I am also aware that some people would like to see a simple email order notification with the order details.  Personally, I do not like the idea of storing credit card information and I really don't like the idea of sending credit card information via email.  This is something I am working through now and will address with the next release.

Thanks,

Will

I think the email notification with order details could mean simply email the order without payment. This is a common B2B (business to business) scenario where an invoice is issued after the order is shipped. Payment terms might be Due Upon Receipt, 2% Net 10, or Net 30 Days as specified by the company.

Another example of a simple invoice provider may require a Purchase Order number for the order to be processed.

The email notification may be as simple as an order number (the company can look up the order in the store website) or a complicated as an XML attachment that contains the order header and order details.

I agree that credit card information must never be emailed and encrypted if stored, but you can only use the Credit Card Verification (CCV) during payment processing - you may never store or transmit the CCV number. Depending on your payment provider, this is usually handled by a Pre Auth with the CCV and a Post Auth by reference number to complete the transaction. You can always store transaction reference numbers.

In my experience this is where the differences between payment providers becomes difficult to implement.

Then there are tax providers. Note that there are over 6200 tax combinations in the US, PST, GST and HST in Canada, and VAT in the UK. Shipping charges may or may not be taxable, etc. etc. I think the tax provider should be implemented as simply as possible (GetTax(source zip, destination zip, subtotal, shipping) to allow customization as required by the store owner. Even external code could be evaluated at runtime to prevent having to recompile the appplication. 

The next best thing would be SOA (Service Oriented Architecture) or web service that calculates the shipping or tax charges in real time as required.This "fill in the blanks" mechanism could be used for many scenarios that we haven't come up with yet.

It would be very interesting if we could post a survey about item pricing, tax charges, shipping costs, payment providers, order processing, and other related issues.  I suspect most small businesses really don't need the complexities that most ecommerce applications offer.

KISS. Keep It Super Simple.

(Anything to help get the next release available).