# Test punchout

Run a real OCI, cXML or IDS Connect punchout against your own shop from the portal and see what a buyer system would have received.

URL: https://punchout.dev/docs/getting-started/test-punchout/

This page explains the portal's test punchout: a punchout round trip through your shop in which the portal plays the buyer system.

## What a test punchout is

A test punchout starts your shop the way a buyer system would. The only difference is where the cart goes at the end: to punchout.dev at `api.punchout.dev` instead of to a procurement system. The tag, the panel, the cart reading and the transfer are the ones a real buyer uses, so a passing test proves the whole round trip.

Start it in the **Test punchout** step on the shop's **Setup** tab, or with the **Test punchout** tile on the dashboard. Owners and admins can start a test, and viewers can read the results.

## The three protocols

| Protocol | What the portal does |
| --- | --- |
| **OCI (SAP)** | Opens your shop the way an SAP system does, at the first allowed origin and the landing path |
| **cXML (Ariba, Coupa)** | Starts the punchout the way Ariba or Coupa does, at the shop's cXML launch URL, and opens the start page it gets back |
| **IDS Connect (craftsman software)** | Starts the punchout the way craftsman software does, at the shop's IDS Connect launch URL, and opens the shop |

While a cXML or IDS Connect test runs, the shop's **Buyers** list shows a temporary entry "Test-Punchout (temporär)". It does not count as a connection and is removed after the test.

A test punchout never signs in through auto-login.

## Run a test

1. Pick the **Protocol** and click **Start the test**.
2. The portal opens your shop in a new tab. If a popup blocker stops it, click **Open the shop tab**.
3. The punchout panel appears in the shop. Put a few products in the cart and open the cart page. The panel reads the cart and lists the items.
4. Check the items and click **Transfer to procurement system**. The panel names the destination: `api.punchout.dev`.
5. The browser shows a page "Transfer received" with "The test punchout was transferred", the number of line items and a link back to the portal ("Zurück zum Portal").
6. The portal tab shows the result. Until then it says "Waiting for the transfer from the shop" and checks every 5 seconds.

To test the cancel path instead, click **Back to procurement system** in the panel and confirm with **Yes, go back**. The test accepts this empty return as well.

## Validity

| Fact | Value |
| --- | --- |
| Valid for | 60 minutes from the start |
| Uses | One. The first transfer that arrives wins; a repeat gets "This test link is no longer valid." |
| Expired | The portal shows "The test has expired." Start a new one |
| Result kept | 30 days after it arrived |

The instant tag on the landing page creates this kind of test too, always with OCI and valid for 60 minutes.

## What the result shows

The portal shows "Transfer received" with the number of items and the time, then a table with **Description**, **Quantity**, **Unit**, **Price**, **Currency** and **Part number**, and the **Total**. **Raw fields of the transfer** opens the transfer as it arrived: the **Kind of transfer**, the number of fields and every field per item.

The **Kind of transfer** names the protocol and says whether items arrived. A test of the cancel path shows as a return or message without items. "unreadable" means that punchout.dev could not read what arrived.

## What to check

- Every product in the cart arrived, once, with the right quantity.
- Descriptions and part numbers are the ones your shop shows. The part number is the shop's article number.
- Prices are net or gross, as your buyers expect. If the cart shows prices with VAT and buyers need net prices, set **Price quality** to the option that strips VAT, enter the **VAT rate** on the **General** tab and test again.
- Currency and unit match what the buyer system expects (**Currency** and **Unit of measure** on the **General** tab).
- The cancel path returns cleanly.

## When the test cannot start

| Message | Cause | Fix |
| --- | --- | --- |
| "The test receiver is not on the list of allowed return hosts." | The shop restricts **Allowed return hosts** | Add `api.punchout.dev` under **General** → **Allowed return hosts** |
| "This shop is inactive." | **Shop active** is off | Turn it on under **General** |
| "This shop's sandbox has ended." | The Sandbox period of the shop is over | Choose a paid plan. See [Plans and Sandbox](https://punchout.dev/docs/account/plans-and-sandbox/) |
| "The cXML test could not be started." or "The IDS Connect test could not be started." | The launch was refused or did not answer | Try again later |

The test punchout returns its cart to `https://api.punchout.dev`, and punchout.dev checks it against **Allowed return hosts** like any buyer system. A shop that restricts that list must include `api.punchout.dev` while it uses the test punchout. A shop that sends a Content Security Policy must allow `https://api.punchout.dev` in `form-action` for as long. Once `api.punchout.dev` is on the list, the **Embed** tab's `form-action` line includes it ([Install the tag](https://punchout.dev/docs/getting-started/install-the-tag/)).

## How it counts

- A received test completes the checklist step **Test punchout** for 30 days.
- The Sandbox allows test punchouts. A real buyer's launch is refused there, a test is not.
- A test transfer shows in the shop's **Transfers** on the **Usage** tab. It is counted separately as a test and never against your plan's monthly transfer allowance.
- Reading the cart during a test uses the shop's daily budget like any punchout.
- On the **Usage** tab, a running test session carries the badge **Test**.

Next: [Connect a buyer](https://punchout.dev/docs/getting-started/connect-a-buyer/).