It works well to enter your payments directly into your lineitems table. In this way, one payment can be split against multiple sales and one sale can hold multiple payments. Your receipt would be simply printing the sale (invoice) so the customer, at any given time, can see their purchase and any payments made against it. Lineitems would also hold any credits or discounts.
Another option is to record payments in a separate payments table. If you link it to contacts, you'd be able to see all payments made by a given customer. If you link it to an invoice, you can see all payments made against that invoice (and you can do both if you want.)
Most accounting firms require that payments received be applied to an invoice or be returned - never applied against a customer's account. I realize that isn't specifically what is being discussed but I mention it because it is walking a fine line.
Just to be safe, all Developers designing solutions which track customer/company money or salary/payroll are wise to establish firm protections for themselves and their employer. Personally, I think payroll should be left to payroll companies ... it is easier and they track the proper regulations and withholding. AR, on the other hand, can be handled as long as there are clear, written (and signed-off) requirements detailing every piece (posting to GL and freezing activity,aging, late payment fees, write-offs and deposits/returns. When Inventory is added to the mix, it is one of the most complex design tasks you can take on. I wish you well with it.
I agree LaRetta,
I would use a link between a customer table and a payment register as a means for seeing aggregrate totals not for entering data. (How much does this customer owe in total over all their invoices? etc.)