TMF Open APIs – TMF663 Shopping Cart Management

(Not TMF633 — that’s Service Catalog. The Shopping Cart API is TMF663.)

In modern telecom architectures, one recurring question appears during digital transformation programs:

“Do we really need a standardized Shopping Cart API?”

With microservices, composable frontends, and powerful BFF layers, many teams assume the shopping cart can simply be implemented inside the digital channel.

So where does TMF663 actually fit? And is it still relevant?

Let’s analyze this architecturally.

What TMF663 Is

TMF663 – Shopping Cart Management is designed to:

• Manage pre-order cart state,
• Persist selected product offerings,
• Support configuration updates,
• Transition cart into a ProductOrder.

It is not:

• A pricing engine,
• A qualification engine,
• An orchestration engine,
• A product catalog.

It exists in the pre-order domain, before TMF622 Product Ordering.

The Core Architectural Question

The real question is not:

“Do we need TMF663?”

The real question is:

“Where should cart state live in a distributed architecture?”

There are three common patterns.

Pattern 1 – Cart Inside the BFF (Channel-Owned)

In this approach:

• Digital Channels (e.g., Mobile/Web) interact directly with the BFF (Backend for Frontend).

• Cart Management is implemented inside the BFF.
• The BFF submits orders to TMF622 Product Ordering Management.
• TMF622 integrates with Enterprise Systems (SoR).

Architectural Characteristics

In this pattern, the shopping cart is not a separate domain capability.
It is embedded within the channel layer.

The BFF is responsible for:

• Managing cart state
• Handling product configuration
• Preparing the ProductOrder payload
• Calling TMF622

There is no reusable cart service outside the channel context.

When It Fits

• Single or tightly controlled digital channel
• Minimal partner exposure
• Strong UX ownership
• Fast delivery priority

Architectural Trade-Off

Cart logic is tightly coupled to channel implementation.
Reusability across channels or partners is limited.

Pattern 2 – Centralized Cart Microservice (Non-TMF)

Here, cart becomes:

• Digital Channels interact with the BFF.

• The BFF calls a Custom API.
• That API exposes a centralized Cart Management service.
• The cart service supports order submission via TMF622 Product Ordering Management.
• TMF622 integrates with Enterprise Systems (SoR).

Architectural Characteristics

In this model, the cart becomes a domain-level microservice.

Key aspects:

• Cart logic is removed from the BFF.
• Cart is exposed through a custom (non-TMF) API.
• It can serve multiple channels.
• It manages cart persistence independently of UX logic.

The BFF orchestrates between channels and the cart service but does not own cart state.

When It Fits

• Multi-channel environments
• Need for shared commercial intent
• Internal domain reuse without ecosystem standardization
• Organizations comfortable with custom API contracts

Architectural Trade-Off

While reusable, the API is proprietary.
External integrations require mapping rather than native TMF compatibility.

Pattern 3 – TMF663 as Integration Contract

In this model:

• Digital Channels and Partners both interact with the BFF.

• The BFF integrates with TMF663 Shopping Cart Management.
• TMF663 represents a formalized cart boundary.
• Orders are submitted to TMF622 Product Ordering Management.
• TMF622 integrates with Enterprise Systems (SoR).

Architectural Characteristics

Here, the shopping cart becomes a standardized integration boundary.

TMF663:

• Exposes cart capabilities through a TM Forum Open API.
• Enables partner access.
• Decouples cart management from the channel layer.
• Provides ecosystem-level interoperability.

Cart logic is elevated from an internal capability to a commercial integration contract.

When It Fits

• Partner ecosystems
• B2B2X models
• Marketplace exposure
• Multi-vendor architecture
• Strategic TM Forum alignment

Architectural Trade-Off

This introduces additional abstraction and governance.
It is justified when interoperability and ecosystem scalability are priorities.

When TMF663 Makes Architectural Sense

You likely need TMF663 if:

• You operate multiple digital channels,
• You integrate partners who must create carts,
• You require persistent pre-order state across systems,
• You want clear separation between UX logic and commercial domain.

You probably don’t need TMF663 if:

• You have one tightly controlled channel,
• Cart is purely session-based,
• No cross-domain reuse is required,
• Simplicity is your primary driver.

The Real Architectural Decision

Shopping cart is not about APIs. It is about ownership of pre-order state.

• If cart logic is deeply UX-driven and temporary, then channel ownership may be enough.
• If cart represents shared commercial intent across systems, then domain ownership becomes necessary.

TMF663 is valuable when the cart becomes a reusable commercial asset, not just a UI artifact.

Common Anti-Patterns

1. Implementing TMF663 but keeping cart logic inside BFF anyway.
2. Treating cart as orchestration pre-stage.
3. Embedding pricing and qualification rules inside cart service.
4. Over-engineering cart for small digital contexts.

Relationship to the Order Lifecycle

In a well-structured order lifecycle, validation should happen before commercial intent is persisted.

A cleaner lifecycle flow can be structured as follows:

1. Perform Qualification
   Validate commercial and technical feasibility using:
   • TMF679 – Product Offering Qualification
   • TMF645 – Service Qualification
2. Manage and Persist Commercial Intent
   Store and maintain the validated configuration in:
   • TMF663 – Shopping Cart Management (optional architectural boundary)
3. Submit the Executable Order
   Create and submit a formal customer order through:
   • TMF622 – Product Ordering
4. Orchestrate and Decompose the Order
   Coordinate fulfillment logic and manage order state within the Order Management domain
   (typically consuming TMF622 events and interacting with downstream APIs such as TMF641 where required)
5. Activate and Provision Services
   Trigger technical fulfillment and manage service lifecycle using:
   • TMF641 – Service Ordering
   • TMF638 – Service Inventory

In this model:

• Qualification verifies commercial and technical feasibility first.
• Only valid, sellable configurations are added to the cart.
• The cart stores already qualified commercial intent.

The formal order lifecycle begins only when a TMF622 ProductOrder is submitted. TMF663, if used, sits between qualification and order submission. Its purpose is to organize and persist validated intent – not to perform eligibility or orchestration logic. When designed this way, the cart becomes a clean transition layer. When qualification is skipped or deferred, the cart turns into a staging area for errors that will surface later in order management or activation.

Conclusion

There is no single “correct” way to structure shopping cart management.

As we’ve seen, you can:

• Keep the cart inside the digital channel,
• Implement a dedicated domain cart service, or
• Expose TMF663 as a standardized integration boundary.

Each option is valid — depending on your scale, channel strategy, partner model, and architectural maturity.

Now that you see the different patterns and trade-offs, the question is no longer “Do we need TMF663?”

The real question becomes:

Which option best fits your context, complexity, and long-term integration goals?

Architecture is about making deliberate choices — not following standards blindly.