Is your feature request related to a problem? Please describe.
UCP already defines a standard way to apply discounts during Cart and Checkout. A Platform can submit a Business-recognized discount code, and the Business remains authoritative for validation, stacking, allocations, messages, and totals. Related work in #346, #609, and #707 is addressing Business-to-Platform discovery of promotions.
A complementary flow is still missing: a Platform may want to fund an incentive and have the Business issue and honor it. UCP does not currently define a standard way for the Platform to request issuance, apply the resulting discount through the existing Cart / Checkout flow, preserve funding attribution on the resulting Order, and reimburse the Business for the amount actually applied.
This capability would benefit all three participants:
- Buyers receive a lower price.
- Businesses can drive incremental orders and reduce effective acquisition costs without funding the entire discount.
- Platforms can invest in incentives when the expected conversion, transaction, or ecosystem value exceeds the subsidy cost.
Without a shared contract, each Platform-Business integration must build bilateral issuance APIs and custom logic for funding attribution, reimbursement, and refund adjustments. That recreates the N×M integration problem UCP is designed to reduce.
Describe the solution you'd like
Define an optional, negotiated flow for platform-funded discounts that composes with the existing Discount, Cart / Checkout, and Order models. At a high level:
- Capability negotiation. The Business advertises whether it supports Platform-initiated discount issuance and reimbursement.
- Issuance. When a buyer or session qualifies, the Platform asks the Business to create a discount within the Business's supported constraints and supplies a durable funding reference or commitment. The Business accepts or rejects the request and, if accepted, returns a Business-scoped identifier or code.
- Application. The Platform passes that identifier or code through the existing Cart / Checkout flow. The Business remains authoritative for eligibility, stacking, application, and totals.
- Order record. The completed Order records the Platform-funded discount, the amount actually applied, and the funding reference.
- Reimbursement and reconciliation. The amount actually applied, net of cancellations, returns, and refunds, becomes the reimbursement basis. Funds may move over an agreed external rail; UCP standardizes the durable references, net amount, status, and reconciliation outcome.
The goal is to standardize the cross-party lifecycle and accounting evidence, not to prescribe targeting logic, the Business's internal coupon implementation, or a particular movement-of-funds rail.
Describe alternatives you've considered
- Issue ordinary Business discount codes out of band. This works for a bilateral integration, but every Business still needs a custom issuance API and reimbursement process.
- Add only a funding field to
discounts.applied. That can identify who funded an applied discount, but it does not cover issuance, funding authorization, or reimbursement.
- Use Order
adjustments. Adjustments can capture post-order refunds, returns, or credits and may change the reimbursement basis, but they do not identify or settle the Platform's funding obligation.
- Treat the subsidy as a Payment or Split Payments contribution. Those capabilities describe how the buyer satisfies the Checkout total. Reimbursing the Business for a Platform-funded incentive is a separate commercial obligation.
Additional context
This request complements #346, #609, and #707. Those efforts address promotions a Business exposes to a Platform; this request covers a Platform-funded discount that the Business issues, applies, and later reconciles. It is also distinct from #641, which concerns settlement of the buyer's payment rather than reimbursement for a Platform-funded incentive.
Feedback Requested
CONTRIBUTING.md recommends that new capabilities begin in a vendor-specific namespace and demonstrate adoption before being considered for UCP core. We can follow that path. We would appreciate guidance from the maintainers and the appropriate Technical Council on whether the most useful next step is a detailed Enhancement Proposal covering capability boundaries, the interaction flow, the data model, and reimbursement and reconciliation semantics, or a vendor-namespaced prototype with implementation evidence.
Code of Conduct
Is your feature request related to a problem? Please describe.
UCP already defines a standard way to apply discounts during Cart and Checkout. A Platform can submit a Business-recognized discount code, and the Business remains authoritative for validation, stacking, allocations, messages, and totals. Related work in #346, #609, and #707 is addressing Business-to-Platform discovery of promotions.
A complementary flow is still missing: a Platform may want to fund an incentive and have the Business issue and honor it. UCP does not currently define a standard way for the Platform to request issuance, apply the resulting discount through the existing Cart / Checkout flow, preserve funding attribution on the resulting Order, and reimburse the Business for the amount actually applied.
This capability would benefit all three participants:
Without a shared contract, each Platform-Business integration must build bilateral issuance APIs and custom logic for funding attribution, reimbursement, and refund adjustments. That recreates the N×M integration problem UCP is designed to reduce.
Describe the solution you'd like
Define an optional, negotiated flow for platform-funded discounts that composes with the existing Discount, Cart / Checkout, and Order models. At a high level:
The goal is to standardize the cross-party lifecycle and accounting evidence, not to prescribe targeting logic, the Business's internal coupon implementation, or a particular movement-of-funds rail.
Describe alternatives you've considered
discounts.applied. That can identify who funded an applied discount, but it does not cover issuance, funding authorization, or reimbursement.adjustments. Adjustments can capture post-order refunds, returns, or credits and may change the reimbursement basis, but they do not identify or settle the Platform's funding obligation.Additional context
This request complements #346, #609, and #707. Those efforts address promotions a Business exposes to a Platform; this request covers a Platform-funded discount that the Business issues, applies, and later reconciles. It is also distinct from #641, which concerns settlement of the buyer's payment rather than reimbursement for a Platform-funded incentive.
Feedback Requested
CONTRIBUTING.md recommends that new capabilities begin in a vendor-specific namespace and demonstrate adoption before being considered for UCP core. We can follow that path. We would appreciate guidance from the maintainers and the appropriate Technical Council on whether the most useful next step is a detailed Enhancement Proposal covering capability boundaries, the interaction flow, the data model, and reimbursement and reconciliation semantics, or a vendor-namespaced prototype with implementation evidence.
Code of Conduct