Guide
A decline code is the whole story
A decline arrives with a code, and the code is the issuer's decision rather than a verdict on the customer. Reading it verbatim is the difference between reporting and guessing.
The code is the decision
A declined payment arrives with a code, and that code is a decision from the issuer rather than a verdict on the customer. insufficient_funds means the account exists and the money is not there yet. do_not_honor is a blanket refusal the issuer will not explain. stolen_card is a fraud determination.
Rewriting those into one friendly message destroys the only signal you have. The extension reports the code verbatim, so a run can be read rather than guessed.
Soft codes and hard codes look identical
insufficient_funds clears when the customer is paid. authenticate_rejected clears when the issuer approves. challenge_required means the step was never completed. Those look alike in a dashboard summary and behave nothing alike.
stolen_card, lost_card, pickup_card and closed_account are hard. They will not succeed, and repeated attempts can count against your acceptance reputation with the issuer.
Report, then decide
The extension's job is to report what the gateway said and what the run did: status, decline code, charge id, ACS vendor, challenge step and result. A decision made on a paraphrased code is a decision made on nothing.
The practical rule: read the code, read the status, read the relay response. A declined run reports its own code instead of posting a card.
The number that matters
How many checkouts settled is the number that matters, not how many were attempted. The menu shows the last run, and the trace shows the path it took to get there.
That is the whole point of the extension: a run you can read back, with the gateway's own words attached to every step.
Apply it without writing a retry engine
The extension ships the scheduling described here. Install it against a test key and watch one declined card get its attempts.