Cybersource Pending-Transaction Fix
Traced a 22% pending-transaction rate to a button that never disabled, then shipped the fix that eliminated it.
Roughly 22% of Cybersource card transactions were stuck pending, hemorrhaging the card step of the funnel, with no obvious cause in the payment integration itself.
Triangulating transaction data, support call recordings, and behavioral heatmaps, I found the "Pay Now" button never disabled. Users tapped it ~10 times, each firing a duplicate request that broke 3DS and stranded transactions. The fix: disable on first click, show a loader, and prevent duplicate submissions server-side.
Three lenses on one bug.
Quantitatively, single orders showed multiple payment requests against the same order ID and card BIN. Qualitatively, call recordings and heatmaps showed users tapping "Pay Now" repeatedly because nothing told them it was working. Then I reproduced it in-app to confirm cause and effect.
A front-end gap with a payments-integrity cost.
Disabling the button after the first click, adding a loading state, and de-duplicating submissions server-side effectively eliminated pending transactions, lifting success ~10% and cutting card-step drop-off ~20%. A small UX gap, a real downstream cost.
Card payments stuck “pending” · before vs after the fix
Users tapped “Pay Now” up to ten times because nothing said it was working — each tap a duplicate request that broke 3DS. Disabling the button on first tap took pending transactions from 22% to near zero, lifting success ~10%.