{
  "id": 6402160,
  "title": "The hold expired before we tried to capture it",
  "url": "https://urgent.news/2026/09/09/the-hold-expired-before-we-tried-to-capture-it",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-09-09T09:38:57.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/payneteasy/the-hold-expired-before-we-tried-to-capture-it-mcn"
  },
  "original_language": "en",
  "account": "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.\n\nVisa'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.\n\nThe 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.\n\nTo 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.\n\nThe 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?",
  "summary": "Ran into this reconciling a subscription billing system: authorize now, capture in 48 hours after fraud review clears. Worked fine in testing. In production, roughly 2% of captures started failing with a decline code that looked like insufficient funds but wasn't. Turned out the issuer had already released the authorization hold. Visa's guideline is 7 days for most MCCs, but individual issuers…",
  "key_points": [],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}