Add expired payment retry and auto-sign flow

[marcopesani]

Summary

This PR adds support for retrying expired payments and enabling auto-sign policies for future payments. When a pending payment expires, users can now retry the payment request or enable auto-sign to automatically approve future payments from the same endpoint.

Key Changes

• Expired Payment Handling: Payments are now marked as "expired" when the countdown reaches zero, with automatic server-side recording via expirePendingPaymentAction
• Retry Flow: Added retryExpiredPayment action to re-execute the payment request and create a new pending payment if needed
• Auto-Sign Integration: Added enableAutoSignAndRetry action that enables auto-sign policy for the endpoint before retrying, allowing future payments to be auto-approved if conditions are met
• UI Updates:
  • Conditional button rendering based on payment status (expired vs. pending)
  • New "Retry" and "Enable Auto Sign & Retry" buttons for expired payments
  • "Reject" button renamed to "Cancel" for expired payments
  • Updated toast messages to reflect context ("Payment dismissed" vs. "Payment rejected")
• Transaction Logging: Expired payments now create transaction records for audit trails across all expiration paths (UI countdown, approval race condition, MCP tools)
• Dashboard Auto-Switch: Added logic to automatically switch to a chain with pending/expired payments if the current chain has none, preventing users from missing actionable payments
• Query Improvements:
  • getPendingPayments now supports includeExpired option to show recently expired payments on dashboard
  • usePendingPayments hook updated to pass through the includeExpired flag
  • New getPendingPaymentChainId helper to find chains with actionable payments

Implementation Details

• Uses useRef to ensure expired payment recording fires only once per card instance
• Shared retryPaymentFlow function handles both retry and auto-sign+retry paths
• Atomic upsert in ensureAutoSignPolicy safely creates or activates auto-sign policies
• Consistent transaction logging across UI, API, and MCP tool expiration paths
• Revalidates dashboard paths after all payment mutations for cache consistency

https://claude.ai/code/session_01LDPLUmKDP2Y7yMJzw2tcub

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
brevet	Error		Feb 28, 2026 10:03pm

[devin-ai-integration]

Devin Review found 1 new potential issue.

View 14 additional findings in Devin Review.

[devin-ai-integration]

🟡 Auto-switch logic uses inconsistent definitions of 'actionable payments'

The auto-switch logic in auth-aware-providers.tsx checks whether the cookie chain has actionable payments using getPendingCount, which only counts status: "pending" with expiresAt > now (src/lib/data/payments.ts:42-52). However, it determines the switch target using getPendingPaymentChainId, which counts both "pending" and "expired" payments (src/lib/data/payments.ts:240-249).

Root Cause: mismatched query semantics

With this PR, expired payments are now actionable (retry / auto-sign / dismiss). But the pendingOnCookie check still uses the old definition that excludes expired payments:

// getPendingCount: only status="pending" AND expiresAt > now
const [pendingOnCookie, chainWithPending] = await Promise.all([
  getPendingCount(user.userId, { chainId: initialChainId }),  // ignores expired
  getPendingPaymentChainId(user.userId),                      // includes expired
]);

Scenario: User has 3 expired payments on cookie chain (chain A) that they want to retry, and 1 newer pending payment on chain B.

• pendingOnCookie = 0 (expired payments on chain A are not counted)
• chainWithPending = chain B (newer pending payment)
• Result: user is auto-switched to chain B, missing the expired payments on chain A

Expected: The cookie chain should be considered as having actionable payments because it has expired payments with retry/auto-sign actions available.

Impact: Users may be silently switched away from chains where they have actionable expired payments, causing confusion when they expect to see those payments.

Prompt for agents

In src/app/auth-aware-providers.tsx, line 34, replace the getPendingCount call with a query that also considers expired payments as actionable. Two options:

1. Add an includeExpired option to getPendingCount in src/lib/data/payments.ts (similar to how getPendingPayments already supports it), and call it with { chainId: initialChainId, includeExpired: true }.

2. Alternatively, reuse getPendingPayments with { chainId: initialChainId, includeExpired: true } and check the length, though this fetches more data than needed.

Option 1 is preferred. In src/lib/data/payments.ts, update getPendingCount to accept an includeExpired option:

export async function getPendingCount(userId: string, options?: { chainId?: number; includeExpired?: boolean }) {
  await connectDB();
  const filter: Record<string, unknown> = { userId: new Types.ObjectId(userId) };
  if (options?.includeExpired) {
    filter.status = { $in: ["pending", "expired"] };
  } else {
    filter.status = "pending";
    filter.expiresAt = { $gt: new Date() };
  }
  if (options?.chainId !== undefined) filter.chainId = options.chainId;
  return PendingPayment.countDocuments(filter);
}

Then in src/app/auth-aware-providers.tsx line 34, change to:
  getPendingCount(user.userId, { chainId: initialChainId, includeExpired: true })

---

Was this helpful? React with 👍 or 👎 to provide feedback.