Right Vendor, Wrong Plan: Why Per-Segment Checkout Routing Matters

Most of the discussion around agentic commerce centers on the front of the negotiation: discovery, proof, fit-score, the personalised offer. We’ve written a lot about that part. But there’s an unglamorous mechanic at the back of the protocol — what happens after the agent says “take this offer” — that decides whether the deal actually closes. That mechanic is the checkout URL the agent hands back to the buyer.

Get it slightly wrong and the buyer lands on a generic pricing page, has to re-select a plan they were never offered, and bounces. Get it right and the buyer clicks once, lands on a checkout already configured for the exact plan, with the negotiated discount applied. The difference between the two is a few characters in a JSON response.

This post is about those few characters. Specifically, the payment_link field on each ICP segment — what it does, why it’s per-segment and not per-vendor, and why this is the detail that determines whether agentic commerce actually converts.

The setup: one vendor, several plans

Almost every vendor that runs haggl has more than one plan. Even “simple” catalogues turn out to have three or four SKUs once you look closely — an energy retailer has a flat-rate plan, an EV time-of-use plan, and a 100%-renewable plan. A SaaS vendor has Free, Pro, and Team. An e-commerce site has variants, bundle SKUs, and the gift-buyer one-off.

Almost every vendor that runs haggl also has several ICP segments. The whole point of the ICP framework is that different customers earn different discounts (see How Much Discount Should You Authorize?). The 22% ceiling on “EV Owners” only makes sense if the buyer actually ends up on the EV time-of-use plan. Putting them on the flat-rate plan with a 22% discount applied is a different product entirely and a different unit economic.

Segments and plans don’t map 1:1, but they always co-vary. A “Multi-Site SMBs” segment expects the business plan checkout. A “Green-Conscious Residential” segment expects the 100%-renewable plan. The matched segment determines the right destination. Hard-coding one vendor-level checkout URL throws that information away.

The mechanic

Each ICPSegment in haggl can carry its own paymentLink. When a buyer agent reads the session object, the segment is exposed with that link inline:

{
  "id":                 "ev-owners",
  "name":               "EV Owners",
  "priority":           1,
  "max_margin_percent": 22,
  "payment_link":       "https://retailer.example/checkout/ev-tariff"
}

When the agent accepts an offer keyed to that segment, haggl’s accept endpoint resolves the next step through a deliberate fallback chain:

1. Stripe Connect dynamic checkout. If the vendor is connected via Stripe, haggl mints a single-use checkout session with the negotiated discount baked in as a one-time price — valid for 24 hours, tied to this specific accepted offer. This is the strongest handoff: the discount is enforced at the payment layer, not by trusting the URL.
2. The matched segment’s payment_link. If Stripe Connect isn’t configured (or fails), the buyer is sent to the segment’s configured URL. The accepted offer details apply at checkout — the vendor’s own checkout page is expected to honour the negotiated terms.
3. The vendor-level legacy paymentLink. The pre-per-segment fallback — kept for vendors who haven’t migrated yet.
4. Contact handoff. If nothing is set, the response includes the vendor’s contact_email and a note that they’ll follow up within 24 hours.

Most production vendors land on combinations 1+2 — Stripe Connect for transactional SKUs, segment-level payment_link as the backup for everything else. The per-segment URL is what keeps the protocol legible when Stripe isn’t in the picture (B2B contracts, enterprise quotes, vendors not yet on Stripe Connect).

Why the agent can’t solve this itself

A reasonable instinct is to say: this is the agent’s job. Surely a sophisticated buyer agent can read the vendor’s pricing page, parse the SKU list, match it to the accepted offer, and pick the right checkout link. Why does this need to be in the protocol?

Three reasons.

• The mapping is the vendor’s, not the buyer’s. Only the vendor knows that “EV Owners” corresponds to the time-of-use SKU and not the flat-rate one. Vendors restructure their catalogues regularly. Asking every agent to re-derive that mapping every time the SKU list changes is exactly the kind of per-vendor adapter burden the meta-tag protocol exists to avoid.
• The agent has no notion of internal SKU IDs. The agent knows ICP segment IDs (because the protocol exposes them). It doesn’t know that “EV Owners” in the segment list maps to plan_ev_v3_2026 in the vendor’s billing system. The vendor knows. The vendor is the only place that mapping can live without leaking.
• Buyer agents that “guess” the URL bounce buyers off the funnel. A scraped pricing page may not have stable URLs. The URLs may be JavaScript-injected. The plan may not be addressable directly without a query parameter the agent can’t see. The protocol short-circuits all of this by letting the vendor publish the URL it actually wants the buyer to land on.

In short: the agent’s job ends at “send the buyer to a URL the vendor designated.” The vendor’s job is to designate the right URL per segment. That’s the cleanest division of labour.

The conversion cliff

Anyone who has worked on checkout funnels knows the rule: every additional click between decision and payment is a step where a buyer bounces. The numbers vary by industry, but the shape is consistent — double-digit percentage drop per extra step.

For agent-mediated commerce this becomes acute. The agent has done the legwork: it found the vendor, negotiated the price, agreed on a plan. The buyer is being handed a single link by their agent and told “here’s your deal.” The mental commitment is to that deal, on that plan, at that price. If the link lands them on a generic pricing page with three columns of plans, they have to re-make the decision their agent already made for them. Half of them won’t.

Per-segment checkout routing collapses the post-negotiation funnel to a single step. Click the agent-provided link → land on the plan that matches the offer → pay. No re-selection. No re-deciding. No interpreting which of three columns matches what the agent said.

This is the cliff. Vendors who put effort into segment design but route every accepted offer to /pricing are leaving most of their negotiated wins on the floor.

How it ties back to the LTV math

The discount authorization model assumes the buyer ends up on the plan keyed to the segment. The 22% ceiling on “EV Owners” comes from LTV math on EV-tariff customers — 30-month tenure, off-peak consumption, low cost-to-serve. If that buyer signs up for the flat-rate plan instead because the checkout link defaulted to the residential page, the LTV math is invalidated. They’re now a flat-rate customer at a 22% discount, which the segment economics never authorized.

Per-segment routing is what keeps the authorization model honest. The vendor configured a discount ceiling against a specific cohort; the buyer is delivered into that cohort. The ceiling and the cohort match. Without per-segment routing, those two things drift apart, and the only way to detect the drift is post-hoc when retention numbers come in wrong.

What the vendor sees in the dashboard

In the haggl dashboard, each ICP segment has its own checkout URL field. Vendors set it when they define the segment. If they leave it blank, the legacy vendor-level link takes over (or the contact handoff fires). Changes propagate to the next agent session — no redeploy, no API call.

The recommended pattern for vendors with three or four segments is to define a dedicated landing page per plan, with the relevant SKU pre-selected, and paste that URL into the segment. Generic /pricing goes nowhere. /checkout/ev-tariff or /signup/business-multi-site goes to a page where the buyer can just hit “Pay” or “Sign contract.”

Vendors on Stripe Connect can mostly ignore this — haggl mints the checkout dynamically. But Stripe Connect is overkill for higher-touch B2B contracts, and even for vendors who use it, the per-segment URL is the right fallback for the few cases where dynamic checkout doesn’t apply (annual contracts, enterprise quotes, partner-led signups).

The point

Negotiation is the loud part of the protocol. Routing is the quiet part. The whole machinery in front of the checkout link — ICP fit-scoring, proof verification, margin ceilings — only earns its money if the buyer actually completes the purchase. The link is the last mile, and the difference between a per-vendor link and a per-segment link is the difference between “the agent recommended this vendor” and “the agent closed this deal.”

It’s a small mechanic. It pays for itself the first time a vendor compares accepted offers to actual checkouts and notices the gap close.

Related Reading:

• Anatomy of a <meta name="haggl-negotiate"> Tag
• How Much Discount Should You Authorize? The Math Behind Your ICP
• Not Every Segment Needs Proof. Here’s When to Skip It.
• Your ICP Is Not About Who’s Ready to Buy