Your sprint board looks healthy. Standups are fine. But every two weeks the same thing happens: a payment infrastructure ticket hits a wall - not because your engineers cannot build it, but because nobody is confident the architecture underneath it is the right call.
Engineering velocity problems in fintech are almost always diagnosed as execution problems: too many tickets, not enough engineers, slow CI/CD. But for scaling payment companies, the more common culprit is architectural ambiguity - the absence of a clear, trusted voice that can make or validate infrastructure decisions quickly.
The ticket that stalls is not a people problem. Should we introduce a message queue here, or is that over-engineering for our current transaction volume? Do we put this reconciliation logic in a new service or extend the existing one? If we go multi-region on this payment processor integration, what breaks in our idempotency layer? These are legitimate infrastructure questions. When nobody can answer them with confidence, sprints stall.
| Scenario | Real Cost |
|---|---|
| A senior engineer spends 4 hours researching a database design decision for payment state management that an experienced architect could resolve in 30 minutes | 3.5 hours of senior engineering time per decision. At £100k/yr loaded cost, that is ~£170 per unresolved architecture question. |
| A "temporary" idempotency shortcut gets built into production payment processing because there was no one to push back in the moment | £15,000–40,000 to remediate when the first duplicate charge incident occurs in production. |
| Your CTO is pulled into three different conversations about payment infrastructure trade-offs in a single week | CTO time at £200k/yr = £800+ per week of misallocated senior leadership. This is not in their job description. |
| A new payment service gets built in a way that expands your PCI DSS CDE scope unnecessarily | £20,000–60,000 in additional QSA time and remediation. Compliance scope is very difficult to reduce after the fact. |
| A processor integration decision made without considering multi-region failover creates a painful migration 8 months later | 3–6 weeks of unplanned engineering work. £50,000–150,000 in engineering cost plus opportunity cost of features not built. |
None of this shows up cleanly on a dashboard. But it accumulates. At some point it starts showing up as missed deadlines, engineer frustration, and technical debt in the payment stack that is genuinely expensive to unwind.
The question that triggers a 2-hour Slack thread every time. The real answer depends on your retry requirements, your idempotency strategy, and your processor's timeout behaviour - not a preference for synchronous vs asynchronous. Without a clear framework for when queueing is required for payment operations, teams default to "let's discuss it" on every ticket that touches the payment flow.
Define your queuing policy once: any payment operation where a timeout cannot produce a visible user error (background settlement, reconciliation, notification) must be async. Any operation on the critical path with a customer waiting can be synchronous with explicit timeout handling. Document it. Reference it.
A recurring question in every fintech team that has grown past Series A. The honest answer for most companies under £5M ARR is no - until reconciliation query volume genuinely competes with transactional writes, or until a separate team owns it. The cost of premature extraction is 6–12 months of distributed transaction complexity for a problem that does not yet exist.
Extract a service when: (a) a separate team will own it, or (b) its compute requirements are genuinely different from the transaction processing path. Not before.
Most payment processors provide idempotency windows of 24–72 hours. Payments that fail to settle within that window require manual or automated retry with a new idempotency key - which means your internal state machine must be able to handle a "new attempt" flow that is distinct from the original transaction. This is almost never designed upfront and almost always creates a production incident when it first occurs.
Model the "retry after window expiry" state explicitly in your Step Functions state machine from day one. It is not a rare edge case - every payment company hits it.
A senior solutions architect with real AWS and fintech experience costs £95,000–£130,000 per year in base salary, plus benefits and recruitment costs. Realistically £133,000+ in total Year 1 cost. The hiring process takes 3–4 months. And you need payment architecture decisions now - not after a 3-month onboarding period during which the new hire is learning your existing stack.
The in-house hire pattern that goes wrong: Teams raise Series A, hire a cloud architect to solve a specific problem - a processor migration, a PCI DSS compliance push, a payment infrastructure cost overrun. The architect solves it in three months. Then there is not enough ongoing architectural work to justify the role. The architect ends up reviewing PRs and attending sprint planning. Expensive for what it is. Within 12–18 months, the mismatch is obvious to everyone.
Your team hits a payment infrastructure question. Instead of scheduling a meeting, starting a Slack debate, or letting the ticket stall - they submit it to an async architecture review queue with a description of the problem, the options being considered, and the constraints.
Within 24–48 hours, they receive: a clear recommendation, the reasoning behind it, the trade-offs of each option, the PCI DSS implications if relevant, and what to watch for in implementation. No synchronous meetings. No context-switching tax on your engineers.
Payment service design, idempotency strategy, processor integration patterns, state machine design, CDE boundary decisions, observability architecture, multi-region failover for payment flows.
Written recommendation with full reasoning, infrastructure service selection with rationale, PCI DSS scope analysis, cost model, and a decision record your team can reference for future architecture discussions.
Fintech teams of 5–30 engineers building payment infrastructure on AWS, making meaningful infrastructure decisions every 2–4 weeks, without a dedicated solutions architect or with one who is overloaded.
Start with the Infrastructure Readiness Assessment to understand where your payment stack stands today - then see how a membership gives your team the architectural clarity to keep it moving.