How to fix a customer requirement with customer in agile ?

While change is expected, looking at your post it seems like the change is too frequent and to the extent that your team is suffering.

Please answer below questions- :

1. Most common reason for change 

2. Do you prioritize backlog?

3. Do you have proper sprint planning meeting and backlog refinement meeting where team clarifies doubts with Product Owner??

First Principle of the Agile Manifesto:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

So, how early and often are you providing increments of work for empirical feedback? Why are you getting your feedback only after development, and not during? It sounds like the leap-of-faith being taken is proving too large and expensive.

Smaller leaps of faith enable the Second Principle:

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Some ideas:

• Limit your risk to one Sprint at a time. Shorter Sprints are less risky. Could you run a 1 week Sprint to get more frequent feedback?
• Teach your Product Owner to craft a product vision and ensure there is a Product Goal, which is transparent. Have the Product Owner share these with the customer.
• Teach your Product Owner about the benefits of having a transparent, ordered Product Backlog, which can be discussed at the Sprint Review. Or perhaps the Product Owner might have a product roadmap to share?
• The Scrum Team needs to complete a valuable, useful product Increment each Sprint. Invite your customer to the Sprint Review to inspect the Increment, give feedback, and collaborate on what to do next Sprint (i.e.adapt the Product Backlog).
• Release product Increments to your customer as quickly as you can, and teach the Product Owner to gather data around measuring value (eg. feature usage, surveys).

There shouldn't be a need to fix customer requirements if you are truly agile.

Agility, when embraced by the development organization and key stakeholders, should minimize the risk of getting requirements wrong. Organizations and people practicing agility value "responding to change over following a plan", where the changes could be changes in requirements and the plan could be the existing implemented and requested requirements. Agile methods should enable changing requirements and "harness change for the customer's competitive advantage".

Scrum, specifically, has structures to support these values and principles. The Sprint is the core event in Scrum that wraps all of the other events and ongoing work. The maximum duration of a Sprint is one month, starts with a Sprint Planning session, and the next-to-last event is the Sprint Review. This means that your plan is, at most, one month long, and you will receive feedback from key stakeholders before making your next plan. If you have built the wrong thing, you should find out about it and have done no more than a month's worth of work, at which point you can address any problems in your next Sprint.

In my experience, most teams using Scrum are working in Sprints that are less than 1 month. Two weeks is a common Sprint length, which means they are making plans that cover two weeks and get feedback more often.

You don't need to wait for a Sprint Review to get feedback. The Product Owner should be in regular contact with key stakeholders. There's nothing preventing the Developers or the Product Owner from getting feedback from stakeholders outside the Sprint Review, even during the design and development of work instead of waiting for work to be finished. Getting early feedback can show areas where the team and the stakeholders may have misunderstood each other and make sure that what is delivered lines up with what people need.

If, for some reason, the team learns that they have built the wrong thing, whether it's by getting feedback in the middle of a Sprint or at the Sprint Review, it could be worth the time to figure out why they built the wrong thing so similar problems can be prevented in the future. The immediate fix is straightforward - capture the changes as Product Backlog Items and order them with everything else in the Product Backlog. The feedback loops that exist can help the team to ensure that their new understanding aligns with stakeholder needs and wants.

In an agile company, "requirements" are only valid until the person that sets them decides to change them.  That is the purpose of incremental delivery with frequent feedback loops.  The way you talk about the requirements leads me to believe you are still working in a waterfall project mode where the customer gives you a lot of requirements, you estimate how long it will take to build it, then they get what they requested when it is done.  That approach does not work in today's world economy.  Things change too fast. People need to be able to see results quickly, even if it is only part of what they asked.  This allows them to provide feedback so that the people building can adapt.  It also minimizes the impact of the requested changes. 

If you are only finding out that the requirements changed extensively "after development", you should work on the incremental feedback loop as everyone above me has suggested.  Stop seeing this as a big problem because the customer needs changed, see this as a big opportunity to fix your process so that you can react to changes quicker and deliver what the customer actually needs.