The hold expired before we tried to capture it

The issue arose when the hold expired before a team attempted to capture it in the subscription billing system. Initially, the authorization and capture processes worked well during testing. However, in a production environment, approximately 2% of captures began failing due to a decline code that seemed like insufficient funds, but it wasn't. Upon investigation, it was discovered that the issuer had released the authorization hold.

Visa's guideline for authorization holds is generally 7 days for most Merchant Category Codes (MCCs), but individual issuers had the flexibility to set their own expiration times. In this case, the holds were released anywhere from 3 to 10 days depending on the card's bank. The original authorization response did not provide any indication of when the hold would actually expire. The only way to determine the expiry was when the capture failed.

The team's fraud review queue had a 72-hour Service Level Agreement (SLA) on paper, and the average review time was within acceptable limits. However, the problem lay in the tail end of the queue. A subset of manual reviews took 4-6 days, which exceeded the issuer-specific expiry windows that were not visible to the team. These delayed reviews ultimately led to the authorization holding beyond the acceptable timeframe.

To resolve the issue, the team implemented a straightforward solution. They began tracking the authorization timestamp separately from the order status. If a capture attempt failed with a specific decline pattern and the authorization was older than 3 days, the system would automatically re-authorize the transaction. Additionally, the team stopped treating "authorized" as a stable state once the authorization exceeded 72 hours.

The team wondered how other teams approached this problem. Should they automatically re-authorize upon capture failure with a specific decline pattern and an old authorization, or should they push the delay back into the review queue instead?