Standard debounce is easy; the interesting part of this question is recognizing debounce is the wrong tool for a payment submission.

The debounce implementation

function debounce(fn, delay) {
  let timer;
  function debounced(...args) {
    clearTimeout(timer);                 // cancel any pending call
    timer = setTimeout(() => fn.apply(this, args), delay);
  }
  debounced.cancel = () => clearTimeout(timer);
  return debounced;
}

A closure holds timer. Each call clears the pending timer and reschedules — so fn only runs after delay ms of quiet. apply preserves this/args; a cancel method lets callers abort.

Why debounce is DANGEROUS on a payment submit

Debounce delays and can drop calls — exactly what you don't want for a charge:

• Trailing-edge delay — the user clicks "Pay," nothing visibly happens for delay ms. They think it failed and click again, or navigate away — now the charge fires after they've left, or fires twice.
• Dropped intent — if anything calls the debounced function again within the window, the previous call is cancelled. A legitimate "Pay" click can be silently swallowed.
• Race with navigation/unmount — the debounced charge can fire after the component unmounts or the user moved on.
• No idempotency — debounce doesn't prevent duplicates, it just spaces them out. Double-submits are still possible.

The failure modes are double charges or dropped payments — real money, real trust damage.

What you should actually do for a payment submit

• Disable the button immediately on click (and show a spinner) — prevents double-clicks deterministically, with no delay.
• Idempotency key — generate a unique key per payment attempt, send it with the request; the server dedupes so a retry/double-submit can't double-charge. This is the real safety net.
• Track request state — idle → submitting → success/error; only allow re-submit from error.
• Server is the source of truth — confirm the charge server-side; never rely on client timing.

Where debounce IS appropriate on the form

Debounce the non-critical, high-frequency bits: live field validation as the user types (card number formatting, "card looks invalid"), or an address-autocomplete lookup. Anything where dropping/delaying a call is harmless. Never the charge itself.

The framing

"Debounce is a closure with a timer that's cleared and rescheduled each call, firing after quiet time. But on a payment form I'd flag that debounce is the wrong tool for the submit: it delays and can silently drop calls, so you risk a late charge after the user left, a swallowed 'Pay' click, or — since it doesn't actually dedupe — double charges. The correct tools for the submit are disabling the button on click plus a server-side idempotency key, with the server as source of truth. Debounce belongs on the harmless stuff — live validation and autocomplete — not the charge."