Punchout

In simple terms, a punchout solution lets your client log in to your webshop from a thirdparty solution, place products in the shopping cart, and then transfer the contents of the cart back to their solution.
Later on somebody makes a purchase order out of the transferred products and an electronic order is imported to your shop.

Login

We support several different implementations; the most popular being based on OCI (Open Catalog Interface) and cXML.
You should contact us for the exact URL to the punchout login handler, but it will look approximately like this: https://www.YOURSITE.com/ocilogin.ashx
It is not a website, but a login handler that requires at least three parameters: username, password, hook_url
Usernames/passwords are standard logins that you have created for your users in the webshop, while hook_url should automatically be filled in by the client purchasing solution when everything is set up correctly.
The login handler works with both GET and POST, so for testing you may create a simple URL with valid username and password and a fake hook_url just to test the login (the cart will be sent nowhere, in that case).
Like this: https://www.YOURSITE.com/ocilogin.ashx?username=TESTUSER&password=123&hook_url=fakeURL
We don't recommend putting the password in cleartext in the URL in production.

Customizations

We do support customizations. In such cases the URL will most likely change to something like https://www.YOURSITE.com/ocilogin.ashx/ENDCUSTOMER . 
Typical customizations are for instance to include or exclude sales tax or return additional values from the shopping cart, such as freight.

Orders

Again, the formats vary, but xCBL 3.5/4.0 seems to be popular (or cXML if that is used for login).
We will give you the exact URL, but it will be similar to this: https://secure.webmercs.com/ibxwebservice/YOURSITE/ibxorder.ashx (It requires a valid order to be POSTed.)
We use SOAP for xCBL.

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://www.w3.org/2003/05/soap-envelope" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:SOAP-ENC="http://www.w3.org/2003/05/soap-encoding">
  <SOAP-ENV:Header>
    <nseps:endpoints xmlns:nseps="urn:schemas-IBX:/docs/endpoint.nsendpoint" SOAP-ENV:mustUnderstand="true">
      <nseps:to>
        <nseps:address></nseps:address>
      </nseps:to>
      <nseps:from>
        <nseps:address>TPID</nseps:address>
      </nseps:from>
    </nseps:endpoints>

In your solution, you create a user email in the following format (added to the correct customer, of course): TPID@ibx-wmx.com
You can set the TPID to anything you like. Orders from purchasing portals (where this solution is used today) normally use a GUID value, like 12bcd1dc-33e1-9000-a2ab-b1a873450102
(which would result in a user email = 12bcd1dc-33e1-9000-a2ab-b1a873450102@ibx-wmx.com), but you can use anything you want. 

The email address is fake and not used for anything - except internally by us to place the order on the correct customer. It doesn't need a password, and it should never be shared with anybody.

Keep in mind:
1) The TPID must match a user email in your system
2) The billing/shipping addresses must be valid
3) The products must exist in the solution

Value from OrderHeader/OrderParty/BuyerParty/Party/ListOfIdentifier/Identifier/Ident may be used in some cases.

Not punchout but "Catalog"?

We support that as well. In that case the customer doesn't go to your site, but receives a product catalog that he imports into his own solution. Sometimes the customer will approve every import, while other times there's automatic upload.
We need to know the format, filename, where it should be uploaded to / credentials, whether it is automatic upload or not, and maybe some other things. The catalog can also be customized.