Quiz

PayPal mobile design quiz

Check the PayPal mobile design post: payment intents, ledgering, idempotency, risk, webhooks, local state, and recovery flows.

Questions

12

Est. time

~9 min

Read the post View the series

Score

01
Payment intent

Why should the system create a durable payment intent before or during confirmation?
Options for question 1
1. A. It creates a recoverable server-side object for retries, timeouts, or restarts.
2. B. It lets the mobile app calculate the final balance locally.
3. C. It removes the need for risk checks.
4. D. It guarantees external bank settlement has completed instantly and the wallet balance is final.
Correct answer: A.

A payment intent gives the system and client a stable object for recovery. If the confirm response is lost, the app can query or retry around the same intent instead of creating a duplicate payment.
02
Idempotency

A user taps Confirm, the server completes the payment, but the response never reaches the phone. What should the app do next?
Options for question 2
1. A. Create a brand new payment request with a new key so the user can try again from scratch.
2. B. Show success without checking the server because the tap already left the device.
3. C. Retry with the same key or fetch the existing intent status.
4. D. Delete the pending payment and tell the user nothing happened.
Correct answer: C.

The app needs to recover around the original business operation. Reusing the idempotency key or querying the intent prevents a second payment while allowing the client to learn the final state.
03
Ledger correctness

Why should the ledger be append-only or tightly controlled by a ledger service?
Options for question 3
1. A. Because append-only storage is always cheaper than caching.
2. B. Because it is the audit trail for money movement.
3. C. Because mobile clients need to write ledger entries offline.
4. D. Because webhooks can replace balance calculations when merchants confirm delivery.
Correct answer: B.

The ledger is the durable record of debits, credits, fees, refunds, and reversals. It should be controlled and auditable because balances and investigations depend on it.
04
Mobile local state

Which local state is safe for a PayPal-style mobile app to keep?
Options for question 4
1. A. Final settlement state for bank transfers started on this device and confirmed by push.
2. B. Risk decisions that allow future payments without server checks.
3. C. Final available balance authority.
4. D. Cached activity, drafts, pending intent IDs, and idempotency keys.
Correct answer: D.

Local state is useful for responsiveness and recovery, but final money state belongs on the server. The app can cache and resume, not decide that settlement completed.
05
Offline behavior

Should a PayPal-style mobile app allow fully offline payment creation?
Options for question 5
1. A. No. Keep drafts and cached state, but require server confirmation for money movement.
2. B. Yes. Queue unlimited offline payments and settle them later when bank and risk systems are reachable.
3. C. Yes, but only for high-value payments.
4. D. No, and it should also hide all cached activity while offline.
Correct answer: A.

Fully offline payment creation is too risky. The app can support drafts, cached reads, and recovery after reconnect, but it should not pretend money moved without the server.
06
Risk and step-up

Where should final risk decisions live?
Options for question 6
1. A. Entirely on the mobile client for lower latency and fewer backend dependencies.
2. B. Inside the push notification service.
3. C. On the server; the app collects signals and shows step-up flows.
4. D. Inside the merchant webhook endpoint.
Correct answer: C.

The mobile app can collect device and session signals, but attackers can tamper with clients. Final allow, deny, review, or step-up decisions need server-side control.
07
Merchant webhooks

Why are webhooks important for merchant checkout?
Options for question 7
1. A. They let the mobile app skip server confirmation.
2. B. They let merchants receive signed async payment state changes.
3. C. They replace the need for a ledger.
4. D. They guarantee push notifications arrive before payment capture and before buyer receipts are visible.
Correct answer: B.

Merchant systems need a reliable way to learn about payment events after the initial API response. Signed webhook events with retries help maintain consistency between platform and merchant.
08
Push notifications

How should the mobile app treat a push notification saying a payment completed?
Options for question 8
1. A. Treat it as final proof and update local balance immediately for a faster wallet home screen.
2. B. Ignore it because payment apps should not use push.
3. C. Use it to trigger a second capture request.
4. D. Treat it as a wake-up signal, deep link, then fetch server state.
Correct answer: D.

Push is useful for alerting and navigation, but it is not the source of truth. The app should fetch server state before showing final details.
09
Read models

Why use wallet and activity read models instead of making the app read raw ledger entries directly?
Options for question 9
1. A. Read models give mobile-friendly views while the ledger remains authoritative.
2. B. Read models let the app bypass authentication.
3. C. Raw ledger entries are always unavailable to backend services.
4. D. Read models eliminate reconciliation because the app sees the same records as external processors.
Correct answer: A.

Wallet home and activity are read-heavy and need product-shaped payloads. Read models can be optimized while ledger entries remain authoritative.
10
Payment state machine

What is the value of explicit payment states like requires_action, processing, completed, failed, and refunded?
Options for question 10
1. A. They let every payment skip risk review.
2. B. They allow the client to mutate final settlement directly when risk and funding providers are slow.
3. C. They make transitions auditable and give the UI clear recovery paths.
4. D. They are only useful for merchant dashboards, not mobile apps.
Correct answer: C.

Explicit states help both systems and users understand what happened and what comes next. They also prevent vague or unsafe transitions.
11
Reconciliation

What problem do reconciliation jobs solve in a payment system?
Options for question 11
1. A. They generate all mobile UI screens from ledger state, funding state, webhooks, and risk review queues.
2. B. They compare internal records with processors or banks and repair drift.
3. C. They replace idempotency keys for mobile retries.
4. D. They make payment confirmation safe while offline.
Correct answer: B.

External systems can be delayed or inconsistent. Reconciliation jobs help detect and repair mismatches between internal payment state, ledger state, and provider state.
12
Explaining the design

What is the clearest high-level explanation of the PayPal mobile architecture?
Options for question 12
1. A. It is mainly a cached balance screen with a payment button.
2. B. It is a push notification system with checkout added later.
3. C. It is an offline queue that settles payments whenever the app reconnects, then asks risk systems to approve later.
4. D. It is a mobile wallet backed by intents, risk, ledger, funding, notifications, webhooks, and reconciliation.
Correct answer: D.

The design needs to connect mobile UX with server-side payment correctness. The important pieces are intent, risk, ledger, funding, read models, notifications, webhooks, and reconciliation.

Progress

0/12 answered

Answer every question before submitting.

Made in SF v1

Product EM · SF

01 Home 02 Projects 03 Writing 04 CV 05 Playground 06 Contact

© 2026 Sean Kim