PayPal Interview Questions (2026): What They Actually Ask

Split on '.', verify exactly 4 parts, each part is a valid integer in the range 0 to 255 with no leading zeros (except "0" itself). Reject empty parts and parts with non-numeric characters. The edge cases are where candidates lose points: "01" has a leading zero and should be invalid; "256" exceeds range; "1.2.3" has only 3 octets.

Reported from a PayPal technical phone screen. An easy problem where interviewers probe your attention to edge cases. Candidates who run through the happy path and call it done usually get a follow-up that exposes the leading-zero case.

BFS with a queue. At each level, record the queue size before processing, that size is the width of that level. Dequeue all nodes at the current level and enqueue their children. Track the maximum width seen. A more memory-efficient variant uses indexes, representing each node's position in a full binary tree to compute width without explicitly tracking all null nodes.

Reported in multiple PayPal phone screen accounts. It shows up as the warm-up problem before the real coding question. The indexed-width variant (using 2*i and 2*i+1 for child positions) comes up as a follow-up when the tree is sparse and naive BFS counts too many nulls.

Spring is the framework: dependency injection, AOP, transaction management, data access. Spring Boot is an opinionated layer on top: auto-configuration based on classpath presence, an embedded server (Tomcat by default), starter dependencies that pull in and configure related libraries as a bundle, and an actuator for health and metrics endpoints. Boot eliminates the XML configuration boilerplate that made Spring painful for new projects.

Reported in the managerial round at PayPal SDE II. Follow-up: "How would you override an auto-configured bean?" The answer: define a bean of the same type in your application context and annotate it with @Primary, or use @ConditionalOnMissingBean on the auto-configuration class to suppress it entirely.

PCI DSS, the Payment Card Industry Data Security Standard, is a set of 12 requirements the card networks impose on anyone who stores, processes, or transmits cardholder data. For an engineer day to day, the practical version is: never log a raw card number, tokenize the card at the point of entry so a reference token replaces the primary account number before it touches most application code, segment the network so only a small, audited scope ever handles real card data, and encrypt cardholder data both at rest and in transit.

The useful interview framing is tokenization first. A candidate who designs a payment flow where the raw card number passes through five internal services before it's finally stored has a compliance problem regardless of how well the rest of the distributed system is designed. PayPal, operating as both a processor and a merchant-facing platform, expects candidates in fintech-adjacent rounds to raise tokenization and scope reduction on their own, without the interviewer having to prompt for it.

PayPal specifically reports this question on Glassdoor. The answer they're listening for: you have a structured approach to un-sticking yourself, not just "I ask for help." A reasonable structure: isolate the assumption you haven't tested, build the smallest reproduction of the problem, check your instrumentation before trusting the output, time-box the solo attempt and then escalate with context. "I was stuck for three hours before Slack-ing the team" is a weaker answer than "I time-box at 30 minutes before seeking input, and when I do I lead with what I've already ruled out."

Generic "fintech is exciting and payments affect everyone" answers are transparent and don't differentiate. The answers that land: you name something specific about PayPal's technical trajectory (the migration from monolith to microservices, the Braintree and Venmo platform integration challenges, the scale of operating across 200+ markets), or a specific product feature you've used and thought about technically, or a specific engineering blog post that gave you a concrete question you want to work on. Research the team. Ask the recruiter what the team is building this quarter. Use that.

Most candidates report 3 to 6 weeks. SDE-level loops tend to close in 3 to 4 weeks when the process moves smoothly. Senior and staff loops are slower, typically 4 to 6 weeks, because team-matching and hiring committee steps add time after the final onsite. The OA is usually sent within a few days of the recruiter screen, and the onsite is typically scheduled within two weeks of passing the technical phone screen.

Yes. The OA runs on HackerRank. New-grad reports describe 11 questions in 90 minutes: two coding problems (easy to medium DSA) and nine multiple choice questions covering SQL, JavaScript, Java OOP fundamentals, and basic CS concepts. For experienced hire roles the OA format varies and some loops skip it entirely, going straight to a technical phone screen. Ask your recruiter whether an OA is part of your specific loop.

For backend and platform roles, Java fluency is strongly recommended. PayPal's core systems are Java-heavy, and interviewers for those teams routinely ask Java-specific follow-ups: HashMap internals, CompletableFuture, streams and lambda syntax, Spring Boot configuration. For full-stack or newer services teams, TypeScript and Node are common and you may not face Java questions at all. Confirm with your recruiter what stack the team uses. For the OA and live coding rounds, Python is generally acceptable as the coding language even in Java-heavy teams.

More important than most SWE candidates expect. General coding skill gets you through the OA and the first technical round. The system design round and the role-specialization round actively test payments domain knowledge: idempotency, double-entry accounting, ACID properties in distributed systems, fraud detection pipeline design, PCI DSS at a basic level. Candidates without this context visibly lose ground in the design round even with strong algorithmic skills. Two or three hours reading about idempotency patterns, payment saga flows, and basic fintech architecture will put you ahead of the majority of candidates.

Usually not a full formal system design round. New grad loops focus on coding problems and behavioral questions, with a lighter design or low-level OOP question sometimes appearing in the HM round. At SDE-2 and above, a dedicated system design round is standard. Staff-level loops may include two design rounds, one low-level and one high-level architecture. If you're unsure, ask the recruiter what rounds your specific loop includes before you start prepping.

Three areas matter most. First, understand idempotency and exactly-once semantics in distributed payment flows. Second, read about double-entry accounting and why append-only ledgers are standard in financial systems. Third, be able to discuss ACID tradeoffs in distributed systems: where strong consistency is non-negotiable (the ledger) and where eventual consistency is acceptable (notification history, analytics). On top of that foundation, the standard system design prep applies: API design, database sharding, caching strategies, failure mode analysis. The Stripe and PayPal engineering blogs both publish technical posts on these topics and are worth an afternoon of reading before your onsite.

PayPal's individual contributor ladder runs roughly SDE1 (new grad or early career), SDE2 (2 to 5 years), Senior SDE, Staff, and Principal, though exact title conventions shift slightly across business units like Braintree and Venmo. SDE1 and SDE2 loops lean on coding and behavioral rounds with a lighter design component. Senior and above add a dedicated system design round, and staff-level loops sometimes split that into two rounds, one low-level and one high-level architecture, plus the extra hiring-committee step that adds time to the process described earlier on this page.

Ask the recruiter directly which level the role is leveled at and which rounds apply before you start prepping. Loop composition gets decided before you're scheduled, so an accurate answer here changes what you should spend your remaining time on.

Authentication answers "who are you", authorization answers "what are you allowed to do". In PayPal's API, authentication happens when a client exchanges credentials (client id and secret, or a login flow) for an OAuth 2.0 access token. That token proves the caller's identity for every subsequent request. Authorization happens on each call after that: the server checks the scopes attached to the token to decide whether this particular caller can, say, read transaction history versus actually issue a refund.

A junior engineer should be able to tell these apart in the status codes too. A missing, malformed, or expired token gets a 401, because the server can't even confirm who's calling. A token that's perfectly valid but lacks the right scope or permission gets a 403, because the server knows who you are and is refusing the action anyway. Mixing these two up in error handling is a common early mistake, and it makes debugging integration issues much harder for merchants calling the API.

A process is a running program with its own memory space, file descriptors, and OS-allocated resources. A thread is a unit of execution inside a process, and all threads in a process share that same heap and open file handles, but each thread gets its own stack and program counter. Because threads share memory, passing data between them is just reading and writing shared variables, which is fast but requires locks or other synchronization to avoid race conditions. Processes don't share memory, so they need explicit mechanisms like sockets, pipes, or shared memory segments to talk to each other.

In a service like a payment API running on the JVM, one process handles many concurrent requests using a thread pool, and those threads share the same connection pool and in-memory caches. Scaling out horizontally means running more processes or containers, each with its own isolated memory, not more threads in one process. It's also worth knowing that an unhandled exception in one worker thread can be caught and contained without affecting the rest of the process if the thread pool is set up correctly, whereas something like a native crash or an OutOfMemoryError takes the whole process down, threads and all.

Use a Boyer-Moore majority vote variant generalized to k candidates. Maintain at most k-1 candidate-count pairs. On each element, if it's an existing candidate increment its count; if there's an empty slot add it; otherwise decrement all counts by 1. After the pass, verify each candidate against the full array to confirm it genuinely exceeds n/k occurrences.

Reported from a PayPal SDE II round in 2024 on GeeksForGeeks. The follow-up was "what's the space complexity and can you reduce it?" The Boyer-Moore approach runs in O(n) time and O(k) space, which is optimal. Candidates who start with a hash map and frequency count (O(n) space) should be ready to explain why that's suboptimal when k is small.

import java.util.*;

public class MajorityElements {
    public static List<Integer> findMajority(int[] nums, int k) {
        Map<Integer, Integer> candidates = new HashMap<>();

        for (int num : nums) {
            if (candidates.containsKey(num)) {
                candidates.put(num, candidates.get(num) + 1);
            } else if (candidates.size() < k - 1) {
                candidates.put(num, 1);
            } else {
                List<Integer> toRemove = new ArrayList<>();
                for (Map.Entry<Integer, Integer> e : candidates.entrySet()) {
                    if (e.getValue() == 1) toRemove.add(e.getKey());
                    else candidates.put(e.getKey(), e.getValue() - 1);
                }
                toRemove.forEach(candidates::remove);
            }
        }

        // Verification pass
        Map<Integer, Integer> counts = new HashMap<>();
        for (int num : nums) counts.merge(num, 1, Integer::sum);

        List<Integer> result = new ArrayList<>();
        int threshold = nums.length / k;
        for (int c : candidates.keySet()) {
            if (counts.getOrDefault(c, 0) > threshold) result.add(c);
        }
        return result;
    }
}

Expand around center. For each index i, expand outward checking both odd-length palindromes (center at i) and even-length palindromes (center between i and i+1). Track the longest expansion found. This runs in O(n^2) time and O(1) space, which is the expected answer in interviews. Manacher's algorithm achieves O(n) but interviewers rarely expect it unless they ask for the optimal solution explicitly.

Reported in multiple OA write-ups from 2024 to 2025. Candidates who submitted the DP table approach (O(n^2) time and space) were asked in follow-up whether they could reduce space. The expand-around-center approach is the right answer to that question.

Modified binary search. At each step determine which half is sorted by comparing the midpoint to the left boundary. If the left half is sorted and the target falls within it, search left. Otherwise search right. One pass, O(log n).

Reported from a PayPal HackerRank OA and a separate phone screen. The standard follow-up: how does this change with duplicates? With duplicates you can't determine which half is sorted when nums[left] == nums[mid], so you fall back to incrementing left and decrementing right, which degrades to O(n) in the worst case.

DFS with backtracking from each cell that matches the first character. Mark cells as visited in-place (set to a sentinel like '#') before recursing, restore on backtrack. Return true as soon as the full word is matched. Pruning: if the remaining word is longer than remaining unvisited cells, abort early.

Reported in PayPal OA write-ups from 2025. The follow-up sometimes asks: "what if you need to find all occurrences?" That changes the logic: instead of returning true on first match, you collect all starting positions and continue searching.

Bottom-up DP starting from the second-to-last row. For each element, it equals its value plus the minimum of the two elements directly below it. After processing all rows from bottom to top, the answer is at the top element. Runs in O(n^2) time and O(n) space if you modify the triangle in place or use a 1D DP array of size n.

Reported from a 2025 PayPal OA. The in-place modification trick, using the triangle itself as the DP table, is the kind of space optimization that interviewers note positively in the OA scoring rubric.

Track four shrinking boundaries: top, bottom, left, right. Walk left to right across the top row, top to bottom down the right column, right to left across the bottom row, and bottom to top up the left column, moving each boundary inward by one after its pass. Stop once top exceeds bottom or left exceeds right. The whole traversal runs in O(rows × cols) time and needs no extra space beyond the output list.

Reported in PayPal OA write-ups on GeeksForGeeks as the second, harder question after an easier warm-up problem. Most point loss happens at the boundary checks, specifically forgetting to re-check top <= bottom before the final left-moving pass on a single remaining row, which either duplicates a row or walks off the matrix.

import java.util.*;

public class SpiralMatrix {
    public static List<Integer> spiralOrder(int[][] matrix) {
        List<Integer> result = new ArrayList<>();
        if (matrix.length == 0) return result;

        int top = 0, bottom = matrix.length - 1;
        int left = 0, right = matrix[0].length - 1;

        while (top <= bottom && left <= right) {
            for (int c = left; c <= right; c++) result.add(matrix[top][c]);
            top++;
            for (int r = top; r <= bottom; r++) result.add(matrix[r][right]);
            right--;
            if (top <= bottom) {
                for (int c = right; c >= left; c--) result.add(matrix[bottom][c]);
                bottom--;
            }
            if (left <= right) {
                for (int r = bottom; r >= top; r--) result.add(matrix[r][left]);
                left++;
            }
        }
        return result;
    }
}

A rectangle on the grid is fully determined by choosing 2 of the n+1 horizontal grid lines and 2 of the n+1 vertical grid lines. That's C(n+1, 2) ways to pick the horizontal pair times C(n+1, 2) for the vertical pair, so the total rectangle count is C(n+1, 2) squared. On a standard 8 by 8 board that's 36 squared, 1,296 rectangles. Squares are a separate count: the number of k by k squares on an n by n board is (n - k + 1) squared, summed over k from 1 to n.

Reported as a PayPal OA and phone screen brainteaser in 2025 candidate write-ups. It's less an algorithm problem than a combinatorics identity, and the interviewer is really checking whether you reach for the closed-form choose-2 pattern or start writing a brute-force loop over four coordinates, which works but signals you didn't recognize the structure underneath.

The standard approach with a HashSet: traverse from node p upward to the root, storing each node in a set. Then traverse from node q upward; the first node already in the set is the LCA. This runs in O(h) time and O(h) space where h is the height of the tree.

Reported from the PayPal SDE II round on GeeksForGeeks (2024). The interviewer specifically asked for space optimization. The O(1) space approach: find depths of p and q, bring the deeper node up to the same level, then move both upward in lockstep until they meet.

import java.util.*;

class TreeNode {
    int val;
    TreeNode parent, left, right;
    TreeNode(int val) { this.val = val; }
}

public class LCA {
    public TreeNode findLCA(TreeNode p, TreeNode q) {
        Set<TreeNode> visited = new HashSet<>();
        while (p != null) {
            visited.add(p);
            p = p.parent;
        }
        while (q != null) {
            if (visited.contains(q)) return q;
            q = q.parent;
        }
        return null;
    }
}

Level order BFS, and at each level the last node dequeued is the one visible from the right side. Track the level size before the inner loop the same way the level-width question above does, and keep only the final node's value from each level. A DFS alternative visits the right child before the left child and records a node's value only the first time its depth is reached; both approaches run in O(n) time.

Reported from PayPal technical phone screens as a quick follow-up after an easier warm-up tree question. The DFS variant trips up candidates who default to visiting left before right out of habit and have to rewrite the recursion order once the interviewer points it out.

Standard BFS by level, but alternate the direction the collected values get appended in: left to right on even levels (counting the root as level 0), right to left on odd levels. The simplest implementation runs the normal BFS and reverses every other level's list before appending it to the result, rather than trying to traverse in alternating directions during the BFS itself.

Reported in PayPal OA and onsite write-ups as a variant of the plain level order traversal question, distinct from the level-width problem covered above since it asks for the actual node values in alternating order, not just a count per level. A common mistake is reversing every level instead of every other one, so testing against a 4 or 5 level tree before submitting is worth the extra minute.

from collections import deque

def zigzag_level_order(root):
    if not root:
        return []
    result, queue, left_to_right = [], deque([root]), True
    while queue:
        level = deque()
        for _ in range(len(queue)):
            node = queue.popleft()
            if left_to_right:
                level.append(node.val)
            else:
                level.appendleft(node.val)
            if node.left:
                queue.append(node.left)
            if node.right:
                queue.append(node.right)
        result.append(list(level))
        left_to_right = not left_to_right
    return result

HashMap for O(1) key lookup plus a doubly linked list for O(1) recency ordering. The list head holds the most recently used entry; the tail holds the eviction candidate. On get, move the accessed node to the head. On put, if the key exists update and move to head; if new and at capacity evict the tail node and remove its key from the map before inserting.

Reported from a PayPal coding round and the OA. Java candidates are sometimes asked to implement this without using LinkedHashMap even though LinkedHashMap with accessOrder=true does this in three lines. The interviewer wants to see that you understand the mechanism, not just the shortcut.

import java.util.*;

class LRUCache {
    private final int capacity;
    private final Map<Integer, Node> map = new HashMap<>();
    private final Node head = new Node(0, 0);
    private final Node tail = new Node(0, 0);

    static class Node {
        int key, val;
        Node prev, next;
        Node(int key, int val) { this.key = key; this.val = val; }
    }

    public LRUCache(int capacity) {
        this.capacity = capacity;
        head.next = tail;
        tail.prev = head;
    }

    public int get(int key) {
        Node node = map.get(key);
        if (node == null) return -1;
        remove(node);
        insertFront(node);
        return node.val;
    }

    public void put(int key, int value) {
        Node node = map.get(key);
        if (node != null) { remove(node); node.val = value; insertFront(node); }
        else {
            if (map.size() == capacity) {
                Node lru = tail.prev;
                remove(lru);
                map.remove(lru.key);
            }
            Node newNode = new Node(key, value);
            insertFront(newNode);
            map.put(key, newNode);
        }
    }

    private void remove(Node n) { n.prev.next = n.next; n.next.prev = n.prev; }
    private void insertFront(Node n) { n.next = head.next; n.prev = head; head.next.prev = n; head.next = n; }
}

An operation is idempotent if applying it multiple times produces the same result as applying it once. In payments: if a charge request times out and the client retries, an idempotent payment API guarantees that the retry does not create a second charge. Implementation: the client generates a unique idempotency key (UUID) per payment intent and sends it in the request header. The server stores the key with the response on first execution. On retry, the server returns the stored response without re-executing. The key lookup and response store must be atomic to handle concurrent retries.

PayPal's public API documentation explicitly requires idempotency keys for payment endpoints. Interviewers consider this basic professional knowledge for any fintech backend role.

Atomicity: a transaction either completes fully or not at all. Consistency: data moves from one valid state to another. Isolation: concurrent transactions produce the same result as if they ran serially. Durability: committed transactions survive crashes.

Where they break down: a single RDBMS can give you all four, but distributing a transaction across two databases requires two-phase commit, which has latency cost and is unavailable during coordinator failure. Most distributed payment systems relax isolation (using eventual consistency for non-critical reads) and implement atomicity at the application level via sagas with compensating transactions. The ledger itself, the source of truth for balances, typically runs on a strongly consistent relational database. Downstream systems (analytics, notification history) tolerate eventual consistency.

HashMap is not synchronized and should not be shared across threads without external locking or use of ConcurrentHashMap. Hashtable is fully synchronized but coarse-grained, every operation locks the whole table. ConcurrentHashMap uses segment-level locking and is the right choice for most concurrent read-heavy workloads.

In payment systems, shared mutable state in-process is usually the wrong design. Correctness comes from the database transaction, not from in-memory synchronization. But caches (idempotency key caches, rate limit counters, session stores) are shared and need thread-safe access. Use ConcurrentHashMap for in-JVM caches, Redis with atomic operations for distributed caches.

A circuit breaker wraps calls to a downstream service and tracks failure rate over a rolling window. In closed state (normal), calls pass through. If failure rate exceeds a threshold, the breaker opens: subsequent calls fail fast without hitting the downstream service, giving it time to recover. After a timeout, the breaker moves to half-open: a probe request goes through. If it succeeds, the breaker closes. If it fails, it opens again.

At PayPal, circuit breakers protect critical payment paths from cascading failures. If the fraud scoring service starts timing out, a circuit breaker allows the payment system to either fail safe (decline the transaction) or degrade gracefully (approve below a risk threshold with extra logging) rather than holding connections open and causing the payment service itself to back up. Reported as a PayPal SDE II system design question.

Use a window function. RANK() or DENSE_RANK() partitioned by user_id and ordered by amount descending. Then filter where the rank equals 2. With DENSE_RANK(), ties in the first position still yield rank 2 for the next distinct amount. With RANK(), tied first entries jump straight to rank 3, which may produce no rank-2 result for tied users.

PayPal uses SQL more than most tech companies of its size. The technical deep-dive round for data-adjacent roles, and sometimes for backend roles, includes multi-table join questions, window functions, and transaction schema design. Candidates who haven't touched SQL beyond simple selects are sometimes caught off guard.

-- Second-highest transaction amount per user
SELECT user_id, amount
FROM (
    SELECT
        user_id,
        amount,
        DENSE_RANK() OVER (PARTITION BY user_id ORDER BY amount DESC) AS rnk
    FROM transactions
) ranked
WHERE rnk = 2;

Optimistic locking assumes conflicts are rare. Read a row along with its version number, and let the write succeed only if the version hasn't changed since the read, a compare-and-swap at the database level, retrying on conflict. Pessimistic locking takes the lock up front (SELECT ... FOR UPDATE) and blocks every other writer until the transaction commits. Optimistic locking scales better under low contention because it never holds a lock across a network round trip. Pessimistic locking wins when contention is high or a transaction needs several dependent reads before deciding whether to write at all, since a retry storm under heavy contention can waste more work than a short block would have cost.

Per-account balance updates are the classic contention point in a payments system, two withdrawals racing against the same account at the same instant. PayPal's ledger design leans toward serializing writes per account through a single shard owner rather than relying purely on optimistic retries, because a failed optimistic write on a balance check has to re-validate a business rule (sufficient funds) before retrying, not just blindly resubmit the same write.

Structure: name the specific mistake, the actual impact (a number is better than "significant"), what you did to contain it, what the root cause turned out to be (not the symptom), and what structural change you made so it wouldn't happen again. "I added more testing" is not a structural change. "We added a required database migration review step to the deploy checklist and I wrote the runbook" is.

PayPal interviewers reported on Glassdoor push on the root cause component most consistently. Candidates who stop at "I fixed the bug and wrote a test" are asked: "But why did the bug get through in the first place?" Have a level-two answer ready.

Pick a story where you had specific evidence, raised it through a professional channel, and either changed the decision or understood why you were overruled. Avoid stories where you were right and management was stubbornly wrong and the project failed. Interviewers read that as a lack of professional judgment about when to push and when to commit.

The stronger story shape: you disagreed, you presented data or a prototype to back your position, the decision went against you, and you found a way to address your concern within the chosen direction anyway, and in retrospect the decision was reasonable even if you'd have made a different call. That story shows judgment, not just confidence.

Be specific about the timeline and what made it hard. The easier version of this story, "we switched frameworks and I read the docs," doesn't land well. The harder version names what you had to give up (certainty, code you'd already written, an approach you'd advocated for), describes how you got oriented fast, and shows a concrete outcome. If you changed course mid-sprint and still shipped on time, say the specific date and what you delivered.

PayPal is large enough that most high-impact work crosses team boundaries. Interviewers want to know whether you lead by authority or by influence. Stories where you called a meeting and issued tasks are weaker than stories where you aligned stakeholders by identifying the shared goal, unblocked a dependency, or built the shared tooling that made collaboration easier. Name the teams, describe the communication mechanism you used, and be specific about what would have broken down without your contribution.

Name the actual decision you made without waiting for full clarity, what information you did have at the time, and how you checked that your direction was reasonable before committing further, a quick prototype, an early stakeholder check-in, a scoped experiment. Skip the version where the ambiguity happened to resolve itself in your favor. Interviewers are listening for a repeatable process for reducing ambiguity, not a story where things just worked out.

PayPal's hiring manager round specifically asks about handling ambiguity, per multiple candidate reports, since cross-team platform work rarely starts with a complete spec. The stronger answers describe checking in early and often rather than disappearing for two weeks to build what you assumed was the right thing.

The shape that lands: you brought data or a working prototype instead of an opinion, you framed the ask around the other team's incentives rather than your own, and you left room for them to adjust the approach instead of demanding your exact solution. Stories where you escalated straight to a manager read as a lack of peer-level influence, not a strength.

This maps to PayPal's stated Collaboration value and often shows up disguised as a more generic prompt, "tell me about a time you worked cross-functionally" is frequently this question in a different wrapper. Name the other team specifically and the concrete change that resulted from your side of the conversation.

Start with requirements: functional (initiate payment, check status, refund, currency conversion), non-functional (high availability, strong consistency for the ledger, exactly-once processing, audit trail for regulators). Fifty million daily transactions is roughly 580 TPS average, with peak bursts significantly higher, design for 5,000 to 10,000 TPS peak.

Core architecture: API gateway for auth and rate limiting, payment orchestration service that breaks the payment into discrete steps (authorization, settlement, ledger update), a double-entry accounting ledger stored in a strongly consistent relational database (Postgres with read replicas for reporting), and an async event bus (Kafka) for downstream consumers like notifications and fraud scoring. Idempotency keys stored in Redis with a TTL ensure retries don't execute twice. The ledger uses append-only writes: you never update a row, you write a new debit and credit entry. This makes the audit trail automatic and simplifies rollback.

Failure modes the interviewer will probe: what happens if the payment orchestrator crashes after debiting the sender but before crediting the receiver? Saga pattern with compensating transactions, or two-phase commit if the databases support it. Two-phase commit has higher latency but stronger guarantees. PayPal's internal architecture (as disclosed in engineering blog posts from 2022 to 2024) uses distributed sagas with explicit compensation logic for cross-service consistency.

# Idempotency key handler (simplified)
import redis
import json

r = redis.Redis(host='localhost', port=6379, db=0)
IDEMPOTENCY_TTL = 86400  # 24 hours

def process_payment_idempotent(idempotency_key: str, payment_data: dict) -> dict:
    cached = r.get(f"idem:{idempotency_key}")
    if cached:
        return json.loads(cached)  # return stored result, do not re-execute

    result = execute_payment(payment_data)  # actual payment logic

    # Store with TTL; NX ensures only the first write wins (atomic)
    r.set(f"idem:{idempotency_key}", json.dumps(result), ex=IDEMPOTENCY_TTL, nx=True)
    return result

def execute_payment(payment_data: dict) -> dict:
    # debit sender, credit receiver, write ledger entries
    # returns {"transaction_id": ..., "status": "COMPLETED", ...}
    pass

True exactly-once across a distributed system without a global two-phase commit isn't really achievable, so the practical goal is effectively-once from the consumer's point of view: duplicates can still arrive, but processing them a second time has no visible effect. The standard way to get there is to record that an event has been handled in the same database transaction as the side effect it triggers, usually with a unique constraint on an event id or a composite key like payment_id plus event_type. If the consumer crashes after committing the side effect but before committing the Kafka offset, it reprocesses that message on restart, and the unique constraint turns the second write into a harmless no-op instead of a duplicate.

On the producer side, enabling the idempotent producer stops duplicate writes to the topic itself caused by retries after a network blip, and transactional producers let you atomically consume from one topic and produce to another as part of the same commit, which matters for chained flows like "payment authorized" triggering "settlement requested."

enable.idempotence=true
acks=all
max.in.flight.requests.per.connection=5

The gotcha most people get wrong is ordering: committing the Kafka offset before the downstream write is durable is a classic at-most-once bug that can silently drop a payment event on a crash. Committing the side effect first and the offset second is safer, but it means every consumer has to tolerate reprocessing its last uncommitted batch on restart, which is exactly what the unique-constraint pattern above is for.

INSERT INTO events_processed (event_id, payment_id, processed_at)
VALUES ($1, $2, now())
ON CONFLICT (event_id) DO NOTHING;

Two-phase commit doesn't hold up well across services owned by different teams with their own databases, the coordinator becomes a single point of failure and it locks resources across a network call, which isn't workable at PayPal's throughput. I'd model the refund as a Saga: a sequence of local transactions, each with a matching compensating transaction, coordinated either by a central orchestrator or through choreographed events. Step one reserves the refund amount in the ledger and marks it pending. Step two calls the bank or card network to actually move the money. Step three, on success, finalizes the ledger entry and emits a "refund completed" event that the notification service consumes.

If step two fails, the compensating action reverses step one with an explicit reversal entry, never a silent delete, and a "refund failed" event goes out instead. The orchestrator has to persist which step a given saga is on, so that if the orchestrator itself crashes mid-refund, a recovery process can pick up from the last known step rather than leaving the refund stuck. The hardest part is making the compensating actions themselves idempotent and safe to run even when you're not fully certain the original step completed, because "no response yet" from the bank and "confirmed failure" are different states, and you can't safely compensate a step you don't know actually ran.

First I'd separate what the customer perceives from what actually happened in PayPal's ledger, because a very common cause is the bank showing a pending authorization hold and a separate posted charge on the statement, which looks like two charges but is one transaction settling normally. I'd pull the transaction id from the ticket and check whether there are genuinely two distinct ledger entries with the same amount and merchant close together in time, or just one transaction the bank is displaying oddly.

If there really are two entries, I'd look at the client retry path next. Did the checkout page fire a second call because the submit button wasn't disabled after the first click, did the client time out and retry the request without an idempotency key, or was an idempotency key present but not actually enforced atomically on the server. I'd check the logs for two requests with the same idempotency key or client-generated request id in a short window, and I'd check whether the server's idempotency check was a proper unique constraint versus a select-then-insert, since the latter is a classic race that only surfaces under load. Once the root cause is confirmed, the fix is enforcing the idempotency key with a database constraint, disabling the client's submit button on click, or both, plus an immediate refund and a reversal entry for the duplicate charge.

First I'd confirm it's an actual leak and not just an undersized heap for peak load, since bursty payment traffic can look identical to a leak until you watch it across a few cycles. If heap usage after each full GC keeps climbing cycle over cycle instead of settling back to a stable baseline, that's a real leak rather than a capacity problem.

Once confirmed, I'd capture a heap dump under load and load it into a tool like Eclipse MAT to check the dominator tree, specifically which object type is retaining the most memory and what's keeping it reachable from a GC root.

jmap -dump:live,format=b,file=heap.bin <pid>

In payment services, the usual suspects are an unbounded in-memory cache of transaction state with no eviction, a ThreadLocal set per request that never gets cleared and so accumulates on threads that live forever in a pool, event listeners registered on a long-lived bus that are never deregistered when a request finishes, or an HTTP client that isn't pooled correctly and keeps accumulating open sockets and their buffers. Once I find the retaining object, I'd correlate it with a recent deploy, since a service that was stable before almost always traces the leak to one of the last few releases, and I'd confirm the fix under a load test that mimics real peak traffic before shipping it wider. A flat heap graph over a few hours at replicated peak load is the only real proof, a quick smoke test won't catch it.

Keep two stacks in lockstep. The main stack holds every pushed value normally. The min stack pushes a new value only when it's less than or equal to the current minimum, so its top is always the running minimum. On pop, pop from both stacks if the popped value matches the min stack's top; otherwise pop only the main stack. getMin becomes a single peek at the min stack's top.

Reported as a live coding warm-up before the harder LRU cache question in several PayPal onsite loops. The follow-up worth preparing: how would you do this with O(1) extra space instead of a second stack? Store the difference between each pushed value and the current minimum instead of the raw value, and reconstruct the minimum algebraically on pop. It works but reads far less clearly, and most interviewers are satisfied once you can explain the tradeoff out loud.

import java.util.*;

class MinStack {
    private final Deque<Integer> stack = new ArrayDeque<>();
    private final Deque<Integer> minStack = new ArrayDeque<>();

    public void push(int val) {
        stack.push(val);
        if (minStack.isEmpty() || val <= minStack.peek()) {
            minStack.push(val);
        }
    }

    public void pop() {
        int val = stack.pop();
        if (val == minStack.peek()) {
            minStack.pop();
        }
    }

    public int top() { return stack.peek(); }
    public int getMin() { return minStack.peek(); }
}

Define resources: POST /payments to initiate, GET /payments/{id} for status, PATCH /payments/{id} for updates (limited fields), POST /payments/{id}/refunds for refunds as a sub-resource. Return 201 with a Location header on creation, 200 with the current state on retrieval, 202 Accepted for async operations where the final state isn't yet known.

Reported from the managerial round at PayPal SDE II. The interviewer specifically asked about idempotency at the API layer. The answer: the client sends a unique idempotency key in the request header (X-Idempotency-Key), the server stores the key with the response, and subsequent requests with the same key return the cached response rather than executing again. This prevents double charges on network retries.

Payment events (completed, failed, refunded) publish to Kafka. Notification service consumes, determines preferred channel per user (push, email, SMS), and dispatches. The hard problem: exactly-once delivery is impossible at this layer. Design for at-least-once with deduplication on the consumer side. Each notification has a unique event ID; consumers check a Redis set of sent event IDs before dispatching and mark as sent after. TTL on the Redis set prevents unbounded growth.

Channel-specific concerns: push notifications have low latency but require APNs/FCM integration and handle device token staleness (tokens expire; the system needs to update or drop dead tokens). Email delivery is asynchronous; use SendGrid or SES with webhook callbacks for delivery status. SMS is the most reliable but most expensive. Priority ordering: push first, email fallback, SMS only for high-value events or explicit user preference.

Token bucket per API key. Each key gets a bucket with a fixed capacity that refills at a steady rate; a request consumes one token, and a request with no tokens available gets rejected with a 429 and a Retry-After header. The bucket state has to live somewhere every API gateway instance can read and write atomically. A plain in-process counter per instance would let the effective limit multiply by however many gateway nodes happen to be running.

Redis is the usual answer: store the token count and last-refill timestamp per key, and update both atomically inside a Lua script so a burst of concurrent requests can't all read stale token counts and all get approved. Sliding window counters, tracking request timestamps in short slices over the last minute, avoid the token bucket's tendency to allow a full burst right at the boundary between two fixed windows. PayPal interviewers sometimes ask specifically why a naive fixed-window counter under-protects against burst traffic at the window edge.

Reported at the system design round for backend and platform roles, usually as a shorter, more contained design problem compared to the full payment processing or fraud detection prompts. It pairs naturally with the idempotency discussion covered earlier on this page, since a client that gets rate-limited and retries needs the same idempotency-key handling to avoid a duplicate charge once it's allowed through.

import time
import redis

r = redis.Redis(host='localhost', port=6379, db=0)

def allow_request(api_key: str, capacity: int = 100, refill_per_sec: float = 10.0) -> bool:
    now = time.time()
    bucket_key = f"ratelimit:{api_key}"

    # Lua script keeps read-refill-write atomic across gateway instances
    script = """
    local tokens = tonumber(redis.call('HGET', KEYS[1], 'tokens') or ARGV[1])
    local last = tonumber(redis.call('HGET', KEYS[1], 'last') or ARGV[3])
    local elapsed = ARGV[3] - last
    tokens = math.min(tonumber(ARGV[1]), tokens + elapsed * tonumber(ARGV[2]))
    local allowed = 0
    if tokens >= 1 then
        tokens = tokens - 1
        allowed = 1
    end
    redis.call('HSET', KEYS[1], 'tokens', tokens, 'last', ARGV[3])
    redis.call('EXPIRE', KEYS[1], 3600)
    return allowed
    """
    result = r.eval(script, 1, bucket_key, capacity, refill_per_sec, now)
    return result == 1

Use the transactional outbox pattern: when a payment's status changes, write the resulting webhook event to an outbox table in the same database transaction as the state change itself, so the event can never get lost between "the payment updated" and "the notification got queued." A separate worker pool polls the outbox (or consumes a change-data-capture stream off it) and delivers each event via an HTTP POST to the merchant's registered endpoint, signed with an HMAC so the merchant can verify the payload actually came from PayPal and wasn't spoofed.

Delivery isn't guaranteed to succeed on the first attempt, a merchant's endpoint might be down for a deploy. Retry with exponential backoff and jitter, move an event to a dead-letter queue after a fixed number of attempts, and give merchants a dashboard showing delivery history with a manual replay button. This is a different problem from the internal user notification system covered above: merchants need signature verification, a much longer retry window (days rather than minutes), and an audit trail they can inspect themselves.

Three stages: feature computation, scoring, and action. Feature computation runs at two speeds: real-time features (user's transaction frequency in the last 5 minutes, device fingerprint match, IP geolocation) computed in the hot path using Redis counters and a feature store; batch features (30-day spending patterns, merchant risk scores) precomputed and stored in a low-latency key-value store. Scoring: a rules engine handles obvious cases (transaction from a new country followed by a large transaction 10 minutes later), an ML model handles ambiguous patterns. The rules engine runs in microseconds; the ML model budget is roughly 50 to 80ms for a sub-100ms total latency target.

Action layer: approved, declined, or sent to step-up authentication (OTP, 3D Secure). Human review queue for high-value ambiguous cases. All decisions, including approved ones, write to an audit log that feeds back into the ML training pipeline. Graph-based analysis (identifying fraud rings where multiple accounts share a device or IP) runs as a background job, not in the real-time path, because graph traversal at PayPal's scale cannot fit in a sub-100ms budget.

PayPal operates across 200+ countries and 25 currencies. Interviewers at this company will ask about geographic data residency: transaction data for EU users must stay in EU regions under GDPR. Design your data sharding around user geography, not hash-based partitioning, if compliance is a first-class requirement.

Data model: one ledger account per currency per user. Never store a single balance field; store a running ledger of credit and debit entries and compute the balance as the sum. This is the double-entry accounting model. It handles rollbacks naturally: a failed transaction produces a compensating credit entry that reverses the debit, and the audit trail is preserved.

Currency conversion: fetch exchange rates from a rate service (cache with short TTL, 1 to 5 minutes, since rates move). Apply conversion at transaction time, lock in the rate, write it to the ledger entry as a field. Never recompute historical rates. For holding multi-currency balances, the user has a balance per currency; conversion from wallet A to wallet B is two ledger entries plus an exchange rate record.

Concurrency: two users sending to the same recipient simultaneously. Use optimistic locking (check-and-increment with versioning) or serialize through a single account's write path. At PayPal's scale, per-account serialization via consistent hashing to a single shard owner is a common pattern.

Model the dispute as its own state machine, separate from the original transaction: opened, evidence_submitted, under_review, resolved_merchant, resolved_buyer, closed. Every transition writes an immutable event to an append-only dispute log, the same pattern as the primary ledger covered earlier, rather than overwriting a mutable status field. That matters because a chargeback decision can itself get reversed on appeal (a "second presentment" in card network terms), and an append-only log turns that reversal into just another event instead of a data-integrity problem.

Funds handling: hold the disputed amount in a reserve ledger entry instead of reversing the original transaction immediately. The original transaction stays intact for audit purposes; the reserve entry moves once the dispute resolves. The workflow also has to track the card network's own SLA clock, roughly 7 to 45 days depending on the dispute reason code, which means a scheduled job checking for approaching deadlines and escalating, not just a reactive system waiting on network webhooks.

This shows up more at senior and staff PayPal loops than at SDE2, since it touches regulatory reporting (Regulation E in the US covers electronic funds transfer disputes) as much as it touches distributed systems. Interviewers want the double-entry, append-only instinct applied consistently, not a special-cased mutable dispute table bolted onto an otherwise immutable ledger.

Every money movement, a payment, a refund, a fee, a currency conversion, has to post at least two ledger entries: a debit on one account and a matching credit on another, and the entries in a transaction must always net to zero. The foundation is an append-only ledger table that is never updated or deleted in place, only reversed with a new offsetting entry, plus an application-level invariant (or database constraint) that rejects any transaction where debits don't equal credits before it commits. I'd write all entries for one transaction inside a single database transaction where possible, and use a Saga with compensating entries when the write spans multiple services, so a partial posting never sits half-written.

Balances shouldn't be recomputed by summing every historical entry on every read, that gets expensive fast at PayPal's volume, so I'd maintain a running balance per account as a materialized value updated incrementally with each posting, then reconcile it against the raw ledger sum in a nightly batch job. That job is the real safety net: it flags any account, or the ledger as a whole, where debits and credits don't sum to zero, because a bug anywhere in the pipeline silently breaks money conservation and you want to catch a one-cent discrepancy before it becomes a systemic one. Idempotency keys tied to the originating external event (a card network callback, a webhook retry) stop the same real-world event from posting duplicate entries when it's redelivered.