Your tables mean something like
Student /* [StudentID] is a student AND ... */
Enrollment /* enrollment [EnrollID] is of student [StudentID] AND ... */
Payment /* payment [PaymentID] is enrollment [EnrollID]
AND enrollment [EnrollID] is of student [StudentID]
AND ... */
You must decide exactly what these mean and what situations can arise. Together those determines the constraints (PKs, FKs etc). You must give the meanings to users.
In the case of payments, purchases, orders, prices etc finalized transactions are usually recorded with the data from that time, even if a customer ceases to be a customer or prices changed. Does this matter to you? Is there is a FK
Payment (StudentID) to Enrollment (StudentID)? I gave Payment a meaning that would lead to that FK.
The integrity problem is that your design allows Enrollment and Payment to disagree about EnrollID and StudentID even when the DBMS is enforcing the constraints. That can never arise, and the database would describe an impossible situation, so it's an error, but the DBMS doesn't know that, so it can't reject it.
That problem is gone with FK
Payment (EnrollID, StudentID) to Enrollment (EnrollID, StudentID). Then the DBMS catches those errors.
But then of you update one of those tables then you have to update the other. That is called an update anomaly. (This one doesn't lead to errors when you have the 2-column FK; it's just inconvenient.)
You can see that the table meanings are simpler when you just have
Payment /* payment [PaymentID] is enrollment [EnrollID] AND ... */
If you do want to involve the previous Payment meaning in a query then you use JOIN to get the table whose meaning is the AND of the simpler meanings.
PS You don't need to declare a FK
Payment (StudentID) to Student (StudentID) because it will be enforced by the combination of FKs in Payment and Enrollment.