I would add a Yes/No field to the table. If the value is True void the payment. I would also ask the user if they are sure they want to void the payment to prevent payments accidently being marked as void.

If Then
MsgBox

If this involves accounting (as is usually the case), then the common accounting practice is that you don't really "cancel" or reverse an payment, as if you erase it.  Once a payment has been made, it usually can't be undone.  A bank check could be already cashed, or a wire transfer that was already sent cannot be unsent.  Even an uncashed check can't be undone, because that check# cannot be reused.  So the only way to "undo" a payment is to *add* a credit item to offset it.  You need an Access table that keeps a list of such items for each invoice: payments, chargebacks, refunds, etc.   If you have accounting people among your staff, they may help you with this.

If you do set up such a system, keep in mind that a payment can pay for multiple invoices, and multiple payments can also pay for one invoice.  So your table design needs to accommodate that.

Hey, I have an 'Payment' and 'Transaction' Tables to use. We don't have an Accountant for our Company, so that's the reason why I am trying to Build this Database System. So, should I setup the Transaction Table like the way the "Transaction Tables Database" or "Accounts Receivable" Databases that Richard created?

I believe Richard's videos show only one-on-one type of transactions, i.e. one payment matching one invoice, etc.  You really need a many-to-many setup, because that happens often in the real world.  It is fairly common when someone pays partially, pays in several installments, overpays, pays for several invoices at a time, etc.  If your customer wants to pay for 5 outstanding invoices, you obviously don't want to ask him to write 5 separate checks.  He will give you just one check, and your database has to be set up to accommodate that.  Here is an example of a many-to-many setup:

TransactionID     TransactionDate     PaymentID     InvoiceID     PaymentApplied
1                 5/5/23              100           11223         $100
2                 5/20/23             101           11223         $200
3                 6/1/23              200           33445         $1500
4                 6/1/23              200           44556         $800
5                 8/20/23             520           11223         ($50)

In this case, multiple payments (payment ID 100 and 101) are applied to a single invoice (ID 11223).  And one payment (ID 200) is applied to multiple invoices (ID 33445 and 44556).  The last entry is when you issue a $50 credit if the customer overpaid an invoice.

If things get complicated, consider using other accounting software like QuickBook or a custom-made accounting tool.

In my old job, things got really complicated, and we used a "factoring service" from our bank.  We would log on to our bank to see a list of transactions very much like the above: outstanding items, payments, chargebacks, etc.  We would send our invoices to the bank electronically, and the customers would deposit their payments directly to the same bank, against our invoices.  So the bank has all the info centrally.  The bank could also arbitrate in disputes between our company and the customers.  You need to consider the cost of paying for factoring service versus that of creating and/or paying for an accounting database system of your own.

Another example from my old job: a customer would place an order to be shipped to 100 stores, with each store invoiced individually.  All invoices must have both billing and shipping addresses; that is an industry standard for any commercial invoices that involve shipping.  That's why the 100 stores would have to be invoiced in 100 invoices.  When the customer pays, they obviously aren't going to write 100 checks, but just one.  (But customers who do such high-volume businesses are likely to use electronic payments instead of paper checks.)