重試邏輯應是決策表，而非固定次數

Ask a billing team how their retries work and you will usually hear a number: "we retry four times over twelve days." That answer treats retrying as a single knob, when the implementations that actually recover money treat it as a decision table — a mapping from what the failure is, what the charge is worth, and what has already happened, to whether the next attempt happens, when, and accompanied by what. The distance between "four times" and a decision table is where a surprising share of subscription revenue sits.

The inputs the table should read

Start with the decline class, because it dominates everything else. A temporary failure earns attempts; a credential failure earns a card-update request with attempts held in reserve; a terminal failure earns none. Next, value: the fully-loaded worth of saving this subscription — its remaining expected lifetime margin, not just this charge — because a $900 annual renewal justifies a patience and a number of touches that a $9 monthly never will. Next, history: an account on its first failure in three years is a different risk from one that fails every cycle, and the table should know it — recurring soft failures often signal a subscriber budgeting around your charge, which argues for aligning the schedule to their pay rhythm rather than escalating pressure. Finally, elapsed context: what else has fired — platform retries, updater events, messages sent — because an attempt is only useful if it adds a new chance, not a duplicate of one already spent.

The outputs nobody designs

Most teams design attempts and inherit everything else by accident: the email that accompanies each attempt (usually the same one, growing sterner), the access state during the window (usually inherited from a policy nobody remembers choosing), and the stopping rule (usually "when the schedule ends," rather than "when the marginal attempt stops paying"). A real decision table specifies all of it per class: for authentication failures, the first output is a message, not an attempt; for terminal failures, the output is a single graceful exit path; for high-value soft failures, the output is a longer table with human review at the end of it. The stopping rule deserves its own sentence in the design doc: every attempt costs a fee and a sliver of issuer goodwill, so the table ends where expected recovery crosses expected cost, class by class, and not one global count later.

Where machine learning helps and where it is decoration

Learned timing models — the kind large processors train on billions of transactions — genuinely help on one input: when a temporary failure is likeliest to clear. They cannot help on the inputs they cannot see: your margin per plan, your subscribers' tenure, your tolerance for issuer risk. The mature architecture uses the model's timing as one row in a table the merchant still owns. A fuller engineering treatment of how payment retry logic should be structured, input by input walks through a reference table you can adapt, including the classes where the correct retry count is zero.

The test of whether yours is a table or a count

Pull ten failed renewals from last month at random and ask, for each, why it received exactly the attempts it received. If the answer is the same sentence ten times, you have a count. If the answers cite the failure class, the value, and the history — you have logic, and logic is what compounds as you tune it.

Retries are the heartbeat of recovery. A count is a metronome; a table is a musician. The revenue difference between the two is not subtle.

Swipe Again publishes engineering notes on recovery systems for subscription businesses.