Cart & Checkout
Product Documentation v1.0 · Built By Retailers, For Retailers
Confidential — For Publisher and Partner Use Only © 2026 Flipkart Commerce Cloud
About This Document
This document is the product reference for Cart and Checkout — also referred to as the Transact orchestration platform — within Flipkart Commerce Cloud. It covers the Cart domain, Checkout lifecycle, payment orchestration, resilience patterns, and cross-cutting capabilities for retailers and their technical teams.
Audience: Commerce product managers, integration engineers, and solution architects implementing or extending Cart and Checkout on FCC.
Prerequisites: Familiarity with e-commerce checkout flows and basic API concepts is sufficient.
Overview
FCC Transact is the orchestration layer that manages the transition from a user's shopping context to a committed, payment-confirmed order. It operates as the central Domain Orchestrator across two primary domains — Cart and Checkout — coordinated through the FCC API Gateway.
The platform is built around two core principles: Evaluate Before Commit (loyalty, promotions, and delivery promise are surfaced at the cart stage, not deferred to checkout) and Decoupled by Design (inventory reservation, order creation, and payment handling are decoupled so that every failure state is recoverable and traceable).
Cart
What the Cart Does
The Cart domain handles all create, read, update, and delete operations on a user's active cart — for both standard and digital goods. It evaluates the cart in real time by orchestrating calls across product, pricing, promotions, promise, trust, and policy services on every relevant cart event. The cart supports both delivery and in-store pickup items within a single cart, allowing customers to mix fulfilment methods across items in one order.
Cart Persistence
The Cart maintains a persistent, session-aware cart model that supports unit-level price attribution and configurable quantity validations. Cart state is preserved across sessions and channels, and is available to the Checkout domain without re-initialisation.
Fulfilment Types
The cart supports two fulfilment types. For delivery, items are shipped to the customer's address and the platform resolves eligibility based on the customer's shipping postal code. For pickup, customers collect items from a physical store and the platform resolves available stores based on the customer's selected pickup postal code.
OMNI Cart
The OMNI cart allows customers to combine delivery and pickup items in a single cart. Each item is independently assigned a fulfilment type. If an item is eligible for an alternate fulfilment type, the customer can switch it within the cart. The platform automatically resolves the pickup store based on the customer's selected pickup postal code.
If no store is available for a selected postal code, the platform presents the customer with the option to enter a different postal code or switch the affected items to delivery.
Real-Time Price and Promotion Evaluation
The Cart calls a Price, Promotion & Promise Orchestrator, which fans out to a dedicated Promise Engine and Pricing & Promotions Engine. Promotions are evaluated while the user is still in the cart — supporting coupon validation, tiered pricing, and bundle offers before checkout is initiated.
Loyalty Visibility in Cart
The Loyalty Engine is connected at the Cart level, enabling redemption eligibility, wallet balances, and credit availability to be displayed before the user proceeds to checkout.
Trust & Safety and Buying Policy Enforcement
Policy violations, quantity limits, restricted items, and fraud signals are evaluated at the cart stage — preventing users from encountering blocks at a later step in checkout.
Delivery Promise Surfaced in Cart
The Promise Engine is invoked from the cart via the orchestrator, allowing delivery estimates and slot availability to be shown before checkout, reducing drop-off during the checkout flow. For delivery customers, the platform can also display an informational nudge showing how much more needs to be added to qualify for free delivery.
Cart–Checkout Synchronisation
Cart Refresh Triggered During Checkout Init
Initiating checkout can trigger a cart re-sync. If availability, pricing, or promotions change while a user is in checkout, cart state is updated before the order is confirmed — preventing stale data from causing order failures or incorrect billing.
Checkout
What the Checkout Does
The Checkout domain is a transactional state machine that orchestrates the full payment lifecycle — from session initialisation through payment termination and final order approval. It coordinates downstream resource creation (inventory reservations, OMS orders), applies business validations including regulatory compliance, integrates with the Loyalty and Trust & Safety services, and manages the handoff to the Order Management System.
Checkout Init and Update
The Checkout Init API establishes the transactional context for the session. The Checkout Update API allows address changes or promotional code application within an active checkout session without requiring re-initialisation — reducing drop-off from users who need to make corrections mid-flow.
Regulatory Compliance at Checkout
The platform enforces configurable regulatory compliance checks at checkout before payment is initiated. These are tenant-configurable — applicable categories, thresholds, and verification flows are defined per publisher. Examples include:
TV License Verification — When the cart contains television products, the platform requires TV license verification before the order can be placed. The customer enters their ID or Passport number, selects a license type (Domestic or Holiday Home), and either links an existing license, pays any outstanding fees, or applies for a new one. Checkout cannot proceed without completing this step.
Liquor Declaration — When the cart contains liquor products and the total quantity meets or exceeds the configured threshold, the platform requires the customer to accept a liquor declaration before proceeding. This declaration is presented as a widget on the checkout page.
Soft Inventory Reservation on Checkout Entry
The Reservation API is invoked before payment is initiated, soft-reserving inventory for the user's items. This prevents another buyer from claiming the same stock during an active checkout session — particularly important for limited-inventory or high-demand scenarios.
Order Creation at Payment Initiation, Not Payment Success
The Init Order API fires at payment initiation — not after payment confirmation. Every attempt, including failures, is associated with a real Order ID, making failed transactions traceable, retry flows anchored, and edge cases such as partial payment or wallet deductions trackable throughout.
Payment-Based Offer Validation
On successful payment termination, the payment context is passed back to Checkout for final validation. Checkout applies and validates any Payment-Based Offers (PBOs) against the order payload before handoff to OMS — ensuring PBOs are applied only on confirmed payment, not on payment intent.
Hard Reservation on Payment Confirmation
A soft reservation upgrades to a Hard Reservation only after payment is successfully terminated. Inventory is not permanently locked for users who abandon at the payment step — soft reservations are released if the session expires.
Decoupled Payment and Order with Explicit Linking
Payment and Order are created as independent entities and explicitly linked after payment termination — supporting multi-instrument scenarios, partial payment capture, anti-fraud checks, and refunds processed against a payment record independently of order status.
Order Approval as a Distinct Step
Order approval follows payment–order linking as a discrete step, allowing an order to remain in a pending state for fraud review, compliance checks, or manual intervention before confirmation.
Resilience and Recovery
Checkout Reconciliation with Retry and Sideline Paths
A dedicated Reconciliation flow handles scenarios where payment succeeds but order confirmation does not, or vice versa. Retry Checkout automatically re-attempts the failed leg; Sideline Checkout parks the session for operations or manual resolution without impacting the user.
Resumable Checkout via Get Checkout API
Checkout state can be fetched at any point — on page refresh, app restore, or CS lookup — without re-executing the checkout flow. Sessions are resumable without data loss.
Cross-Cutting Capabilities
Session-Based Context for Personalisation and Risk Signals
Session information is passed into the FCC API Gateway for context-building across Cart and Checkout, enabling dynamic pricing, personalised promotions, loyalty tier awareness, and fraud signals without repeated identity resolution calls.
Third-Party Integrations at Payment Termination
External systems — loyalty partners, gift card providers, and analytics platforms — are notified at the payment termination event, providing a single consistent trigger point for all downstream integrations.
Capability Summary
| Capability | Description |
|---|---|
| Unified Cart Persistence | CRUD for standard and digital goods; unit-level price attribution and quantity validations |
| Fulfilment Types | Delivery and pickup supported; eligibility resolved by postal code |
| OMNI Cart | Delivery and pickup items mixed in a single cart; per-item fulfilment type assignment |
| Real-Time Price & Promotion Evaluation | Orchestrated via Price, Promotion & Promise layer at cart stage |
| Loyalty in Cart | Earn/burn eligibility and wallet balance visible before checkout |
| Trust & Safety Enforcement | Fraud checks and buying policy validation at cart stage |
| Delivery Promise in Cart | Slot availability and delivery estimates surfaced pre-checkout |
| Free Delivery Nudge | Informational prompt showing remaining spend to qualify for free delivery |
| Cart–Checkout Sync | Cart refreshed during checkout init to prevent stale state |
| Checkout Init & Update | Session establishment and mid-flow updates without reinitialisation |
| Regulatory Compliance | TV License verification and Liquor Declaration enforced at checkout; tenant-configurable |
| Soft Reservation | Inventory soft-reserved on checkout entry; TTL-based release |
| Order Creation at Payment Init | Order ID created at payment initiation for full traceability |
| Payment-Based Offer Validation | PBOs validated post-payment confirmation before order approval |
| Hard Reservation | Inventory locked only on successful payment termination |
| Decoupled Payment-Order Linking | Payment and Order created independently, explicitly linked post-payment |
| Order Approval | Discrete post-payment step supporting fraud review and compliance holds |
| Reconciliation | Retry and Sideline paths for async payment–order resolution |
| Resumable Checkout | Checkout state fetchable at any point without re-execution |
| Session-Based Context | Session signals used across Cart and Checkout for personalisation and risk |
| Third-Party Integration at Payment Termination | Single trigger point for all downstream external system notifications |
© 2026 Flipkart Commerce Cloud — Confidential. For Publisher and Partner Use Only.