Improving on the existing API by allowing API calls to process orders securely would open up a lot of possibilities for merchants. Here are a few advantages that I can think of:

- Custom order forms/interfaces can be created and controlled by merchant's developers, in unique and creative ways that more suit a client's specific sales process needs.

- Because the order form could be developed in the client's web application language of choice (PHP, Rails, etc), order processing can be more easily integrated directly with other applications that might be dependent on billing such as content management systems, forums, membership software, etc, etc. (limitless possibilities really).

- And of course, order forms can be hosted on the merchant's domain!

Thanks much for consideration!

It would be most useful if you can tell us what some of the possible values of certain field can be eg statuses so we can code to catch exceptions and know what else to look out for as orders come in.

Your sample codes are excellent and is a great base to build upon. I've since built (c#) entities (entity graph) to match up to your xml responses, but it would be great if you can document the possible nodes that may or may not appear during difference circumstances. eg if an order is recurring or has taxes if won't know what's in their sub nodes until an order with those comes through.

I'm happy to share the entities on your site to allow others or yourselves to improve upon so we can all get better and robust codes. A mechanism to alert us of any changes to the xml response would also be most helpful.

What does everyone else think of these?

Using your API, I can get both a list of all product IDs, and separately, all the attributes of a single product given the product ID.

In order to integrate with our CMS and have the CMS auto-create nodes based on the products we have for sale, we need an XML result that has every product's details.

Is it possible to get a result like this?

For instance, a call like:

https://www.mcssl.com/API/70223/Products/ALL?key=MY_SECRET_KEY_CODE

With the product ID being a "show all" kind of command, so that the XML tree has a node for every product, and with each node, all the details the Product/READ method returns on one page, like this:

Response
- Products
- - ProductInfo*
- - - Id = 9207622
- - - ProductPrice = 120.00
- - - ProductName = My Book
- - - ETC (all other attributes of this product)
- - ProductInfo*
- - - Id = 9207623
- - - ProductPrice = 400.00
- - - ProductName = My Sculpture
- - - etc...

Running hundreds of API requests just to get a complete listing usually kills our page with timeouts, and must no-doubt be hurting your own servers as well (think DDoS by accident).

When I check "Use Sale Price" on a product, any website grabbing ProductInfo details via the API on that product has no way of knowing if that sale is still active or not, based on the Date Effective Range I set.

The only bits of info we can glean from the API results regarding a Sale Prices are:

(when it is NOT checked)

<UseSalePrice>false</UseSalePrice>
<SalePrice/>

(when it IS checked)

<UseSalePrice>true</UseSalePrice>
<SalePrice>10.00</SalePrice>

(when it IS checked but the "End Date" has passed):

<UseSalePrice>true</UseSalePrice>
<SalePrice>10.00</SalePrice>

As you can see, no difference on the last two.

I propose changing the value of <UseSalePrice/> to FALSE if either

A) "Enable Sale Price" is unchecked -OR-
B) "Enable Sale Price" is checked, but the sale has passed the "End Date."

This is how your checkout behaves - it knows that a sale is passed - without us having to manually UNcheck the "Enable Sales Price" box.

The API needs to be able to signal and reflect this as well.