Scrum is a collaborative process between the three defined roles (Product Owner, Scrum Master, and Development Team). You are experiencing problems with your Scrum implementation because your Product Owner is not collaborating throughout the process.
The Scrum Team (including the Product Owner) collectively agree to a Sprint Goal for each Sprint, as well as a Definition of Done for stories or Product Backlog Items (PBIs) that will be done within the Sprint.
Work is "done" or "not done" according to these criteria. There is no framework provision for rejecting work that has met the agreed-upon criteria. However, there are opportunities to iteratively improve the product, and to inspect-and-adapt the process.
The Sprint Review
The Sprint Review is the place to demonstrate whatever work was completed during the current Sprint. It is a formal ceremony within the Scrum framework, and has a specific purpose:
A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value. This is an informal meeting, not a status meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration.
The Sprint Review is not intended to be an increment-acceptance or status-report meeting. It's simply a way to collaborate on what should be done next within the project, and for stakeholders to participate in the iterative design and implementation of the product.
Fixing Your Process
The Product Owner should be involved through the Sprint. He should be constantly available to the developers, part of the daily stand-up, and working closely with the Scrum Master to track burn-down, the Definition of Done, and other metrics that relate to the defined Sprint Goal.
If the work-in-progress will not achieve the defined Sprint Goal, the Product Owner may collaborate with the team to modify scope, or to call an Early Termination and a return to Sprint Planning. During the Sprint Retrospective, the Product Owner and the Development Team should also collaborate to improve the quality of user stories, add acceptance testing into each Sprint as part of the Definition of Done, or make other process changes to reduce the likelihood of failed Sprints in the future.
However, work that is completed in accordance with the defined Sprint Goal and that meets the agreed-upon Definition of Done is complete whether or not it's what the Product Owner or stakeholders originally envisioned.
Unless an increment has not met the Sprint Goal or the Definition of Done, the work may not be rejected. However, the Sprint Review is the place to hammer out how to iteratively move towards what stakeholders really want now that they've seen how what they asked for has been implemented. After that, the Sprint Retrospective is the place to identify process or communications improvements that will help the Scrum Team and the organization collaborate better in the future.