Processing error processing_error
What this decline means
The payment provider hit an error while handling the charge. Sibling of the transient error: the failure lives in the machinery, not in the customer's wallet.
Why it happens on subscription renewals
- A gateway-side exception while authorizing or capturing — malformed exchange, internal error, or an integration edge case.
- A brief incompatibility between the request and the provider's current state (maintenance windows, degraded mode).
The merchant playbook
- Retry after a short delay. Like transient errors, most processing errors are one-off and clear on re-attempt.
- Leave the customer out of it — no email, no alarm, unless the failure persists past several attempts.
- If processing errors persist for one subscription while others bill fine, examine that subscription's specifics: unusual amount, currency, or an edge case in how its payment method was saved.
- If they spike across many subscriptions at once, treat it as an incident (platform or gateway) and pause judgment on individual customers until it passes.
Should you retry?
Yes — a near-term retry is appropriate, with escalation to human review only if the error repeats across multiple attempts and days.
Common questions
Processing error vs. transient error — is there a real difference?
Both are machinery failures. Transient explicitly promises 'try again later'; processing error is the provider reporting an exception, which is usually — but not always — equally temporary. Operationally, treat both as retry-soon, tell-no-one.
When does a processing error stop being 'just retry it'?
When it repeats. Two or three processing errors on the same subscription across different days point at something structural — at that point, inspect the payment method and contract rather than scheduling attempt four.
Related codes: transient_error · generic_error · payment_method_declined · or see the
full decline-code guide.
Where Moorly fits: Moorly reads the raw decline reason your subscription app records for each failed renewal, keeps it attached to the case instead of collapsing it to “payment failed”, and sorts failures into families, so the total you lost is broken out by the kind of failure behind it. Codes it has not yet classified are handled conservatively rather than guessed at. It starts read-only. Join the early-access list →
Moorly is an independent product by Velun Labs and is not affiliated with Shopify, Appstle Inc., or Seal Subscriptions. Code names follow Shopify's public API documentation as of August 2026; bank behavior varies by issuer — always confirm against your own admin.