PunchOut Catalog Requirements for Suppliers Explained

The PunchOut Supplier Checklist at a Glance

Use this as your go-to list. Work down it before you commit to a buyer, and hand the technical half to your developers or your platform.

Non-technical requirements

• An online catalog of the buyer’s approved products
• Clean product data: title, description, image, supplier part number
• Customer-specific (contract) pricing shown at login
• Units of measure, tax and shipping rules set correctly
• A named technical contact for testing and go-live

Technical requirements

• Support for the buyer’s standard, cXML or OCI
• The three-message flow: Setup Request, Setup Response, Order Message
• Shared secret and identity credentials exchanged
• Return URLs and endpoints configured
• Secure, frame-safe HTTPS hosting
• Test endpoint validated before switching to production

Before you commit, ask your buyer

• Which procurement platform do you use?
• cXML or OCI?
• Can you share your test endpoint?
• Who is your technical contact for testing?

What Is a PunchOut Catalog, and What Does It Require From a Supplier

A PunchOut catalog is an online catalog that connects to your customer’s buying system. The buyer starts in their own procurement software, clicks your catalog, and is sent to your online store to shop. When they are done, their cart is sent back into their system for approval and a Purchase Order (PO). They never leave their workflow, and you never rekey their order.

To make that work, you have to meet a set of requirements on your side. Some are about your business and your catalog. Some are about the technical connection between your store and their system. The connection usually runs on one of two standards: cXML (Commerce eXtensible Markup Language) or OCI (Open Catalog Interface).

The rest of this checklist splits those requirements into the two halves, so you know which ones your sales team handles and which ones need a technical hand.

Non-Technical vs Technical PunchOut Requirements: What’s the Difference

The non-technical requirements are the ones your business already understands. What you sell, at what price, to whom. These are about getting your catalog and commercial terms ready.

The technical requirements are the connection itself. The data format, the credentials and the testing that let two systems talk safely.

Here is the useful part. If you use a PunchOut platform, most of the technical half is handled for you. Your job becomes getting the business half right, which is work only you can do. So do not let the technical words scare you off. Read both lists, then decide how much you want to hand to a platform.

What are the Non-Technical PunchOut requirements for Suppliers?

Start here, because this is the work that is yours no matter how you build the connection.

An online catalog of approved products

The buyer needs to shop a specific list, often the products tied to their contract. You need those products in a catalog, organized so they are easy to search.

Clean product data

Each item needs a clear title, a description, an image and a supplier part number. Thin or messy data is the most common reason buyers reject a catalog. Good data is what makes the catalog usable.

Customer-specific pricing

PunchOut buyers almost always shop at a negotiated contract price, not your list price. You need to show the right price to the right customer when they log in.

Units of measure and tax rules

The buyer’s system expects each item to carry a Unit of Measure (UOM), such as each, box or case. Tax and shipping rules need to be right too, because a mismatch here stalls the order later.

A named technical contact

Even if a platform does the setup, the buyer’s procurement team will want one person on your side to coordinate testing and go-live. Name that person early.

Get these five right and you have done the part that matters most, because no technical connection can fix a catalog with the wrong prices or missing data.

What are the Technical PunchOut requirements for Suppliers?

These are the PunchOut catalog implementation requirements that make the connection work. If you use a platform, it handles most of them. If you build in-house, your developers own this list.

Support for cXML or OCI

Your store has to speak the buyer’s language. Most procurement systems use cXML. Some, like older SAP setups, use OCI. Confirm which one your buyer needs before anything else.

The PunchOut message flow

A cXML PunchOut runs on three messages. The PunchOut Setup Request, when the buyer clicks in. The Setup Response, when your store sends back the URL to start shopping. And the PunchOut Order Message, when the finished cart is sent back to their system. Your store has to handle all three.

Shared secret and credentials

The buyer’s system and yours confirm each other with a shared secret and identity details, so no one else can reach the catalog. You exchange these during setup.

Return URLs and endpoints

You need to configure where the buyer lands when they punch in, and where the cart is sent when they check out. A wrong endpoint is one of the most common setup errors.

Secure, frame-safe hosting

The connection runs over HTTPS with encryption. Your store also has to work inside a frame in the buyer’s system, so it cannot contain code that breaks out of frames.

Test and production endpoints

You test the whole flow against the buyer’s test system first, then switch to production. Skipping a clean test is how go-lives slip.

Do PunchOut Requirements Change by Procurement Platform?

Yes, and this catches suppliers out. The core idea is the same everywhere, but each platform asks for its own details.

SAP Ariba, Coupa, Oracle, JAGGAER and Workday each have their own setup fields, their own way of exchanging credentials, and small differences in what they expect in the cXML. A catalog built and tested for one buyer does not automatically pass for the next. This is why suppliers who win several enterprise accounts often move to a platform that can manage many buyer connections from one place, rather than rebuilding each time.

If your buyer names their platform, that tells you most of what you need. VARStreet has per-platform setup guidance for SAP, Coupa and others, which maps the exact requirements for each.

How Long Does PunchOut Implementation Take, and What Delays It?

A straightforward PunchOut can go live in a few days to a few weeks. The variable is not the technology. It is how ready your catalog is and how quickly both sides test.

Most delays come from small, avoidable mismatches. A wrong return endpoint. A shared secret typed incorrectly. A test cart that fails because the product data does not line up. A price that shows list instead of contract. None of these are hard to fix, but each one means another round of testing with the buyer’s team, and each round adds days.

The suppliers who move fastest are the ones who have their catalog and contract pricing clean before setup starts, and who name a single point of contact for testing.

Do You Need Developers to Meet PunchOut Requirements?

You have two honest paths.

You can build it in-house. That means developers who know cXML or OCI, who set up the message flow, the credentials and the hosting, and who maintain it as buyers change their requirements. This works if you have that skill on staff and only a buyer or two to support.

Or you can use a PunchOut platform. The platform provides the connection, the hosting and the testing support, and you focus on the catalog and pricing. This is the common path for suppliers who do not have in-house cXML skills, or who need to support several buyers without rebuilding each time.

Neither is wrong. The right choice depends on how many buyers you serve and whether you have the technical staff to maintain the connections yourself.

How VARStreet Helps Suppliers Meet PunchOut Requirements

If you choose the platform path, here is where VARStreet fits. It is built to take the technical half of the checklist off your plate, so you handle the catalog and let the platform handle the connection.

You do not need an existing website. If a customer requires PunchOut and you have no online store, VARStreet gives you a hosted, PunchOut-ready aggregated catalog that meets the buyer’s requirements. If you already have a catalog, VARStreet can extend PunchOut to it without a full rebuild.

You can serve many buyers from one place. When several customers require PunchOut, VARStreet lets you manage customer-specific catalogs and connections from a single platform, with each buyer’s pricing and product list kept separate. That is what stops the “rebuild for every account” problem.

The team supports setup, testing and go-live. VARStreet coordinates the configuration and testing with your buyer’s procurement team, across platforms like SAP Ariba, Coupa, Oracle and JAGGAER, and has completed more than 250 PunchOut connections.

Our Product Manager puts it simply: “Suppliers think PunchOut is a technical problem. For most of them it is a catalog problem wearing a technical mask. Get the products and prices clean, and the connection is the easy part.”

The result is that meeting a PunchOut requirement stops being a developer project and becomes a catalog you keep current. You can book a demo to see how it works for your buyer’s platform.