Event Sourcing with Credit Transaction if not accept to lack of credit

I'm now learning event sourcing. I know many examples of event sourcing are banking or credit systems.

However, they don't discuss the conflict between the same timing commands.

Here is the example:

Backgraound

• User X has $100 at 01:10:00

timeline	payment A ($70)	payment B ($80)
01:10:00	request Payment A
01:10:10	trace current balance at 01:10:10
01:10:11		request Payment B
01:01:12	accept Payment with enough balance $(100 - 70)	trace current balance at 01:01:12
01:01:13	execute the payment event	accept Payment with enough balance $(100 - 80)
01:01:14		execute the Payment event

if the User X query his balance, he got 100 + (- 80) + (- 70) = $-50

It's a terrible situation I think.

-> Question1. Where is the discussion about this solution about the situation?

I know some engineers propose the queue or (pessimistic) lock about the table to solve this problem at CRUD pattern.

Of course, we can use these solutions for event sourcing commands, but these patterns decrease event sourcing patterns' benefits, availability.

-> Question 2. Does the event sourcing system use queue or lock exist?

(OffTopic)

Given These problems, I think some credit system needs a CRUD system and a better persistence logging system which can trace the domain flow.

-> Question 3. My proposal is some thing strange, isn't it?