Code 100: Processor or Gateway-Specific Decline

Decline Code 100: What It Means & How to Resolve It

Decline code 100 is not a standard ISO decline code. Unlike the two-digit codes that make up most of this cluster, code 100 is a processor or gateway-specific response that maps to an underlying standard decline. What it means depends on which payment system returned it, and the first step to resolving it is identifying that mapping.

What Does Decline Code 100 Mean?

Standard credit card network decline codes follow the ISO 8583 specification and are two digits: 05, 51, 14, and so on. These codes are consistent across networks and processors because they originate with the issuing bank.

Code 100 is different. It's a three-digit code used by specific processors and gateways as part of their own internal response code system. When a processor returns a 100, they're translating an underlying bank response into their own code set. The bank may have returned a 05, a 51, a 12, or something else entirely. The processor wrapped that in a 100.

That means a code 100 from Authorize.net and a code 100 from a different gateway may not mean the same thing. The code itself tells you less than knowing which processor returned it and what their documentation says it maps to.

Which Processors Use Decline Code 100?

Several major processors and gateways use extended three-digit code sets that include 100-series codes. Authorize.net uses code 100 in specific decline scenarios. Other platforms including Braintree, some versions of Stripe's extended error codes, and various acquiring bank systems have their own 100-series mappings.

The right reference is your processor's decline code documentation, not a general guide. Every major processor publishes a response code reference that lists what each code in their system means and what the underlying bank response was. That document is the authoritative source for what code 100 means in your specific environment.

If you don't have that reference handy, your processor's support team can pull the transaction details and tell you exactly what the issuing bank returned alongside the 100 code. Transaction logs from most gateway dashboards also include the raw issuer response code alongside the processor's mapped code, which gives you the underlying standard code to work from.

Is Decline Code 100 a Hard or Soft Decline?

It depends entirely on what the underlying standard code maps to, and that varies by processor.

If your processor's code 100 maps to a Do Not Honor (05) response, treat it as a hard decline. Do not retry, ask for an alternate payment method.

If it maps to Insufficient Funds (51), treat it as a soft decline. The customer may be able to resolve the balance issue and retry later.

If it maps to an Invalid Transaction (12) or similar merchant-side error, the fix is on your end before retrying.

The processor's documentation or transaction log will show you which underlying code applies. Once you have that, the guidance for the corresponding standard code applies in full.

How Merchants Should Handle Decline Code 100

1. Check your processor's decline code documentation first. Find the reference document for your specific gateway or processor and look up code 100. It will tell you what the underlying response is and how to classify it.
2. Review the transaction log for the issuer's original response code. Most gateway dashboards surface both the processor's mapped code and the raw issuer response. The raw code is the standard two-digit code that the bank returned, and that's what you need to know how to proceed.
3. Follow the guidance for the underlying standard code. Once you know what the code 100 maps to, treat it exactly as you would that standard code. If it's a 05, follow hard decline protocol. If it's a 51, follow soft decline protocol.
4. Contact your processor support if the mapping is unclear. If your documentation doesn't have a clear answer or your transaction logs don't surface the underlying code, a call to your processor with the transaction ID will get you the information you need.

Frequently Asked Questions About Decline Code 100

Is decline code 100 the same across all processors? No. Code 100 is a processor-specific code and its meaning varies depending on which gateway or processor returned it. Two merchants using different processors can receive a code 100 for entirely different underlying reasons. This is the core thing to understand about any three-digit decline code: it doesn't have a universal definition the way two-digit ISO codes do. Always check the documentation for your specific processor.

How do I find out what code 100 means for my specific gateway? Start with your gateway's developer documentation or merchant support portal. Search for "response codes" or "decline codes" and look for a reference table. Authorize.net, Braintree, and most major gateways publish these tables publicly. If you can't find it in the documentation, log into your gateway dashboard and look at the raw transaction detail for a transaction that returned the 100 code. The issuer response code field will show the underlying two-digit standard code. Alternatively, call your processor's support line with a specific transaction ID and ask them to explain the response.

Should I retry after a code 100 decline? Only after you've identified what the underlying code maps to. Retrying without knowing the underlying cause is the wrong move because the right retry behavior depends entirely on what's actually happening. A 100 that maps to a hard decline shouldn't be retried at all. One that maps to a soft decline has a retry path. Retry blindly on a hard decline and you waste time and potentially accumulate failed authorization attempts that affect your processor relationship.

How is code 100 different from standard two-digit decline codes? Standard two-digit codes originate with the issuing bank and follow the ISO 8583 specification used across all card networks. They're consistent regardless of which processor or gateway you use. Three-digit codes like 100 are processor-generated and represent that processor's internal mapping of an underlying bank response. They're only meaningful within the context of the specific system that issued them, which is why the same number can mean different things depending on who returned it.

Related Decline Codes

Code 100 maps to different underlying codes depending on the processor. The most common standard codes it represents are worth understanding directly:

• Code 05 — Do Not Honor. The most common underlying mapping for a processor's code 100. Hard decline, no retry path.
• Code 51 — Insufficient Funds. Another common mapping. Soft decline with a resolution path.
• Code 12 — Invalid Transaction. A merchant-side transaction validity error that some processors surface as a 100.
• Code 14 — Invalid Card Number. A card number validation failure that may appear as a 100 in some processor environments.
• Code 06 — General Error. A catch-all processing error sometimes mapped to 100-series codes.
• Code 57 — Transaction Not Permitted to Cardholder. A permissions issue at the account level.
• Code 91 — Issuer Unavailable. A bank availability issue sometimes wrapped in processor-specific codes.
• Code 01 — Refer to Issuer. A bank verification request that some processors surface with extended codes.