Most punchout conversations start with a network: Ariba's business network, Coupa's supplier portal, Jaggaer's enablement team. Oracle is the exception that clarifies the rule. In Oracle Fusion Procurement (and its predecessor iProcurement before it), punchout is a direct arrangement between the buyer's Oracle instance and your catalog site. No central network sits in the middle, no network account is created, and nobody charges you for the privilege of receiving orders.
No network means bilateral everything
The architecture sounds simpler, and in one sense it is: fewer parties, no network fees, no separate registration process. But it moves all coordination to one place, the buyer's Oracle administrator. They configure your punchout catalog in their instance: your URL, your credentials, the protocol dialect, and the category mapping that routes your items into their requisition flows. There is no network-side validation step to catch a broken configuration before a user does. Whatever gets set up wrong surfaces as a failed punchout attempt on a real requisition screen.
For suppliers this cuts both ways. Enablement can be fast, because you only wait on one team's calendar, with none of the trading-relationship ceremony that stretches an Ariba project across a quarter. It can also stall completely if the buyer's Oracle team is busy, because there is no self-service path around them the way there is with Coupa. The practical playbook: deliver a complete configuration sheet on day one (URL, identities, shared secret, test credentials, sample documents), so their admin can configure everything in a single sitting.
Native XML or cXML, and the details that bite
Oracle Fusion supports punchout in Oracle's own native XML format and in cXML, the same document flow described in our punchout guide. For a supplier already speaking cXML, that is the sensible dialect to offer: setup request in, start page out, cart returned as a PunchOutOrderMessage, purchase orders delivered as OrderRequest documents to the same endpoint. Two details deserve attention in testing. First, transport security: Oracle instances are strict about TLS and certificate hygiene on the URLs they call, so your endpoint needs clean certificates and no redirect surprises. Second, category and unit data: requisitions in Oracle lean on category mappings, so UNSPSC codes and units of measure on your items need to be present and consistent before the first test, not patched afterwards.
What PunchRelay does for an Oracle connection
PunchRelay gives your Shopify store the punchout endpoint the buyer's Oracle admin configures against: credential validation, sessions opened on the Shopify B2B company location you assign, contract pricing straight from your B2B catalogs, quantity rules enforced before transfer, and the cart returned in the dialect their instance expects. Purchase orders sent as cXML OrderRequest come back to the same endpoint and become Shopify orders with an acknowledgment in under 150 ms.
Because Oracle connections are bilateral, per-buyer configuration matters more, not less: encoding choices, category mapping, correlation fields, and the UNSPSC and unit-of-measure data mapped from your Shopify products are all set per connection. And every request and response is logged raw, both directions, because in a direct integration the log is the only shared record both sides can look at. When the buyer's admin asks what your endpoint received at 14:02, you answer with the document, not a guess.
If a customer on Oracle Fusion Procurement just asked for your punchout URL, leave your email below. We will prepare the configuration sheet their admin needs and walk the first test with you.