Yes. Under your current contract and within your current process, you should pay the vendor for all work completed. Unless you have a fixed-price, fixed-scope contract, all the problems you've described are process issues for which your company (rather than the vendor) is responsible.
You are having difficulties because you are treating the offshore company as an external vendor, rather than actively collaborating with them during each iteration. The Agile Manifesto values:
Customer collaboration over contract negotiation[.]
Both problems are resolvable by better agile collaboration. In the meantime, as a purely pragmatic matter you should probably pay the invoices if you wish to continue using this company as a vendor. Treat it as a sunk cost and improve your process as you move forward.
Scrum Scoping and Deliverables
Based on the following statement, you aren't leveraging the Scrum framework in your current process. You ask:
Should we be paying for non-planned things that are neither a part of our requirements nor are a change request from our side (i.e. deployment to staging server not working, updating codebase to support newest iOS version, etc.)?
This question highlights several issues with your current process, including:
- Your company should either be providing the Product Owner for the process, or actively collaborating as a stakeholder through a Product Owner on the vendor's side.
- You mention of "unplanned work" indicates that Product Backlog Items are not being properly decomposed and planned out at the start of each iteration.
- The failure to expect the unexpected, especially in IT, violates the core agile principle of embracing change, and generally indicates a lack of sufficient slack and iterative planning in your process.
- The mention of "requirements" and "change requests" indicates an organizational mindset focused on upfront specification rather than truly iterative or collaborative development.
To fix these sorts of problems, you will most likely need a fundamental shift in how you work with your vendor. At a minimum:
- There must be a clearly-defined Product Owner role, and both the stakeholders and the development team should actively collaborate with the Produc Owner to manage scope and prioritize deliverables.
- The work for each iteration must be taken from a prioritized list of work items (the Product Backlog) and decomposed into tasks for the Sprint Backlog. This just-in-time planning is essential to proper scoping and identifying knowable (but potentially unplanned) work that will impact the current iteration.
- Your process must contain sufficient slack to handle a reasonable amount of uncertainty. IT development is an inexact science, and expecting 100% certainty or 100% utilization will serve you very poorly in your planning. An immature Scrum process should generally target only around 60% of team capacity in order to handle the vicissitudes of software development.
- The process must begin treating Product Backlog Items and the Product Backlog as an ongoing conversation between stakeholders and the development team. The backlog is not a list of fixed specifications; each item on the backlog is a starting point for iterative planning and collaborative development.
Testing, Defects, and the Definition of Done
You can't expect anyone to hit moving target. When you say:
After user acceptance testing, should we be paying for the development team to fix defects we find in features they delivered as complete?
you are implicitly saying that you reserve the right to move the finish line after you've already agreed on the Definition of Done for an increment of work. Don't do that!
The question shows that there is a lack of test-first development in the current process, and that you and the vendor are not actively collaborating on the Definition of Done for Product Backlog Items. In order to resolve this, the process must change from subjective, post facto testing to objective (and ideally executable) criteria for measuring success.
To address the gaps in the current process, carefully consider the following:
- Collaborate with your development team on the acceptance testing criteria before they do any development. This ensures that everyone agrees on an objective definition of "potentially shippable" for the increment.
- Work that doesn't meet the agreed-upon criteria isn't defective; it's simply "not done."
- If you have a lot of work that ends up "not done" at the end of each Sprint, this is ideal process-improvement material to discuss in your Retrospective.
- If work meets the agreed-upon criteria, but you need refinements or changes, then this is future work that belongs on the Product Backlog for prioritization and planning. Being imperfect is not a defect; it is a transitional state for emergent designs within an iterative development process.
- Even if you find out after the fact that everyone agreed on the wrong criteria, it was still the increment of work agreed-upon at the outset. The development team shouldn't be penalized because the stakeholders and the Product Owner asked them to build the wrong thing.
Inspect and Adapt Iteratively!
There are certainly other issues with the current process that need to be addressed as well. Make sure that you and the vendor collaborate on a joint Retrospective, and work together every iteration to continuously inspect and adapt your process until it runs more smoothly for both of you.
Please remember that "smoothly" doesn't mean perfect! It just means that the overall process operates within defined tolerances, and that the project management controls perform as expected.