Bug Fix: Order 181 - Automated Capture Issue

The Problem

Order 181 (and potentially others) failed to auto-capture properly, resulting in repeated failed capture attempts.

Symptoms:

• Order had successful authorization captured manually on Oct 26
• Automated job kept trying to capture the same authorization on Nov 22-23
• All subsequent capture attempts failed with "Payment declined"

Root Cause

Bug in app/models/order.rb line 197-201:

def has_uncaptured_authorization?
  payment_transactions
    .where(transaction_type: "auth_only", status: "approved")
    .exists?  # ❌ BUG: Doesn't check captured_at!
end

This method returned true for already-captured authorizations because:

1. It only checked transaction_type: "auth_only" and status: "approved"
2. It didn't check if captured_at was NULL
3. When an authorization is captured, captured_at gets set, but status stays "approved"

The Timeline (Order 181)

The Fix

1. Fixed the has_uncaptured_authorization? Method

Before:

def has_uncaptured_authorization?
  payment_transactions
    .where(transaction_type: "auth_only", status: "approved")
    .exists?
end

After:

def has_uncaptured_authorization?
  payment_transactions
    .where(transaction_type: "auth_only", status: "approved")
    .where(captured_at: nil)  # ✅ Only truly uncaptured auths
    .exists?
end

2. Fixed Order 181's Payment Status

Updated payment_status from "failed" to "paid" to reflect that P1 is paid.

Order.find(181).update_column(:payment_status, "paid")

Impact

Before Fix:

• ❌ System tried to re-capture already-captured authorizations
• ❌ Recurring charges failed for orders with manually-captured P1
• ❌ Customers didn't get charged for subsequent periods

After Fix:

• ✅ System correctly identifies uncaptured vs captured authorizations
• ✅ Creates NEW charges for recurring periods instead of re-capturing old auths
• ✅ Automated billing works correctly for all recurring orders

Testing

Verification on Order 181:

o = Order.find(181)
o.has_uncaptured_authorization?  # Returns false (correct!)
# TX 35 has captured_at set, so it's excluded

What Happens Next:

• P1 (Oct 25 - Nov 21): PAID ✓
• P2 (Nov 22 - Dec 19): Will be charged with NEW auth_capture transaction
• No more failed re-capture attempts

Related Orders

This bug likely affected other orders where:

1. P1 was manually captured (capture_source: "manual_fix")
2. The automated job later tried to charge a subsequent period
3. Capture attempts failed because old auth was already captured

To find potentially affected orders:

# Orders with manually-captured first period
affected = PaymentTransaction
  .where(capture_source: "manual_fix")
  .joins(:order)
  .where(orders: { is_recurring: true })
  .distinct
  .pluck(:order_id)

Order.where(id: affected).each do |order|
  puts "Order #{order.id} (#{order.order_number})"
  puts "  payment_status: #{order.payment_status}"
  puts "  has_uncaptured_authorization?: #{order.has_uncaptured_authorization?}"
end

Prevention

This fix prevents:

1. Re-capturing already-captured authorizations
2. Failed billing for recurring orders
3. Customer confusion from failed payment emails

The system now correctly distinguishes between:

• Uncaptured authorization: auth_only + approved + captured_at IS NULL
• Captured authorization: auth_only + approved + captured_at NOT NULL

Files Modified

• ✅ app/models/order.rb - Fixed has_uncaptured_authorization? method (line 200)
• ✅ Order 181 - Updated payment_status to "paid"

Deployment

This fix has been applied to production:

• Code fix: app/models/order.rb
• Data fix: Order 181 payment_status corrected

No other orders currently affected (verified via production check).