Most teams hiring their first payments engineer run their standard backend interview loop, hire the strongest generalist, and discover the gap four months later — usually during a month-end reconciliation that does not balance.
The gap is not intelligence or engineering ability. It is that payment systems fail in ways ordinary product engineering never has to think about, and the habits that make someone excellent at building a high-throughput API do not automatically make them safe around money.
What actually makes payments different
Three things, and they compound.
Money has to balance. In most systems, a dropped event is a bug you fix and move on from. In a payment system it is a discrepancy that will surface in a reconciliation file, and someone will have to explain it to a finance team, an auditor or a regulator. Engineers who have worked in this environment develop a reflex for it — they reach for double-entry, immutability and idempotency without being asked.
You do not control the other side. Schemes, acquirers, processors and banks send you malformed data, duplicate webhooks, out-of-order notifications and partial reversals. Your system has to stay correct anyway. A candidate who has only integrated a clean gateway SDK has not met this.
The state machine is longer than it looks. Authorisation, capture, clearing and settlement are separate stages with separate failure modes, separate timings and separate implications for where the money legally sits. A candidate who collapses them into “the payment succeeded” will design a data model you have to rebuild.
The questions that reveal it
Skip the algorithm round. It selects for interview practice, not transactional correctness.
1. Trace the money
“Walk me through what happens to the money, and to your database, between a customer tapping their card and funds landing in the merchant’s account.”
The best question in the set. Strong candidates naturally separate authorisation from capture from settlement, mention that the money sits with the acquirer before it reaches the merchant, and bring up settlement timing without prompting. Weaker candidates describe an API call returning 200.
2. The duplicate webhook
“Your payment provider sends the same webhook twice, four seconds apart. What happens in your system?”
You are testing for idempotency as a habit rather than a term. Follow up with: what if they arrive simultaneously on two instances? Now you are testing whether they reach for a unique constraint, an idempotency key table, or optimistic locking — and whether they know why “check then insert” is not enough.
3. The partial reversal
“A customer is refunded 30 of a 100 authorisation, then the original settlement file arrives showing 100. What does your ledger do?”
This one separates people quickly. It requires holding the ledger, the reversal and the settlement file in mind at once, and there is no clean answer without an entry-based model.
4. The reconciliation break
“Tell me about a time the settlement file did not match your ledger. What did you do?”
Ask for a specific incident. Anyone who has run payments in production has one. The absence of a story here is the single strongest signal that a candidate’s payments exposure has been peripheral.
5. Retries and the double charge
“A request to the processor times out. You do not know whether it succeeded. What do you do?”
The naive answer is to retry. The good answer establishes idempotency on the outbound call first, and knows that a timeout is not a failure.
What to weight, and what to ignore
Weight heavily: production ownership of a money-moving system, a specific reconciliation or incident story, fluency in the authorisation-to-settlement lifecycle, and instinctive idempotency.
Weight moderately: scheme certification exposure, PCI scope experience, ISO 8583 or ISO 20022 familiarity, direct bank or processor integration work.
Do not over-weight: the specific language or framework. Strong systems engineers move between stacks routinely. Very few move between domains quickly.
The four mistakes that cost a quarter
Running the generic loop. If your interview process is two algorithm rounds and a system design question about a URL shortener, you are not measuring anything that predicts performance in this role.
Conflating issuing and acquiring. These are different markets with different candidate pools. A brief that says “payments experience” without specifying which side will produce a shortlist where half the candidates are wrong for reasons nobody named up front.
Hiring for the platform you plan to build. Teams often hire for scheme-level expertise when the first eighteen months of work is actually building a ledger and an operations dashboard. Hire for the work in front of you.
Treating payment operations as a lesser hire. A strong payment operations person catches losses that engineering cannot recover afterwards. On small teams, that hire frequently returns more than an additional engineer.
A realistic process
Four stages, inside two weeks:
- Screening call (30 min). Trace-the-money question. Compensation and notice period. This alone filters heavily.
- Technical conversation (60 min). The duplicate webhook, partial reversal and reconciliation questions. A senior engineer, not a take-home.
- Practical exercise (60–90 min). Design a ledger and payment state machine for a specific flow, discussed live. Never an unpaid multi-day take-home — the strongest candidates decline them.
- Team and close (45 min). Fit, and a real conversation about what the role owns.
Compress it. In every market we recruit in, the most common reason a strong payments engineer is lost is not compensation — it is a process that took five weeks while a competitor took nine days.
Hiring a payments engineer? Send us the brief and we’ll come back with an honest read on who is realistically available in your market. More on our payments recruitment practice.