Returns & Refunds in Agentic Commerce: Agent State

The Returns Gap in Agentic Commerce

While inventory sync, payment settlement, and checkout flows dominate agentic commerce discourse, one critical operational area remains largely unaddressed: returns and refunds at scale. When a customer initiates a return through an AI agent, the system must orchestrate inventory reversal, payment refunds, shipment logistics, and compliance documentation—all while maintaining transactional consistency. Unlike stateless APIs, UCP agents must recover gracefully if any step fails mid-process.

This gap matters because returns represent 15-30% of e-commerce volume depending on category. In agentic commerce, where agents operate autonomously, a single failed refund can cascade into inventory mismatches, customer disputes, and regulatory violations. The Universal Commerce Protocol must define how agents maintain state through the entire return lifecycle.

UCP Agent State in Returns Workflows

Returns differ fundamentally from forward commerce transactions. A forward sale moves inventory from merchant to customer in one direction. A return reverses that flow while simultaneously:

• Reversing inventory allocation—moving SKU from customer back to merchant warehouse or return center
• Initiating refund authorization—coordinating with payment processors (Stripe, PayPal, Visa) to reverse or credit funds
• Managing shipment logistics—generating return labels, tracking inbound packages, validating receipt condition
• Updating financial records—reconciling refunds against original transaction IDs for audit trails
• Enforcing policy compliance—applying restocking fees, damage assessments, time-window restrictions

UCP agent state management must preserve context across all five steps. If a refund authorization fails after inventory is already reversed, the agent must either rollback the inventory reversal or escalate to a human operator. Without explicit state transitions, agents risk orphaned partial refunds or duplicate inventory credits.

Refund Authorization Challenges with Payment Agents

Payment agents (like Stripe’s Agentic Commerce API or PayPal’s Payment Agent Architecture, both covered in recent site posts) can initiate refunds, but they operate within narrow scope. A refund request must include:

• Original transaction ID (charge_xxxx in Stripe, sale_id in PayPal)
• Refund amount (full or partial)
• Reason code (return, customer_request, fraud, etc.)
• Merchant account and settlement credentials

The payment agent’s response includes a refund ID and status (pending, completed, failed). But the commerce agent must then interpret that response and decide:

• If refund is pending: hold inventory reversal until confirmation arrives (typically 3-5 business days)
• If refund fails: notify customer and determine root cause (insufficient funds, account closed, processor decline)
• If refund succeeds: finalize inventory reversal and close the return ticket

Stripe’s webhook architecture (detailed in UCP Webhook Infrastructure posts) sends refund.created, refund.updated, and refund.failed events. But these events arrive asynchronously. An agent that reverses inventory immediately after initiating a refund request risks a race condition where the refund fails 48 hours later, leaving inventory orphaned.

State Machine Design for Return Workflows

UCP agents handling returns should implement explicit state machines with named transitions:

Valid State Sequence:

1. return_initiated → customer_contact + proof_of_purchase validation
2. return_authorized → generate shipping label, reserve inventory slot
3. return_in_transit → track package, hold refund authorization
4. return_received → inspect item, apply condition assessment
5. refund_requested → call payment agent with original txn ID
6. refund_pending → await webhook confirmation from processor
7. refund_completed → finalize inventory reversal, close ticket

Invalid transitions (e.g., jumping from return_initiated to refund_requested without authorization) must be rejected with an error log. If a state transition times out (e.g., refund_pending for >14 days), the agent must escalate to human review.

This design mirrors agent state recovery patterns (covered in Agent State Recovery: Commerce AI & Reinforcement Learning), but with explicit financial and inventory guardrails.

Partial Refunds and Multi-Item Orders

Most coverage of agentic commerce assumes single-item transactions. Returns in real commerce are messier: a customer orders 5 items, returns 2, and requests a partial refund. The agent must:

• Map which items are being returned (SKU + quantity)
• Calculate the proportional refund (original price × qty, minus taxes/shipping allocation)
• Call the payment agent with the precise amount
• Reverse inventory for only the returned SKUs (not the entire order)

If the original charge was $100 for 5 items + $10 tax + $8 shipping, a 2-item return should refund approximately $40 (2/5 of $100) + $4 tax + $3.20 shipping = $47.20. Rounding errors, bundle discounts, and loyalty credits complicate the calculation. A stateless API cannot handle this without merchants sending detailed line-item data on every refund request.

UCP agents should cache the original order object (retrieved from order management APIs) to calculate refunds deterministically. This requires state persistence: the agent must remember which items were originally ordered, their prices, and tax treatment.

Compliance and Audit Requirements

Returns generate regulatory obligations:

• PCI DSS—refunds must be traced to original card, not issued as store credit without explicit customer consent
• FTC regulations—merchants must issue refunds within 30 days of receiving returned items (US rule)
• Payment processor rules—Visa requires merchants to validate return reason codes to reduce chargeback disputes
• Sales tax—some states require merchants to reverse sales tax only if goods are physically returned (not for digital refunds)

An agent handling returns must log every state transition with timestamps and audit trails. If a refund is delayed, the audit log proves the merchant initiated it on time, protecting against FTC claims. If a customer disputes a refund, the log shows the exact refund ID and processor response.

UCP agents should emit structured audit events (similar to webhook architecture) for every return state change, enabling merchants to build compliance dashboards and export reports for regulators.

Integration with Reverse Logistics Platforms

Most large merchants use specialized reverse logistics providers (Happy Returns, Returnly, Loop, Shopify Returns) to manage physical return logistics. These platforms offer:

• Return label generation and tracking
• Centralized return warehouses (drop-off locations for customers)
• Item condition assessment (photos, ML inspection)
• Resale or disposal routing

UCP agents must integrate with these platforms’ APIs, waiting for condition assessment before finalizing refunds. If an item is assessed as damaged, the agent applies a restocking fee or partial refund per merchant policy. This introduces another async dependency: the agent initiates a return, ships it, and waits for inspection results (typically 5-7 days) before calling the payment agent.

State machines must account for this latency. A refund_pending state should timeout gracefully and escalate if inspection reports don’t arrive within SLA windows.

FAQ

Q: Should refunds be processed immediately or after return receipt?
A: Merchant policy varies. Some issue refunds immediately upon return authorization (better for customer retention); others refund only after receiving and inspecting items (protects against fraud). UCP agents should support both workflows via configuration flags, not hardcoded logic.

Q: How do agents handle refund failures due to processor issues?
A: Implement exponential backoff retry logic with max 3 attempts over 48 hours, then escalate to human review. Log the processor response code to diagnose issues (e.g., 429 rate limit vs. 402 insufficient funds). Do not automatically reverse inventory on first failure.

Q: Can a UCP agent reissue a partial refund if the customer requests more?
A: Only if the original refund completed successfully and the agent has the refund ID. Most payment processors allow refund refunds (refunding a refund) only within 90 days. Agents should check refund eligibility via processor API before promising additional credit.

Q: What happens if a customer returns an item after refund deadline?
A: Agent policy enforcement. If return window (e.g., 30 days) has closed, agent should offer store credit or deny the return. This prevents abuse and aligns with legal requirements (merchants are not obligated to accept returns after reasonable windows). Log the rejection reason for audit.

Q: Should agents handle store credit vs. monetary refunds differently?
A: Yes. Store credit requires no payment processor interaction; it increments a customer ledger account. Monetary refunds require payment agent coordination. Agents should offer store credit as default (faster, cheaper), with fallback to monetary refund if customer declines.

Q: How do agents handle refunds for orders with multiple payment methods?
A: Rare but critical. If a customer paid $60 on card + $40 on gift card for a $100 order, a full refund must split: $60 back to card, $40 back to gift card balance. Agents must track payment method splits on original order and reverse proportionally. This is a common source of payment agent errors.

Conclusion

Returns and refunds represent a genuine technical and operational gap in agentic commerce coverage. While inventory sync, checkout flows, and payment authorization dominate recent posts, the reverse transaction—how agents manage state through a multi-step return lifecycle—remains largely unaddressed. This matters because returns are high-volume, high-risk transactions where state failures cascade into inventory mismatches, compliance violations, and customer disputes.

Merchants and developers implementing UCP agents should design explicit state machines for returns, implement async recovery patterns for payment processor webhooks, cache original order context for refund calculations, and emit audit logs for regulatory compliance. Payment agents alone cannot solve this problem; returns require orchestration at the commerce agent layer, with clear state transitions and timeout handling.