Section C · Coding

Practice Problems

Ten payments-PM problems — product spec, SQL, estimation, design. Try each on a timer. Open the drill answer only after you've taken a shot.

How to use this chapter

  • Set a timer per problem: 12-15 minutes for spec/design, 8-10 for SQL.
  • Write a structure first, fill in detail second. Senior interviewers care about the frame.
  • Each problem has a drill with the answer. Open only after attempting.

P1 · Spec UPI AutoPay for recurring DCA crypto buys (India)

Prompt: The company wants to let Indian customers schedule a recurring weekly crypto buy via UPI AutoPay. Spec it.

Drill answer

Frame: Goal → users → flow → mandate UX → rail mechanics → KPIs → risks.

  • Goal: drive recurring deposits and lower per-purchase cost via UPI; build LTV vs one-shot.
  • Users: retail Indian customers; KYC-completed; have a UPI-linked bank account.
  • Flow: user selects amount + frequency + cap → app creates UPI mandate via NPCI flow → user PINs to authorise mandate in their PSP app → daily/weekly debit triggered by the company backend; PSP app may show confirmation; auto-credit fiat → market-order crypto.
  • Mandate UX: explicit max amount per debit, frequency, expiry. Cancellation path same screen as setup. Clear copy about NPCI mandate framework.
  • Rail mechanics: NPCI mandate creation → debit on schedule → reconcile via PSP webhook → idempotency on intent_id. Handle partial debits and failures explicitly.
  • KPIs: mandate creation rate, mandate execution success rate, recurring TPV, churn (mandate cancellation rate), regulatory complaint rate.
  • Risks: NPCI/RBI posture on crypto — handle policy reversibility; mandate failure UX must not be silent; ensure Travel Rule and AML monitor recurring patterns.
  • What I'd cut for v1: variable amount (start fixed); multiple instruments; auto-pause on insufficient funds.

P2 · Design an A/B for adding PIX as default in Brazil

Prompt: You currently offer card-only checkout in Brazil. Engineering has shipped PIX integration. Design the experiment to decide whether to default PIX.

Drill answer
  • Hypothesis: defaulting PIX lifts deposit completion ≥ X pp without harming TPV per deposit.
  • Unit: user (sticky assignment).
  • Variants: A = card first / PIX collapsed; B = PIX first / card collapsed.
  • Sample: power for 1.5pp lift at 80% power, two-sided; baseline ~50% deposit-from-intent.
  • Primary: deposit-from-intent conversion.
  • Secondary: avg deposit value, time-to-availability, cost-per-success, chargeback rate.
  • Guardrails: fraud rate, support contacts per 1k deposits.
  • Run for ≥ 2 weeks; pre-register cuts: new vs returning, mobile vs web, amount band.
  • Decision rule: ship if primary lift positive at significance AND no guardrail regression > threshold AND blended cost-adjusted revenue per user up.
  • Trap: don't credit PIX for absent chargebacks — disaggregate.

P3 · SQL — weekly first-attempt AAR by issuer bank, last 4 weeks

Prompt: Write the query.

Drill answer 
WITH first_attempts AS (
  SELECT DISTINCT ON (payment_intent_id)
    payment_intent_id, issuer_name, status, created_at
  FROM auth_attempts
  WHERE created_at >= NOW() - INTERVAL '4 weeks'
  ORDER BY payment_intent_id, attempt_seq ASC
)
SELECT
  DATE_TRUNC('week', created_at) AS wk,
  issuer_name,
  COUNT(*) AS attempts,
  COUNT(*) FILTER (WHERE status='approved') AS approved,
  ROUND(100.0 * COUNT(*) FILTER (WHERE status='approved') / COUNT(*), 2) AS aar_pct
FROM first_attempts
GROUP BY wk, issuer_name
HAVING COUNT(*) >= 100
ORDER BY issuer_name, wk;

P4 · Size the lift from adding PIX in Brazil

Prompt: Brazil currently 100% card. PIX is cheaper and faster. Estimate the lift to GTV from adding PIX as a default option.

Drill answer
  • Brazil deposit intents/month: I (clarify; assume 500k).
  • Current deposit conversion: 55%. Successful deposits/month: 275k. Avg deposit: R$ 350. Monthly GTV: R$ 96M.
  • PIX expected conversion: 70% (cleaner UX + zero issuer-decline path). New successful deposits/month: 350k. Monthly GTV: R$ 122M. Delta: +R$ 26M (+27%).
  • Cost delta: card cost ~ 3% all-in vs PIX ~ 0.3% all-in. Savings: 2.7% × R$ 122M = R$ 3.3M/mo.
  • Caveats: PIX may attract different cohort (lower-value); chargeback loss reduces (card chargeback ~50 bps eliminated on PIX share); MED returns add a small cost; integration + on-call.
  • State the assumption sensitivity: ±10% conversion ↔ ±R$ 10M monthly.

P5 · Cost-per-successful-deposit query

Drill answer 
WITH per_intent AS (
  SELECT payment_intent_id,
    MIN(rail) AS rail,
    MIN(geo)  AS geo,
    BOOL_OR(status='approved') AS approved,
    SUM(fee_interchange_c + fee_scheme_c + fee_psp_c + fee_xborder_c + fee_fx_c) AS fees_c
  FROM auth_attempts
  WHERE created_at >= NOW() - INTERVAL '30 days'
  GROUP BY payment_intent_id
),
dispute_cost AS (
  SELECT payment_intent_id, SUM(amount_c) AS dispute_c
  FROM disputes
  WHERE status IN ('lost','accepted')
    AND filed_at >= NOW() - INTERVAL '60 days'
  GROUP BY payment_intent_id
)
SELECT
  p.rail, p.geo,
  COUNT(*) FILTER (WHERE p.approved) AS successes,
  SUM(p.fees_c) FILTER (WHERE p.approved) + COALESCE(SUM(d.dispute_c),0) AS total_cost_c,
  ROUND(
    (SUM(p.fees_c) FILTER (WHERE p.approved) + COALESCE(SUM(d.dispute_c),0))::numeric
    / NULLIF(COUNT(*) FILTER (WHERE p.approved),0),
    2
  ) AS cost_per_success_c
FROM per_intent p
LEFT JOIN dispute_cost d USING (payment_intent_id)
GROUP BY p.rail, p.geo
ORDER BY p.rail, p.geo;

P6 · Design a vendor-selection scorecard for a new acquirer in Mexico

Drill answer
CriterionWeightWhat you score
Coverage (MX schemes, OXXO, SPEI)25%% of target rails supported in-market
Cost (all-in, blended)20%Modeled at our volume mix
Reliability (uptime, p99 latency)15%SLA + reference checks
AAR baseline on similar merchants15%Reference data; sandbox testing
Compliance / licensing10%Licensing posture, sub-processors, audits
Integration speed5%Engineering time-to-go-live estimate
Partnership cadence5%Account team, roadmap influence
Concentration risk5%How dependent are they on a single bank?

Two-vendor recommendation typical: primary + secondary failover.

P7 · Spec the on-ramp flow for a new emerging market (pick one)

Prompt: The company wants to enter the Philippines. Spec the v1 on-ramp.

Drill answer
  • Goal: first PHP-denominated on-ramp; new-market activation.
  • Rails: GCash (wallet-first), Maya, InstaPay bank transfer. Defer card v1 — issuer/MCC posture uneven.
  • Partner: local PSP with BSP licensing (Xendit, PayMaya, or similar).
  • Flow: user picks PHP → wallet/InstaPay → redirected to partner UX → confirms → callback to the company → crypto credited at locked quote.
  • KYC overlay: BSP requires KYC tiered; integrate with our existing flow.
  • FX: locked quote with 60-second window; show breakdown.
  • KPIs: conversion intent→success, time-to-availability, cost-per-success, support contacts.
  • Compliance: AML monitoring tuned for PH typologies; sanctions screening; Travel Rule on outbound.
  • Risks: partner concentration; regulator posture; wallet outage; FX volatility for low-value customers.
  • v1 cuts: card; recurring; high-tier limits.

P8 · AAR dropped 4pp overnight in Brazil. Diagnose.

Drill answer
  • Confirm: real or measurement? Pull the SQL by hour; compare to last week same day-of-week. Rule out reporting lag.
  • Decompose: BR overall vs by acquirer. If concentrated on one acquirer, partner incident — escalate.
  • Decompose: by BIN range. If concentrated, issuer-side change (a major issuer tightened crypto MCC).
  • Decompose: by decline_family. Spike in "system" → network issue. Spike in "soft" → issuer behaviour shift. Spike in "stepup" → 3DS routing change.
  • Recent changes: any rule changes deployed in the window? Roll back the suspect change while investigating.
  • If issuer-side: communicate via PSP; explore alternate routing; surface message to customers.
  • Throughout: dashboard + status page; payment-ops Slack channel; post-mortem.

P9 · Spec defenses against the deposit-withdraw fraud loop

Drill answer
  • Force 3DS on first card deposit (liability shift); risk-score subsequent deposits.
  • Hold withdrawals to crypto for 24-72 hours after card deposit, risk-tiered by amount/customer history.
  • Restrict early withdrawal destination — same card refund only, for X days.
  • BIN-level scoring — flag high-friendly-fraud BINs for tighter hold.
  • Velocity rule: high deposit + immediate withdraw + new account → manual review.
  • Track chargeback rate per BIN; auto-block BINs exceeding internal threshold.
  • Tradeoff: hold period hurts conversion for legit users — A/B the threshold; offer "verify identity to release faster" UX.

P10 · Should we settle treasury with our LatAm partner via USDC?

Drill answer
  • Pro: ~real-time settlement (vs T+1/T+2 wires); lower correspondent-banking cost; 24/7; FX risk window shortened.
  • Con: USDC depeg tail risk; local-fiat conversion still required at endpoints; regulatory acceptance uneven; treasury controls and accounting integration; partner readiness.
  • Decision frame: pilot with one partner for one corridor; cap volume; daily reconciliation; full audit trail. Track stable-coin operational cost vs wire/correspondent.
  • Compliance: Travel Rule applies; AML pattern monitoring on USDC inflows; sanctions screening on counterparty wallets.
  • Recommendation: pilot, don't replace. Decide post-pilot.