Help design a program - multithread?

I am asked to write a program for a PSP (Payment Service Provider). They gave some organizations a barcode readers, in order to read a utility bill. Then, they upload a batch file contains bill data. Then, they pay total amount of bill fees with just one transaction.
But the utility organization needs a separate payment for each bill. This means if you have 200 records in a batch file which has been paid by one payment, a system must pays all of bills separately, to get 200 separate trace number from bank.
Because this bill payment system are separated from the payment server, then bill server application must make payment via calling a web service on the payment server. Payment must be done through idle time of CPU and network traffic.
How can we achieve this goal (paying bills at the CPU idle time and network traffic)?
Another approach will be paying bills simultaneously, as the bill server is a quad core CPU running SuSE Linux Enterprise Server (SLES 10), which I think we can use it via a multi threading software. Am I right? Does developing a multi thread application help us?
Is there any other idea about this?

There are a great array of and potential depth at getting Java to boogie on Linux, it was not all that long ago the all the libs had to be totally re-compiled just to get Java to run at all on Linux, I saw little progress. I did witness one rebild of entire system to get up on it but nothing was ever accomplished on pre-Alpha prototyping. In concept, one can use threading as the Java Virtual Machine has the front-end code and language specification to do a remarkably sophisticated load-balancing design .... but,.. uh,.... you are on your own if this is anything beyond a lab-Queen for Master's level work in concepting behind the Ivory Doors of Academia.

I am never disappointed when I boot up the machine to find tools disappearing, avenues blocked, it's as though Masters of Nothing run the entire data-field. What I would do for your design is just have one class that is the Master class or base class, have it extend thread, then do RumRunner rumRunner = new RumRunner(); in main() and rumRunner.setPriority(lower);then .start(); and see how it runs, isolated from the real world.

Then spend years reading books and writing code, never placing the design in service directly on the critical datapath. That is what I am doing right this moment, I have run-time linkage into the system message dispatcher,..... still finding things that horrifiy me. Maybe cheaper to rent a horror movie or something, definitely less risky - the off button works.

Don't worry about performance. Unless you are dealing with an enormous amount of transactions, or the server is already maxed out, *that* will be the least of your problems.

You have the classic accounts receivable matching problem. You get one payment against many receivables. As long as the total open receivables matches the payment, it's easy. When they don't, you have to determine how to allocate the payment.

Either the payment processing needs to provide you with detail, or you need have a means of handling situations where the totals don't match. Once you figure that out and code it, then worry about where to run it.

Then it's TreeMap keyed on Barcode, front of code is a conditional if TreeMap Key == payment via calling a web service on the payment else {dispatch for totals do not match }

chron can be used to scedule the work to run at four am but trying to do load balancing via threading as an avenue of time-performance improvement is uh, "the least of your problems"

Listen to Steve. Get it to work first. You will probably never have to even think about performance.

If you run into operational performance issues, come back. fixing them is well understood.