Solutions / E-commerce

Pricing, Eligibility, and Promotions Without Drift

E-commerce teams maintain the same pricing and promotion rules across web, mobile, and backend. Without a shared runtime, they drift. Traverse writes the rule once and runs it everywhere.

Get started All solutions →

The drift problem

Same promo code. Different results.

Promotion: SUMMER20 — 20% off orders over $50

storefront

$48.00

cart API

$60.00

mobile app

$48.00 *

fulfillment

$60.00

* Mobile applies the discount but does not check the $50 minimum. Cart API does not apply it at all. Fulfillment uses a six-month-old version of the rule. All four were supposed to be identical.

Separate implementations that drift

Promotion rules are coded independently in the storefront, cart API, and fulfillment worker. Each gets bug fixes and updates on different schedules. They diverge.

Inconsistency between platforms

Mobile gets a discount the web does not. Or vice versa. Customers notice. Support tickets follow. The fix goes to one place and misses two others.

A/B testing multiplies the problem

Testing two pricing variants means maintaining both versions in multiple places. When the test ends, cleaning up all the copies is error-prone. Some versions persist in production.

AI recommendations need eligibility

The recommendations model needs to know what a customer is actually eligible for. That logic lives in the backend. The AI team cannot call it safely without going through a governed interface.

What Traverse gives you

One rule. Every environment.

Write the pricing or eligibility logic once as a Traverse capability. The same WASM binary runs in the browser, the cart API, the fulfillment worker, and the AI pipeline. The contract enforces correctness before execution. The trace proves it ran correctly after.

Single pricing capability

The browser computes the price for instant display. The API confirms it at checkout. The worker applies it at fulfillment. All three use the same WASM binary. Same result every time.

Governed promotions

Eligibility rules are contracts. Invalid promo codes fail at the contract level before your database is touched. The precondition says what must be true before the discount is applied.

Portable WASM binary

Deploy the same capability to the storefront, checkout flow, and fulfillment service. No reimplementation. No sync meetings to coordinate rule changes across teams.

AI integration via MCP

Expose your eligibility and pricing capabilities to AI agents as MCP tools. Agents call governed capabilities, not raw APIs. The same contract enforcement applies to every AI call.

      The flow with Traverse: storefront, cart, fulfillment, and AI pipeline each load the same capability from the registry. When the promotion rule changes, one version increment updates all of them. No coordination required.
    

promotions.check-eligibility@2.1.0

→

storefront browser

cart API edge

fulfillment cloud

rec agent ai-pipeline

Use cases

Where e-commerce teams use Traverse first

Price calculation engine

Base price, tier discounts, volume pricing, and currency conversion in one governed capability. Browser shows it. Backend confirms it. Fulfillment applies it.

Promotion eligibility checking

Promo code validation, minimum order requirements, customer tier gates, region restrictions. Enforced by contract. Fails fast before touching your database.

Cart validation

Stock availability, quantity limits, bundle rules, restricted items by region. Run in the browser for instant feedback and again at checkout for confirmation.

Product recommendations with eligibility gates

AI recommendation agents call the same eligibility capability your backend uses. Agents only surface products the customer can actually buy at the price shown.

Code example

Promotion eligibility contract

Here is the full contract for a promotion eligibility capability. The runtime reads it before every execution. If any precondition is unmet, the capability does not run. If any postcondition is violated, the result is rejected.

capabilities/promotions/check-eligibility.toml

[capability]
name      = "promotions.check-eligibility"
version   = "2.1.0"
placement = ["browser", "edge", "cloud", "ai-pipeline"]

[preconditions]
# All enforced before execution. Cannot be bypassed by callers.
# Invalid inputs are rejected here — not inside the function.
customer_id  = "non-empty string, max 64 chars"
promo_code   = "non-empty string, alphanumeric, max 32 chars"
cart_total   = "float, >= 0.0, max 999999.99"
currency     = "ISO 4217 code"
region       = "ISO 3166-1 alpha-2"
customer_tier = "one of: guest, standard, silver, gold, platinum"

[postconditions]
# Enforced after execution. Output shape is guaranteed to callers.
eligible       = "boolean"
discount_type  = "one of: percentage, fixed, free_shipping when eligible"
discount_value = "float, >= 0.0 when eligible"
reason         = "non-empty string when !eligible"
expires_at     = "RFC3339 timestamp when eligible"

[constraints]
max_execution_ms = 30
memory_limit_mb  = 8
# Tight limits. This runs in the browser on every cart interaction.

[trace]
emit      = true
retention = "30d"
# trace_id links browser call → API confirmation → fulfillment application
    

The storefront loads this capability and calls it on every cart update. The cart API loads the same capability and calls it at checkout to confirm. The fulfillment worker calls it before applying the discount. All three get the same result from the same binary.

storefront/src/cart/promo.ts

import { TraverseRuntime } from '@traverse-framework/runtime';

const runtime = await TraverseRuntime.init({ registry: REGISTRY_URL });

export async function applyPromoCode(
  cart: Cart,
  promoCode: string,
  customer: Customer,
): Promise<PromoResult> {
  // Same capability the cart API and fulfillment worker use.
  const result = await runtime.execute(
    'promotions.check-eligibility@2.1.0',
    {
      customer_id: customer.id,
      promo_code: promoCode,
      cart_total: cart.subtotal,
      currency: cart.currency,
      region: customer.region,
      customer_tier: customer.tier,
    }
  );

  // Postconditions guaranteed. No defensive null-checking needed.
  if (!result.output.eligible) {
    return { applied: false, reason: result.output.reason };
  }

  return {
    applied: true,
    discount_type: result.output.discount_type,
    discount_value: result.output.discount_value,
    expires_at: result.output.expires_at,
    trace_id: result.trace_id, // passed to API for confirmation
  };
}
    

    The trace_id travels end to end: the browser call, the API confirmation, and the fulfillment application all carry the same trace_id. When a customer disputes a discount, you can pull the full execution chain in one query.
  

Fix your promotion drift.

One capability. Every environment. Contract-enforced from day one.

Quickstart All solutions →