Mastercard Software Engineer Case Interview: Real-Time Payment Authorization Service

This case simulates designing and iterating on a high-volume, low-latency payment authorization microservice within Mastercard’s network. It reflects Mastercard’s security-first engineering standards, global scale, and the company’s Decency Quotient (DQ) emphasis on responsible innovation, collaboration, and customer trust. Scenario prompt (given at start): You are tasked with designing an Authorization API that receives card-present and card-not-present transactions from acquirers/merchants, performs initial validations and token handling, enriches with risk/fraud signals, routes to issuers (or issuer processors), and returns an approve/decline/soft-decline decision. The service must be globally distributed, secure by design, and operable under strict SLAs. Business and technical constraints to clarify and address: - Scale and latency: target p99 end-to-end decisioning under ~150 ms in steady state; design for bursty traffic (e.g., major sales events) at ≥10k TPS per region with multi-region failover. - Availability and resilience: ≥99.99% service availability, active-active across regions; graceful degradation, circuit breaking, and backpressure when downstreams (fraud, issuer, token vault) are impaired. - Security and compliance: strong data minimization, PCI-DSS scope awareness, PAN/token flows, HSM-backed encryption, key rotation, auditability; clear trust boundaries between tokenization, authorization, and analytics. - Correctness: idempotency keys for retries, exactly-once or effectively-once semantics, deterministic decision logs, reconciliation hooks for settlement/chargebacks. - Risk and fraud: plan for synchronous risk scoring (e.g., rules + ML via sidecar service) with timeouts and fallbacks; soft-decline handling (e.g., step-up auth/3DS flows) where applicable. - Observability and SLOs: define golden signals (latency, error/decline codes, issuer timeouts), structured decision logs, traceability across services, and error budgets. - Data governance: PII handling, retention windows per region, right-to-erasure hooks, and regional data residency considerations. What interviewers expect you to cover: 1) API and contract design: request/response schema (masked PAN or network token, merchant/acquirer IDs, amount/currency, MCC, auth type), idempotency strategy, versioning, and backward compatibility. 2) System architecture: ingress (global anycast/load balancer), multi-region active-active, stateless auth service nodes, tokenization boundary, issuer routing component, async event bus (e.g., for audit/analytics), and cache choices (e.g., BIN ranges, merchant config, risk features). 3) Security-by-design: HSM integration for crypto, secrets management, least-privilege service roles, data-at-rest/in-transit encryption, and threat modeling (e.g., replay, tampering, credential stuffing on merchant side). 4) Resiliency strategies: timeouts/retries with jitter, bulkheads, hedged requests for issuer routing, partial responses, rate limits by merchant/BIN, load shedding and maintenance modes. 5) Testing and rollout: contract tests with acquirers, synthetic traffic, golden path/chaos experiments, canary + blue/green, zero-downtime schema changes, and rollback plan. 6) Operability: runbooks, on-call handoffs, dashboards/alerts mapped to SLOs, incident response with blameless postmortems aligned to Mastercard’s DQ. 7) Product and DQ alignment: trade-off discussion balancing customer impact, fairness, privacy, and regulatory requirements; collaboration with risk, compliance, and issuer partners. Format and timing (typical 70 minutes): - 5 min: context setup and clarifying questions (customer, acquirer, issuer, and network boundaries). - 20 min: API + high-level architecture (draw components, data flows, trust zones, and regional topology). - 20 min: deep dives (choose two): a) security/PCI scope & tokenization, b) resiliency under issuer slowness, c) risk scoring path and timeouts, d) idempotency/exactly-once. - 15 min: observability, SLOs, deployment, and testing strategy; discuss failure drills and rollback. - 10 min: behavioral wrap reflecting Mastercard’s DQ (stakeholder alignment, ethical decisions, incident handling example). Evaluation rubric (what strong answers demonstrate): - Customer and compliance awareness: clear reasoning about PCI scope, data minimization, and privacy. - Correctness and reliability: crisp idempotency model, deterministic auditing, and safe retry semantics. - Performance and scalability: sound partitioning/caching, multi-region strategy, and realistic latency budgeting. - Security rigor: explicit crypto/HSM choices, key rotation, and threat mitigations. - Operability and culture: SLO-driven design, thoughtful incident practices, and collaborative communication consistent with Mastercard’s DQ. Tools/tech examples (not prescriptive): Java/Kotlin + Spring Boot, gRPC/REST, Kafka for events, Redis for hot config/BIN cache, Postgres/CockroachDB for config and audit, Kubernetes, HSM/Vault, OpenTelemetry for tracing.