Checkout.com Interview Guide (2026)

1Snapshot, read this first#

The one thing to understand: this is a payments infrastructure company, not a flashy consumer app.

• They care intensely about correctness, idempotency, and systems that do not drop a transaction at 3am.
• Show you think about money moving safely and you are already ahead of most candidates.
• Most candidates default to the happy path and only remember failure when prompted.

2Getting the call (the part most guides skip)#

The pile is large and the ATS is real.

• A cold application without keywords mostly disappears into a queue a recruiter skims in bulk.
• Each resume gets roughly six to eight seconds.

Referrals matter more than people admit.

• Checkout.com runs an internal referral program, and a referred resume gets a human read instead of a keyword scan.
• Find someone on LinkedIn in the team or office you want (London, NYC, Bengaluru, Dubai) and send a short, specific note.
• Not "can you refer me." Say what you built and why their payments stack interests you.
• Example: "I built an idempotent transfer service in Go that survived a Kafka partition rebalance without double-sending, and I saw your team owns the acquirer routing layer. Would you be open to a referral?"
• People refer specifics, not strangers, because a bad referral costs them credibility with their own recruiter.

On the resume, lead with impact and numbers. Bad: "Worked on payment APIs." Good:

Rebuilt the refund reconciliation job in C#, cut end-of-day settlement mismatches from ~1.2% to under 0.1% across 4M daily transactions, saving the ops team ~15 hours/week.

Why that bullet works:

• A real technology (the C# reconciliation job).
• A measurable before-and-after (1.2% to 0.1%).
• A business outcome and who it helped (the ops team, 15 hours/week).
• Test every bullet: "could anyone on any team have written this?" If yes, it is too generic to earn a callback.

ATS keywords that help, when honestly true of you:

• C#, .NET, Go, distributed systems, Kafka, PostgreSQL, Kubernetes, AWS, idempotency, event-driven, REST/gRPC, payments, PCI.
• Payments, acquiring, PSP, 3DS, or fraud experience goes near the top. It is rare and it gets you shortlisted fast.

3The loop at a glance#

Not everyone gets all six.

• A mid-level SE might see screen, machine-coding, one design-lite, and behavioral.
• Seniors always get a full system design.

The signals are cross-checked, so stay consistent.

• The behavioral interviewer reads your coding feedback, and the hiring manager reads everything.
• The "owner mindset" story in the values round should match how you handled a surprise requirement at minute 70 of machine-coding.
• The panel compares notes in a debrief where one strong "no" from a single interviewer can sink an otherwise fine loop.
• Nobody is trying to trap you. They are all asking the same quiet question: would I trust this person with a service that touches real money?

4The coding or technical rounds#

The coding screen is medium-hard, not insane.

• They are not trying to stump you with the hardest graph problem on the internet.
• They want correct, readable code and you talking while you write it.

Patterns they reuse:

• Hash maps and frequency counting. Payments data is full of "group these, dedupe those." A real version: given a stream of transaction events, collapse duplicates that share an idempotency key and keep the latest status.
• Two pointers and sliding window.
• Interval problems (merging, overlap). Maps directly to settlement windows and rate limits, so they like it. Expect "merge these settlement windows" or "find the busiest one-minute window of charges."
• Trees and basic graph traversal (BFS/DFS). Occasionally a topological sort, which maps cleanly to ordering dependent payment steps.
• String parsing. They parse a lot of transaction payloads, so expect to tokenize a message format or validate a fixed-width record.
• Basic DP at the harder end, but not the focus. They care more about clean iterative solutions than a slick memoized recurrence.

The follow-up is the real test.

• Difficulty is roughly LeetCode medium with one that leans hard.
• Expect a changed constraint: "now the input is a stream, you cannot hold it all in memory."
• It shows whether you understand your solution or just pattern-matched it.
• The stream variant is a favorite because it mirrors how their services consume Kafka: you cannot buffer a day of transactions in RAM, so you think about bounded memory and what you give up when you see each event once.

How to practice:

• Do about 60 to 80 mediums across the patterns above, and practice out loud.
• Record yourself and play it back. If you solve it silently but go quiet explaining, you lose points, because the screen scores communication as much as correctness.
• Blunt heuristic: if the playback is boring to listen to, it was probably clear. If you cannot follow your own recording, neither can the interviewer.

How to win the round, concretely:

1. Clarify first. Ask about input size, duplicates, null, empty, negative numbers. Can amounts be negative (refunds)? Can the same id appear twice? Ten seconds of this signals seniority and saves you from solving the wrong problem.
2. State your approach before you type. "I'll use a hash map keyed on transaction id, O(n) time, O(n) space."
3. Narrate while coding, but do not perform. "Building the frequency map now, then one pass to find the answer." Silence for 90 seconds reads as stuck or hiding, and both cost you.
4. Test it yourself. Walk one normal case and one edge case by hand before you say "done."

5System design and the machine-coding round#

This is where Checkout.com is different from a generic FAANG loop. There are two separate things, and which one you get depends on level.

The machine-coding / LLD round (common here, often mid-level)#

You get a small spec and 60 to 90 minutes to build something that actually runs. Classic payments prompts:

• A simple in-memory rate limiter (fixed window, then "make it sliding window").
• A currency/money class that handles rounding correctly (never use a float for money, and they will notice if you do).
• A small payment-splitting or fee-calculation engine.
• A command-parser / mini bank-account ledger with deposits, withdrawals, and idempotent transfers.

What they grade:

• Does it compile and run.
• Is it broken into sensible classes with clear responsibilities.
• Did you write at least a couple of tests.
• Can you extend it when they add a requirement at minute 70.

The number one failure here is over-engineering.

• Do not build a factory of factories for a problem that needs one interface and two implementations.
• Ship the smallest correct thing, then extend.

How to pace the 90 minutes:

• First 5 minutes: clarify the spec and name your classes out loud.
• By minute 35: a running vertical slice, one happy path end to end.
• By minute 55: add tests.
• Leave real margin for the extension they will drop on you.
• The late requirement is almost guaranteed: "now transfers have to be idempotent" or "now add a reversal." Clean design means it touches one class. Hard-coded means rewriting under pressure, which is exactly when they watch your judgment.
• Wire up one test harness early, even a bare main method that prints results, so you are never guessing whether your code runs. Guessing at minute 80 is how people fail a build they had basically finished.

For money specifically, here is the shape I want to see, in C#:

public readonly struct Money
{
    public long MinorUnits { get; }   // e.g. pennies, cents
    public string Currency { get; }   // ISO 4217, e.g. "GBP"

    public Money(long minorUnits, string currency)
    {
        MinorUnits = minorUnits;
        Currency = currency;
    }

    public Money Add(Money other)
    {
        if (other.Currency != Currency)
            throw new InvalidOperationException("Currency mismatch");
        return new Money(MinorUnits + other.MinorUnits, Currency);
    }
}

Two things that quietly earn points there:

• Money is immutable (a readonly struct, no setters).
• Addition across currencies throws instead of silently producing garbage.
• Reach for that guard unprompted and I relax, because it means you have been burned by real money bugs before.
• Ask me "should adding GBP and USD even be allowed?" before writing the method and that is stronger still, because you are thinking about the invariant, not just the code.

System design (senior and up)#

The framework I tell people to use: Requirements, API, data model, high-level architecture, deep-dive on the one hard part, then failure modes.

• Spend real time on requirements. In payments, "what are the consistency guarantees" and "what is the retry behavior" are requirements, not afterthoughts.
• Spend two or three minutes here out loud, write the guarantees on the board, and refer back to them when you make a trade-off later.

Classic Checkout.com style prompts:

• Design a payment processing / transaction service. The whole game is idempotency (a client retries the same charge, you must not double-charge), exactly-once-ish semantics via idempotency keys, and a durable state machine for payment status.
• Design a webhook delivery system (retries, backoff, ordering, dead-letter, signing).
• Design a reconciliation pipeline between internal records and bank/acquirer reports.
• Design a rate limiter or a ledger at scale.

What separates a pass from a fail: talk about consistency and money.

• Where do you need strong consistency?
• How do you handle a partial failure mid-transaction?
• What happens when the downstream acquirer times out but may have actually processed the charge?
• "I'd just retry" is the wrong answer, because a blind retry on a charge that already went through is exactly how you double-charge a customer.
• The right answer involves idempotency keys, a state machine, and reconciliation. That is the whole business.

Make the payment state machine concrete. A payment is not a boolean, it is a lifecycle, and the interviewer wants to see you model it as one.

Then say what makes it safe:

• The idempotency key maps to a stored request record, so a retry of the same charge returns the original result instead of starting a new transaction.
• Transitions are forward-only and each one is persisted before you call the acquirer, so a crash mid-flight leaves a Pending row you can reconcile.
• The timeout case gets a name: if the acquirer times out, you do not assume failure, you mark it uncertain and resolve it against the acquirer's report, because the money may already have moved.
• Saying that timeout sentence out loud is often the moment an interviewer decides you actually understand payments.
• One level deeper: the idempotency record should store a hash of the request body too, so a client reusing a key with a different amount gets a clear error instead of a stale result.

Sketch the write path too, so the deep-dive has something to point at.

6Behavioral and culture fit#

The values center on ambition, ownership, and directness.

• Think of "Aspire" (think big), "Excel" (high bar, ownership), and acting like an owner with speed and integrity.
• The exact wording shifts over time, but the spirit is consistent: ambitious, high-ownership, direct, and collaborative without politics.
• Direct is the word to watch. They like engineers who can say "I think that approach is wrong, and here is why" without it turning into a fight.
• If every story is about perfect harmony, you read as junior or conflict-avoidant, and both hurt at senior level where they expect you to push back on a bad plan.

Prepare 5 to 6 STAR stories:

• A hard technical trade-off.
• A conflict with a teammate.
• A failure you owned.
• A time you shipped under pressure.
• A time you pushed back on a bad decision.
• Have numbers in every result.

For the failure story in particular:

• Own the part that was actually your fault.
• Name the blast radius: how many merchants, how much money, how many hours of on-call.
• Say what you changed so the whole class of bug could not happen again.
• "I shipped it, it broke, I rolled back, lesson learned" is too thin.

One full worked example:

Situation: Our payment status webhooks were arriving out of order, and a few merchants were seeing "refunded" before "captured," which triggered false alerts. Task: I owned the delivery service and had to fix ordering without breaking throughput for the other ~2,000 merchants. Action: I added a per-resource sequence number and a small reordering buffer with a timeout, so events for one payment were delivered in order while unrelated payments stayed parallel. I wrote a replay test against a week of production-shaped data before rolling out behind a flag. Result: Out-of-order delivery for affected merchants dropped from about 0.8% to effectively zero, and we cut the related support tickets by roughly 90% in the first month. No throughput regression.

Why that shape wins:

• It is specific, it has numbers, and it shows ownership and a real trade-off.
• The trade-off is named explicitly: ordering per payment without killing parallelism across payments.
• Interviewers at a payments company lean in on exactly that "I kept the guarantee where it mattered and stayed fast everywhere else" judgment.
• The rollout was behind a flag with a replay test first, which tells them you do not ship risky changes to money flows and hope.

7Your prep plan#

4-week plan:

• Week 1: 25 LeetCode mediums across hash maps, two pointers, intervals, trees. Narrate every one.
• Week 2: Machine-coding reps. Build a rate limiter, a money class, a mini ledger. Time-box each to 75 minutes.
• Week 3: System design. Payment service, webhook delivery, reconciliation. Learn idempotency keys and state machines cold.
• Week 4: Behavioral stories written out in STAR, one mock interview, review payments basics (3DS, authorization vs capture, settlement).

2-week plan:

• Week 1: 20 mediums + 3 machine-coding builds.
• Week 2: 3 system design prompts + 5 STAR stories + one timed mock.

2-day crash plan:

• Day 1: 8 mediums (hash map, intervals, trees), plus build one rate limiter end to end with tests.
• Day 2: Read idempotency, payment state machines, and webhook retries. Write 4 STAR stories. Read the values page and recent product news so you can ask one sharp question.

8Why people get rejected at Checkout.com#

1. Coding silently. If I cannot hear your reasoning, I cannot pass you, even if the code works. A correct solution with no narration is a borderline score, not a strong one.
2. Using floats for money in the machine-coding round. It reads as "has never shipped payments code," and it is the single fastest way to lose the room here.
3. Over-engineering the LLD. A huge class hierarchy for a tiny spec signals poor judgment, not skill, and it usually means you cannot adapt when the minute-70 requirement lands.
4. System design with no idempotency or failure handling. For a payments company this is the whole point, and skipping it is disqualifying no matter how pretty the boxes are.
5. Generic behavioral answers with no numbers. "We improved performance" means nothing. By how much, across how many transactions, and what was your specific part in it?
6. No curiosity about the business. Candidates who cannot name why payments infrastructure is interesting, or ask zero questions, come across as just collecting offers. Have two real questions ready about their stack or roadmap.

Treat correctness as a feature you build on purpose, and the whole loop gets easier.

9The offer, comp and negotiation#

Rough 2026 total comp, varies by level, location, and interview signal:

Packages mix base, an annual bonus, and equity.

• Checkout.com is private, so equity is RSUs/options tied to a valuation, not public stock.
• Treat the equity as upside, not guaranteed cash, and negotiate on base and bonus first.

Because the company is private, price the equity before you weigh it:

• What is the current strike or reference valuation.
• What is the vesting schedule.
• What happens to unvested shares if you leave.
• A grant you cannot price is a grant you should discount in your head, sometimes close to zero if there is no clear path to liquidity.

Negotiation tips:

• Get the written offer before you commit to a number, and ask them to lead. The first number is rarely the ceiling.
• Use the full package. If base is capped at a band, push sign-on bonus or a higher equity grant instead.
• A competing offer is your strongest lever, but only if real. Say "I have another offer at X total, I'd rather be here, can you close the gap," and stay specific and calm.
• Bluffing a competing offer is a bad bet, because recruiters talk and the ask-to-match can call it.

10FAQ#

When you are ready, map these rounds onto your actual calendar and build a dated plan backward from your interview date, so each week has one clear focus.