Implement atomic subscription plan deletion with batch payment cancellation

[coderabbitai]

Problem

The current subscription plan deletion process has a critical data integrity issue that can leave the system in an inconsistent state. When deleting a subscription plan with active recurring payments, the system cancels payments sequentially without proper error handling for partial failures.

Current Issue

• Sequential cancellation of recurring payments in a loop
• If any cancelRecurringPayment() call fails (network issues, blockchain failures, wallet disconnection), some payments are cancelled while others remain active
• Plan deletion proceeds regardless of cancellation failures
• This violates atomic operation principles and can lead to billing disputes and user confusion

Impact

• Users may continue being charged for subscriptions they believe were cancelled
• Manual cleanup required for partial failures
• Billing disputes and user confusion
• System state inconsistency

Proposed Solution

Backend Changes

1. Request Network API Enhancement

Add DELETE /v2/payouts/recurring endpoint for batch cancellation:

{
  "paymentIds": ["payment1", "payment2", "payment3"],
  "reason": "subscription_plan_deletion"
}

Features:

• Database transaction to ensure all-or-nothing cancellation
• Detailed results for each payment cancellation attempt
• Graceful handling of blockchain transaction failures with rollback

2. EasyInvoice Backend Enhancement

Add deleteSubscriptionPlanWithPayments() tRPC endpoint in subscription-plan.ts:

• Call Request Network batch DELETE endpoint first
• Only proceed with plan deletion if all payments cancelled successfully
• Use database transaction for local state consistency
• Provide atomic operation guarantee across both systems

Frontend Changes

Replace current sequential logic with single atomic call:

await deleteSubscriptionPlanWithPayments(plan.id);

Benefits

• True atomicity across both systems
• Better error handling and user feedback
• Simplified frontend logic
• Elimination of race conditions
• Consistent user experience
• No partial failure states

Testing Requirements

• Verify behavior when batch cancellation fails
• Simulate network failures during cancellation
• Test mixed payment states (some active, some already cancelled)
• Test blockchain transaction failures
• Verify rollback behavior on partial failures

Implementation Priority

High - This addresses a critical data integrity issue that can impact billing and user trust.

---

Related PR: #98
Comment: #98 (comment)
Reported by: MantisClone