Agile Projects Generally Work Best When Billed as Time-and-Materials
Do software developers operating under some sort of agile development cycle and presenting a series of 'deliverables' to their customer expect—or contract—their clients to make a stage payment per acceptable deliverable?
In the world of contracting, anything the parties agree on (provided it isn't illegal) is generally acceptable. So, you could certainly do this. Whether or not it is common is a different question, and that's likely hard to quantify.
Agile projects could be structured around piece-work, or around stages or phases of the project. However, such payment terms are usually a thinly-veiled attempt at fixed-cost pricing for fixed-scope specifications. This doesn't work well with an iterative development methodology that explicitly values collaboration over contract negotiation.
In my professional experience, agile projects are most effective when billed on a time-and-materials basis, with project controls on both sides to manage scope, budget, and risk. In particular, Scrum is designed to establish a cadence for the project such that a potentially-shippable increment is delivered each Sprint. The project can be stopped at the end of any Sprint, either because the goals were met or because the project has successfully "failed early."
If you want the benefits of an agile methodology, then you need to use a contract structure that encourages collaboration and continuous engagement rather than risk management. Contracts that shift all the risk to the vendors, especially the risk of potential process issues originating on the client side, almost always prevent real collaboration on emergent designs.