Rebuild EPPromoCodeInput on a named cart-adjustment operation

[field123]

Parent

#553 — Spec: one session for Elastic Path identity

What to build

A working promo code field. It has none today: one of its two code paths posts to an endpoint the
package never served, and the other writes the discount from the browser on a public credential —
so a shopper could in principle set their own discount.

The replacement is safe by construction. The shopper supplies a code; Elastic Path decides
what that code is worth. The merchant's money is never a number the browser sends.

Spec story 26.

Acceptance criteria

• A shopper enters a valid promo code and sees the discount Elastic Path computed for it applied to their basket.
• A shopper entering an invalid or expired code is told, and the basket is unchanged.
• No request originating in the browser states a discount amount — only a code.
• The component works with no route mounted beyond the standard one; the old server-routes switch is not required and is not the mechanism.
• The feature is demonstrably working end to end, since neither existing code path does anything today.

Blocked by

• Add the six new named ep.* functions and the missing dispatch entries #532 — Add the six new named ep.* functions and the missing dispatch entries

The tracker's dependency graph on this issue is authoritative; this list mirrors it.

---

Below is the original ticket, kept intact — it carries the research and decisions from #486, #495, #523 and #524.

In brief

The promo code component has two code paths and neither works. One posts to a server endpoint the package never actually served. The other writes the discount to the basket from the browser, using a public credential — which means a shopper could in principle set their own discount, and money the merchant controls must never be supplied by the client.

Both paths are being removed anyway, so this is new code rather than a migration. Without it the feature simply disappears.

The replacement is safe by construction: the shopper supplies a code, and Elastic Path decides what discount that code is worth.

Part of the ADR-0003 token architecture. Carried from #491 and #495.

Why

EPPromoCodeInput has no surviving implementation. Its server branch posts to /api/cart/promo, an endpoint createCartRoutes never served (server-routes.ts handles only [], items, items/:id). Its client branch uses commerce.client and writes a promotion_item on the browser's public anonymous token — a discount is authoritative money under ADR-0013, so that branch was already a defect. Both die, so the replacement is new code either way, not a migration.

Without a replacement the feature dies.

Work

Applying a code is admissible as a named operation: the shopper supplies a code and Elastic Path computes the discount, so the value stays merchant-determined under ADR-0013. Add the dispatch entry and rebuild the component on it.

The useServerRoutes prop does not survive as a switch — it becomes an inert registration in the breaking release, since a per-component token-surface switch only means something while two identity surfaces coexist.

Blocked by: the new named functions issue.

---

ADR-0003: plasmicpkgs/commerce-providers/elastic-path/docs/adr/0003-one-session-for-elastic-path-identity.md. Map: #486. Issue set: #496.