What will you do as a project manager if the programmer is asking for overtime pay due to additional hours spent to additional user stories that was not planned on the initial estimate, but when you check it, it is part of the scope?
First of all, adding new user stories after the initial plan, is a very normal agile process. Agile is about minimizing upfront planning and continuously revising and updating the product backlog until the product is finished.
Secondly, I do not think that connecting bad estimates or bad planning with overtime payment policy is a good idea. Rather it must be connected with the quality and quantity of the work it is produced.
Seems to me that this will come down to the programmers contract.
In general though, Assuming overtime is in their contract, if they worked the extra hours you should pay them. Although most contracts I've seen will only allow paid overtime if it is approved first.
The phrasing of your question though makes it looks like you are trying to justify not paying the developer because their estimate was incorrect or that the work might be out of scope for the project or sprint.
This would not be an advisable route to go down in my opinion. You want developers to estimate tasks without having to worry they might get paid less, or work more hours if they estimate low.
Similarly with the scope. Usually clients want a nice working product, not a legalistic exact interpretation of a potentially wrong or incomplete spec. Generally you would want to encourage developers to 'fill in the blanks' rather than working to rule. It will make your job easier in the long run.
Obviously some projects have very exacting specifications and very tight budgets and you would want to make this clear to the developers when the project starts
Asking for overtime suggests he is an employee and not a contractor. Assuming that is true and that you are in the US, then he likely understands the difference between being exempt and non-exempt. Assuming his job family is exempt, then you have three competing issues: 1) paying him overtime will bring into question whether you assigned to his job family the exempt versus non-exempt status and then you will have to change the entire job family; 2) he may look for greener pastures and, if he is a solid employee, you will need to fill the gap; and 3) when it gets out--and it will get out--he was able to get more money with a complaint, you may open the floodgates for others to knock on your door.
The general rule I have seen companies institute for things like this is: No, get back to work. It sounds harsh and cold and not very employee friendly but I think it mitigates a ton of issues you WILL cause by entertaining this. No one is irreplaceable. Take that risk over the other risks.
If he is a contractor, refer to the contract and then tell him to go back to work.
Bad estimates, poor planning, changes, agile, scrum--these are all irrelevant to the problem.
Assuming the programmer in question is an employee:
Do you have a company policy for unrequested overtime? Are employees made to be aware of it?
If the answer to both of those is 'yes', then consult your policy. If the answer to either is 'no', then that's where you need to start. Work with HR to get a policy put in place. For this specific instance, however, I'd suggest just paying the overtime. You needn't worry about it becoming a trend, as you'll be updating the company's policies specifically to avoid this. And the loss of morale of a programmer who believes s/he's been treated unfairly can be costly.
Assuming the programmer is a contractor:
Consult the contract.
Of course, this all assumes it was unrequested overtime, and not a situation where, for example, the Scrum Master requested overtime without informing you. That's its own problem, and you should probably double-check first, just to be safe - "Did anyone ask you to perform this overtime?"