Thinking of Test Cases

A strong theme on Taro is that good testing distinguishes a good engineer from a great one. Thinking of good test cases is not trivial, and I would like to know how the great engineers at Taro approach testing.

For example, my company is working on a program (program B, say) that picks up and validates payment requests from program A and sends them to program C, which issues payments, after which program B notifies program A that payment has been issued. I have been put in charge of thinking of test cases, with the biggest concern being duplicate payment issuing.

I have only been able to think of 8 test cases that may actually occur in the program. I have been asked to think of 20-30, and I'm finding it quite difficult to do so. I've only written test cases that can occur assuming the program works as expected, i.e. in which the user does something unexpected. For example, at a certain point program B reads data from a file into the database and moves that file into a directory called "archive". I could hypothetically write test cases for the program's behaviour when the file did not successfully move to "archive", but intuitively this seems trivial.

I believe I probably am thinking about testing in the wrong way / have insufficient knowledge of testing theory. I approached it by starting with what Alex calls the "happy flow", the way the user is supposed to use the program. I then thought of multiple ways the user could mess up when using the program. My next strategy is to go through the code and see what could go wrong (a sort of "white-box" approach), but this is low-level and time-intensive, so I wanted to ensure that it is a good testing strategy. Most testing I've seen thus far has been "black box", i.e. ignore the code and just play around with different user actions.

As always, the advice is very appreciated!