ENGINEERING NOTE 36 / 50 · CARD
Classify card declines before allowing another attempt
A retry should follow a corrected or understood cause. Repeated attempts without diagnosis can add holds, confusion and risk signals.
Published by OPEN RAMBO. The engineering patterns and pseudocode illustrate designs, not a documented product API. Numerical examples are illustrative.
Locate the layer
Separate merchant-form validation, authentication, issuer authorization and later settlement failure. A browser error does not necessarily mean the issuer declined. Collect time, amount, currency and a safe transaction reference before choosing a remedy.
Use supported next steps
Insufficient available value may require reviewing holds and funds; an account restriction requires the relevant provider’s support. Do not invent billing details or rotate cards to bypass a target restriction. A corrected factual billing field differs from fabricated identity data.
Control repeat attempts
Track attempts by merchant operation or invoice, not only browser session. Give users a status-check route when an outcome is uncertain. A second attempt should not be offered while the first may still settle without a clear explanation.
Illustrative implementation
if outcome == "unknown": check_original_transaction()
elif cause_corrected: allow_controlled_retry()
else: show_specific_next_step()Acceptance check
Test a transport error with an existing authorization. The UI must not incorrectly claim there was no financial effect.