The renewal failed — so why is there a pending charge on the customer's bank statement?

Moorly guides · Updated August 2026 · 6 min read

It's one of the more confusing support tickets a subscription merchant can get: the renewal failed — your app says so, no order was created — and yet the customer is looking at a pending charge from your store on their banking app. Sometimes several, stacked up from repeated attempts. Nobody was actually charged, but try explaining that to a customer staring at three pending transactions. This guide covers the mechanism, the failure codes that cause it, and the two changes that reduce how often it happens.

Authorization first, everything else second

Card payments happen in two steps: an authorization (the bank confirms the card is valid and places a hold on the amount) and a capture (the money actually moves). The pending line the customer sees is the authorization hold — it appears the moment the bank approves the hold, before the rest of the billing attempt finishes.

The catch: a Shopify subscription billing attempt can still fail after the card was successfully authorized, for reasons that have nothing to do with the card. When that happens, the authorization is never captured — but the hold has already landed on the customer's account, where it sits until the issuing bank releases it.

The failure codes that aren't about the card

Shopify's SubscriptionBillingAttemptErrorCode vocabulary — the error codes a failed billing attempt reports — includes a whole family of codes that are internal to the store's own state, not the customer's payment method:

• INSUFFICIENT_INVENTORY — “Not enough inventory found.” The subscription's product is out of stock and the variant's inventory policy says don't oversell.
• INVENTORY_ALLOCATIONS_NOT_FOUND — “No inventory location found or enabled.”
• MERCHANT_ACCOUNT_ERROR — a problem with the store's own payment setup, not the customer's.
• PAYMENT_METHOD_NOT_SPECIFIED — the contract has no payment method attached at all.

Every one of these was knowable before any authorization existed — the stock level and the contract's configuration don't depend on asking the bank anything. That's exactly why they frustrate: the customer's card did its job, the attempt failed anyway, and the customer inherited a phantom pending charge for it. (For the card-side codes — declines, expired cards and friends — see our decline codes guide.)

How long does the pending charge last?

An authorization that is never captured doesn't become a real charge — the issuing bank releases the hold when it expires. How long that takes varies by bank and card type: typically days rather than minutes, which is why it reads so badly when it happens repeatedly. There is no merchant-side button to clear it faster in the subscription flow; the practical move is to give your support team a one-line explanation (“that's a temporary hold from an attempted renewal — it was never charged and your bank will remove it automatically”) and to stop generating doomed attempts in the first place.

Fix 1 — pre-flight the contract before attempting

If a billing attempt is predictably going to fail for an internal reason, the best outcome is that it never gets created. The store (or the app acting for it) already knows the contract's lines, so before the attempt: resolve each line's variant and check inventoryQuantity against the variant's inventory policy. A tracked variant at or below zero with the policy set to deny is a guaranteed INSUFFICIENT_INVENTORY failure — skip or delay the attempt until restock, and no authorization ever reaches the customer's bank. The same idea covers the configuration codes: a contract with no payment method attached, or a paused gateway, is detectable up front.

Fix 2 — treat internal failures as a separate class

Inventory and configuration failures should not flow into the same handling as card declines. The customer's payment method is fine — so a “payment failed, please update your card” email is factually wrong, confusing, and a reliable generator of support tickets on its own. No card retry logic applies either: the fix is restocking or reconfiguring, then attempting again. If your dunning tooling can't tell these classes apart, that's a gap worth knowing about — our failure-reasons guide covers the full taxonomy.

What to check on your store this week

1. Pull your recent failed billing attempts and look at the error codes — how many were card problems, and how many were inventory or configuration?
2. Check your subscription products' inventory policies — a subscription SKU that regularly sells out is a pending-charge generator.
3. Read your failure emails — does an out-of-stock failure send the customer a “update your card” message? If so, separate the paths.
4. Brief support with the one-liner about authorization holds.

Moorly is an independent product by Velun Labs and is not affiliated with Shopify. Authorization-hold release times are set by issuing banks and vary; API behavior described here was checked against Shopify's developer documentation in August 2026 — always confirm against the current docs.