[Feat]: Catalog items with no public price ("price on request")

[evoleinik]

Is your feature request related to a problem? Please describe.

UCP catalog requires a price on every item. product.price_range and variant.price are required, price.amount says "Use 0 for free items", and REST conformance requires "valid Price objects".

Many B2B sellers publish a catalog but no prices. The price depends on the contract, the volume or an NDA, and the buyer gets it from a quote. @juanferrub's B2B note in #812 names contracts and volume tiers among the inputs.

We (AirShelf) built UCP endpoints for two such sellers. One leases office equipment on quoted terms. The other sells security software and shares prices only under NDA. Between them they list 318 products, and none has a price we could send. Each option we had breaks something:

1. Send amount: 0 with a disclosure warning. It is schema-valid, but 0 means free. A platform that skips messages shows "$0.00" on a leased printer.
2. Omit price and send a disclosure warning. It is honest, and it is what we built. It fails the schema, and @ucp-js/sdk 0.5.1 rejects any response with an unpriced variant.
3. Skip catalog and offer only ask. It conforms, but catalog-first platforms cannot list the products at all.

Nearby work covers other steps. Identity linking lets a signed-in buyer see member pricing, and we use it for buyers who sign the NDA, but public discovery still has no price. #845 and #812 cover terms once a quote exists, and this gap is one step earlier, at listing. #810 keeps price required on each offer.

Price has been required since the first catalog PR (#55), which modelled a single seller's DTC catalog. B2B implementers so far add RFQ as vendor extensions, such as Shopware's com.shopware.quote and UCPReady's com.ucpready.procurement (#93). Both add a quote flow. Neither can remove the price requirement from the listing, for the reason below.

Describe the solution you'd like

A structured way for a Business to say "no public price for this item", so a Platform never has to read it from prose. One possible shape:

• variant.price and product.price_range become optional only when the variant says why, for example "pricing": "on_request".
• A Platform MUST NOT show a price for such a variant, and MUST NOT treat the missing price as 0.
• Price filters exclude such variants.
• The price reaches the buyer through identity linking or a quote ([Proposal]: Accepted commercial term handoff into UCP Cart/Checkout #845), never through catalog.

A well-known message code such as price_on_request with presentation: "disclosure" could carry the wording a Platform shows the buyer.

Describe alternatives you've considered

The three options above. A vendor extension cannot fix this, because an extension composes with allOf and can add a field but cannot relax a required one. So every B2B seller hits the same wall until core allows it.

Additional context

Happy to share our implementation and the responses it sends.

Code of Conduct

• I agree to follow this project's Code of Conduct

[juanferrub]

Hi @evoleinik - thanks for mentioning us.

I totally agree that this is an important and currently uncovered B2B scenario for UCP.

Requiring every catalog variant to expose a numeric price creates a false choice for businesses whose pricing depends on contracts, buyer identity, volume, rental terms, or an RFQ process.

I think using amount: 0 is misleading, and omitting price makes the catalog non-conformant. This should be addressed through a core, versioned pricing-state model.

I'm sharing some ideas below as well for your reference and to enrich the conversation

A catalog variant should be able to declare a structured pricing mode, for example:

{
  "pricing": {
    "mode": "quote_required",
    "reason": "contract_or_volume_dependent",
    "next_step": "request_quote"
  }
}

Possible modes could include:

• public — a numeric price is supplied and is required.
• buyer_specific — pricing becomes available after identity linking or buyer-context resolution.
• quote_required — the supplier must form the price through an RFQ or quote flow.
• contract_only — pricing is available only to an existing contractual customer.

The schema rules would then be:

• price is required when pricing.mode is public.
• price is omitted when the mode is non-public.
• Missing price never means zero.
• Platforms must not display or infer a numeric price for non-publicly-priced variants.
• Price filters, sorting, and comparisons must exclude those variants.
• product.price_range is present only when it is meaningful across the included variants.
• A structured code such as price_on_request may support presentation, but the semantic state should live in the catalog schema itself.

This keeps the stages separate:

1. The catalog makes the product discoverable.
2. Identity linking may resolve buyer-specific pricing.
3. RFQ or quote formation establishes dynamic commercial terms.
4. Accepted terms can then be handed into UCP Cart/Checkout through the commercial-term handoff semantics being discussed in [Proposal]: Accepted commercial term handoff into UCP Cart/Checkout #845.

This would allow UCP to support B2B discovery without pretending that every B2B product behaves like a fixed-price DTC item. It also keeps the change compatible with the broader work on quotes, accepted commercial terms, and procurement flows, while avoiding the misleading $0.00 fallback.

Thoughts?
Cheers!
Juan