If you scan the keypad at a sufficiently low frequency, i.e. get through the scan at a rate that allows for even the fastest typist to be "caught" yet still allow for the keybounce, you'll need to wait for the debounce interval to pass and then scan and record the result again, comparing with the prior result. If the last result is an "idle" (no keys pressed) code, and that occurs a second time, then the last keypress value stored is the key code you should process. That way, any unwanted "sneak-paths" will have become invalid due to multi-key closures, while the presumably valid key will remain as the last recorded value.

Note that it doesn't matter how fast you scan, so long as the frequency at which you perform the entire scan is lower than the switch bounce time. The way I'd do it is on a timer-driven interrupt basis using

{scan by whatever method may be available}
{save non-idle code}
{compare non-idle code with previous, perhaps several times}
{if equal, then clear saved value and return the matched value}

There are lots of ways of getting this done. The key is not to waste too much time waiting for things. That's why the timer-driven interrupt is handy.

RE