Agile vs waterfall vs hybrid: which project approach fits a payments project?

Waterfall, or predictive delivery, fits work whose scope is fixed early and approved by someone outside the team, such as a card scheme certification, a regulator's authorization or a hardware rollout. Agile fits work where the right answer is learned by building and testing, such as a merchant dashboard or checkout flow. Most payments projects contain both, so they end up hybrid: iterative delivery inside fixed gates set by schemes, partners and regulators. Choose the approach per workstream, not once for the whole project.

The argument about methods usually hides a simpler question: who has to approve the result, and can they approve it more than once?

What are agile, waterfall and hybrid?

Waterfall (predictive). PMI describes a predictive approach as one where scope, time and cost are determined in the early phases of the life cycle. PMI: Lexicon of project management terms Work moves through planned stages, and changes go through formal control.

Agile. A family of iterative approaches. Scrum, one widely used framework, rests on transparency, inspection and adaptation, and its Sprints ensure progress toward a Product Goal is inspected and adapted at least every calendar month. The Scrum Guide adds that shorter Sprints create more learning cycles and limit risk to a smaller time frame. The 2020 Scrum Guide

Hybrid. PMI's Lexicon describes a hybrid approach as combining adaptive and predictive elements, useful when requirements carry uncertainty or risk. The second edition of PMI's Agile Practice Guide, written with Agile Alliance, goes further and replaces the binary "hybrid" label with a delivery continuum from which teams choose the mix that fits. PMI: Agile Practice Guide · PMI: what is new in the Agile Practice Guide

Agile vs waterfall vs hybrid: how do they compare?

Which payments constraints force fixed gates?

Some approvals cannot be iterated. You submit, a third party tests or assesses, and you get a yes or a no. Plan these as fixed gates.

Terminal and scheme certification. EMVCo's Level 1 and Level 2 testing checks an acceptance device against the EMV contact and contactless specifications, carried out by recognized independent laboratories. EMVCo: Level 1 and Level 2 testing Level 3 integration testing with the payment brands comes after that approval. EMVCo: Level 3 testing Mastercard describes its M-TIP process as Level 3 certification, ending with a Letter of Approval. Mastercard: Tap on Phone implementation guide Visa's US chip testing requirements state its ADVT and CDET terminal tests can only be performed on EMVCo-approved terminals. Visa: U.S. EMV chip terminal testing requirements Preparation can overlap, but the formal approvals run in sequence, each depending on the one before.

Regulator approvals. Licensing has its own clock that the project does not control:

• UK. The FCA says it usually assesses a complete application from a payments or e-money firm within three months, and an incomplete one can take up to twelve. FCA: how to apply for authorisation
• Germany. BaFin's guidance on the Payment Services Supervision Act says it decides within three months of receiving a complete application for a payment institution license. BaFin: ZAG guidance notice
• UAE. The Central Bank's Retail Payment Services and Card Schemes Regulation sets the conditions for licensing retail payment services, and card schemes must obtain a license before starting operations in the country. CBUAE: Retail Payment Services and Card Schemes Regulation

Partner certification. Banks, acquirers and payment method operators often require a certification run in a booked window against an agreed test profile. Payment partner certification covers readiness and exit criteria.

How do you choose the approach for each workstream?

Split the project into workstreams

For example certification, licensing, checkout, reconciliation and operations.

Take one workstream at a time

Does a scheme, partner or regulator approve the result?

If yesPlan to a fixed gate

Freeze the approved scope and plan backward from the test or decision date.

If noDeliver iteratively

Use short iterations and release when each increment is accepted.

Gates and iterations on one plan

Connect them at the interfaces

Agree contracts and test fixtures so iterative work can proceed before the gate.

Evidence for each gate

Decide at the gate

The approver decides on evidence; iterative work adapts to the result.

Simplified: real projects often have several gates, and a workstream can change approach once its approval is complete.

A second question refines the first: how expensive is it to be wrong? A merchant report can be changed next week. A settlement file format agreed with a bank, or a cutover from one processor to another, cannot be cheaply reversed, so it deserves predictive planning even without an external approver.

How does hybrid work in practice?

On a typical payments launch, hybrid means:

1. One milestone plan, owned by the project or program manager. It shows the external gates (certification window, license decision, partner go-live) and the latest dates each depends on.
2. Iterative teams underneath. Checkout, merchant portal and internal tooling teams work in sprints and release behind feature flags.
3. Frozen interfaces at the gates. Whatever the scheme or partner certifies is placed under change control. A later change can trigger re-certification, so it needs a decision, not a ticket. Handling change requests explains how to price it.
4. Evidence produced as you go. Test results, approvals and configuration records are produced during sprints, not rebuilt before the gate. Launch readiness evidence shows the records.
5. Steering reports in milestone terms. Report gate readiness, forecast dates and decisions needed. Velocity is a team tool, not a steering measure.

This is consistent with PMI's emphasis on tailoring the approach to the work. For how the PMBOK guidance and agile combine at the framework level, see PMBOK plus agile hybrid frameworks; the project management guide covers the basics.

What goes wrong with each approach?

• Pure waterfall on a customer-facing product. The design is fixed before merchants have used it, and the first real feedback arrives at launch.
• Pure agile on certification. The team keeps changing a certified flow, and each change reopens testing with the scheme or partner.
• Two plans that never meet. The sprint board and the milestone plan are maintained separately and disagree about the date.
• Gates without evidence criteria. A "go/no-go" meeting without agreed evidence becomes a debate.
• Treating the license as a task. The regulator's timeline depends on a complete application; the project controls the quality of the submission, not the decision date.

FAQ

What is the main difference between agile and waterfall?

Waterfall fixes scope early and delivers in planned stages. Agile delivers in short iterations and adjusts scope based on feedback. Hybrid uses each where it fits.

Can agile be used in regulated payments projects?

Yes, for most product and engineering work, provided the evidence, approvals and controls are designed into the iterations. External certifications and license decisions still need fixed gates.

Why do payments projects need a hybrid approach?

Because they combine customer-facing work that benefits from iteration with scheme, partner and regulator approvals that are pass or fail against a fixed scope on someone else's timetable.

Is waterfall outdated?

No. Predictive planning is still the right fit for work with fixed external requirements, long lead times or costly reversals, such as certification, hardware and platform cutover.

How long does an FCA payments authorisation take?

The FCA says it usually assesses a complete payments or e-money application within three months; incomplete applications can take up to twelve months.