What about affiliates, referrals and discount codes distributors?

[PaoloNardini]

Hi, the UCP initiative is fantastic, but it's missing a key player in most e-commerce transactions: the referral or affiliate, who drives traffic to the e-commerce site and earns commissions on sales. You've included discount codes in the specifications, but you don't specify where the discount code comes from or how to identify the marketing and promotional channel that distributes it, because discount codes are often not distributed directly by the merchant, but through affiliate networks. I know this is a very controversial topic, as many believe affiliate marketing is doomed in the age of AI-driven commerce, but the entire industry could benefit from continuing to benefit from this promotional channel.

[zologic]

Good framing from @PaoloNardini — this is underspecified and the stakes are real.
We've been running UCPReady on a live WooCommerce store (40k+ SKUs, houseofparfum.nl) and recently shipped an addon called KeepCard.io that sits on top of UCP's checkout flow and extends it in a direction that touches exactly this problem.
The short version of what KeepCard does: instead of processing a return, the merchant offers the buyer a store credit instrument redeemable at checkout. That instrument is issued, tracked, and redeemed entirely through UCP's checkout flow — it surfaces as a payment_handler entry, the agent reads it, and applies it without any out-of-band voucher string.
That pattern — a value instrument issued by a third party, redeemable at checkout via a declared handler — is the same primitive an affiliate or referral network needs. The affiliate doesn't need a discount code string passed through a query parameter. It needs:

A way to declare a value instrument or discount entitlement in the checkout context
A handler identifier the agent can read and apply without guessing
An optional provenance field — where did this entitlement come from — that the merchant's system can reconcile against

The current spec has the discount extension and payment_handlers, but no provenance or issuance chain. An agent completing a checkout today has no way to know whether a discount was merchant-originated, affiliate-issued, or loyalty-earned — and no way to communicate that back to the merchant's attribution system.
What we'd propose as a minimal addition: an optional source object on discount line items and payment instruments:
json{
"discounts": [{
"amount": -500,
"code": "PARTNER20",
"source": {
"type": "affiliate",
"network": "awin",
"ref": "pub_12345"
}
}]
}
Ignorable by implementations that don't need it. Actionable by merchants and networks that do. No breaking change.
On the "affiliate marketing is doomed" question — we'd argue the opposite in an agent world. Agents need trusted, machine-readable sources of product recommendations. That's a new distribution surface, not a shrinking one. The question is whether the protocol exposes enough structure for attribution to survive the transaction.
Happy to share more detail on how KeepCard handles the instrument issuance side if useful for the spec discussion.

[PaoloNardini]

Very interesting, thank you for sharing.