Skip to content

Decline code 13: Invalid Amount

Travis SteffenBy Travis Steffen · Co-Founder, GTMReviewed by Calum EwingUpdated 3 min read
Summarize with AI

Quick answer

Decline code 13 — “Invalid Amount” — is an ISO 8583 response indicating the issuer or network rejected the transaction because of the amount field: a value that is zero, negative, malformed, over a ceiling, or carries the wrong currency exponent (e.g. cents vs. dollars). It is a hard decline, so an unchanged retry repeats the rejection. Stripe surfaces the equivalent as a card_declined error and Authorize.net returns reason code 2 (Declined).

What code 13 means

Hard declineDo not retry

Re-running the same request rarely clears a 13 — the transaction amount itself is what the issuer or network rejected. Fix the amount (or the data behind it) before another attempt, then retry; blind back-to-back re-tries just repeat the same rejection.

Cross-processor equivalents

The same issuer decision surfaces under a different code on every processor. Here is how code 13 maps across the stacks Revatto recovers on.

ISO 8583
Code13
CalledInvalid Amount
Stripe
Codegeneric_decline
CalledGeneric declinealso card_declined
Braintree
Code2038
CalledProcessor Declined
Authorize.net
Code2
CalledDeclinedresponseReasonCode 2 — generic issuer decline
NMI
Code200
CalledTransaction declined
Chargebee
Codecard_declined
CalledCard declined
Recurly
Codedeclined
CalledDeclined
IxoPay
Code2002
CalledDeclined
Shopify
CodePAYMENT_METHOD_DECLINED
CalledPayment method declined
Whop
Codecard_declined
CalledCard declinednormalized — no processor-specific code (free-text categorized)
Fanbasis
Codecard_declined
CalledCard declinednormalized — matched by substring rule, no processor-specific code

Why it happens

  • The amount field is zero, negative, or empty when the network requires a positive value.
  • Currency-exponent or scaling error — the amount was sent in dollars where minor units (cents) were expected, or vice versa, so the value reads as malformed.
  • The amount exceeds a per-transaction ceiling the issuer or acquirer enforces on the card or merchant account.
  • A formatting fault — non-numeric characters, too many decimal places, or a value outside the field’s allowed length per the ISO 8583 spec.
  • Card or account restrictions on the transaction type that the issuer reports against the amount rather than itemizing a more specific reason.

How to recover it

  1. 1Don’t re-submit the same request — an unchanged amount returns the same 13 and inflates your decline ratio.
  2. 2Check the amount before anything else: confirm it is positive, scaled to the correct currency units, formatted cleanly, and within the issuer’s ceiling.
  3. 3When the charge is legitimate but capped, reach the customer on a channel they answer — email and SMS — to confirm the amount or split it into an allowable charge.
  4. 4
    When it persists on a recurring subscription, a real person — not another automated email — works the amount and the card update directly. That AI-plus-human handoff is exactly what Revatto does for you: AI-timed retries where the processor API supports them, plus email, SMS, and human outreach, fully done-for-you. You only pay if it works — 20% of the first recovered payment, $0 setup, $0 monthly, cancel anytime.See how Revatto recovers 13declines →

See what Revatto would recover for you

Failed payments recovered automatically — no engineering, no manual chasing. We do the work; you keep the revenue.

See Your Recovery Potential

Frequently asked questions