Credit Card Customer Portal

0) Problem Restatement

Design the web and mobile portal where credit card customers manage their account (asked at Capital One Power Day). Customers log in and:

• see current balance, available credit, minimum payment due and due date,
• view transactions (pending and posted) and download statements,
• make payments from a bank account (one-time or autopay),
• use card controls: lock/unlock card, report lost, set alerts, replace card.

The interviewer will ask why you made each decision, so be ready to justify the choices.

1) Requirements

• Secure login with MFA, and session timeout.
• Accurate account data (from the core card processing system).
• Payments must never be duplicated.
• Card lock takes effect immediately for new authorizations.
• High availability, especially around due dates and statement days.

2) Architecture

flowchart LR
    U["Web / Mobile"] --> GW["API Gateway - auth, rate limits, WAF"]
    GW --> BFF["Portal BFF"]
    BFF --> ACC["Account Service"]
    BFF --> TXN["Transactions Service"]
    BFF --> PAY["Payments Service"]
    BFF --> CARD["Card Controls Service"]
    BFF --> STM["Statements Service"]
    ACC --> CORE["Core card system (processor)"]
    TXN --> TDB[("Transactions store - read replica / search")]
    STM --> OS[("Statement PDFs - object storage")]
    PAY --> ACH["Bank transfer network (ACH)"]
    CARD --> AUTHZ["Authorization system - card status"]
    IDP["Identity - login, MFA"] --> GW

• Identity: login with password + MFA (push/OTP), device recognition, risk-based step-up (a new device → extra check). Short-lived tokens, and refresh with rotation.
• BFF: one API tailored to the portal screens. It calls domain services in parallel.
• Core card system is the source of truth for balances. The portal reads through the Account Service with a short cache.

3) Key Features

3.1 Balance and transactions

• Pending transactions (authorizations) and posted transactions (settled) come from different stages, so show both, clearly labeled.
• Transactions are served from a read-optimized store (replicated from core, updated in near real time via events) with search and filters (merchant, date, amount).
• The balance is cached for ~30–60 s, and refreshed right after actions like payments.

3.2 Payments

• POST /payments with an Idempotency-Key, amount, source bank account (tokenized) and date.
• Validate (amount ≤ balance or allowed overpay; bank account verified), save as scheduled → send via ACH → processing → posted or returned.
• Show the payment immediately as "pending" so the customer doesn't pay twice, and credit available credit according to bank policy.
• Autopay: a scheduler creates payments on the due date (minimum, statement balance or a fixed amount).

3.3 Card controls

• Lock writes the card status to the authorization system, which checks it on every card swipe, so new purchases are declined within seconds.
• Report lost/stolen: block the card, issue a replacement, and move recurring merchants to the new card if supported.

3.4 Statements

Statements are generated monthly by batch jobs as PDFs in object storage. The portal lists them and gives short-lived download links.

4) Security

• TLS everywhere, WAF, rate limiting on login (credential-stuffing protection), and bot detection.
• Sensitive data minimization: show only the last 4 digits of the card, keep full numbers in a vault, and mask everything in logs.
• Audit log of all account changes (address, payments, card status).
• Alerts to the customer on important changes ("your address was changed").

5) Availability

• Stateless services behind load balancers across zones.
• Statement and due days bring spikes, so pre-scale and cache heavily for read paths.
• If core banking is slow, show cached balances with an "as of" time, and queue non-urgent actions.

6) Wrap-Up

Put a strong identity layer (MFA, risk-based step-up) and a gateway in front of a portal BFF that aggregates account, transactions, payments, card controls and statements services. Balances come from the core card system with short caching, transactions from a read-optimized replica showing pending vs posted, payments are idempotent and tracked through ACH states, and card locks write directly to the authorization system. Secure everything with masking, an audit log and customer alerts.