The book claims to be a recursive relationship.
I believe it is possible to make a comparison with the example of the book 
I drew a drawing in the draw to represent the answer.

In this way it is possible to represent that there are N clients who receive remuneration from other clients, and that there is at least 1 client who assumes the position of remunerator.
It is worth noting that the number "1" on the payer side indicates that in one transaction there can only be 1 person who is paying the other, that is, there is no 2 or more people make a payment to the same person in the form of a single record (this makes no sense)
If a (paid) person is receiving an amount of more than one person (paid), then there must be 2 separate records of payment.
The answer came from the book:Database systems 5th edition
Authors: Elmasri, Ramez Navathe, Shamkant B.
Year: 2011
Wouldn’t this be a self relationship? Client > Pays > Client, the way you described it. However, it is not necessary to create another entity, the association arrow back to the client itself,
– Andrew Ribeiro
It crossed my mind, but the examples I see only show things related to customer > supervise > client, things like that. And another, the relationship would also become a table because of the cardinality. Is there a problem when I put foreign keys inside the PAID table?
– Eduardo B.
No problem. Even the primary keys of the generated table can be composed by the id of the payee and the id of the payee.
– Andrew Ribeiro
Okay, thank you buddy.
– Eduardo B.
Related: https://answall.com/q/214625/64969
– Jefferson Quesado