Stripe Internship Payment-Intent Refund-Window OA

Role: Software Engineering Intern
Result: Rejected two days after the OA
Timing: September 2024 (report month; exact OA date not shared)

This was a four-part Payment Intent task. The candidate’s screenshot showed Part 4. The earlier parts below are the matching rules from another firsthand report of the same task.

Part 1 — Build the basic flow

Handle INIT, CREATE, ATTEMPT, and SUCCEED. A new intent starts in REQUIRES_ACTION, then moves to PROCESSING, then COMPLETED. A successful payment adds its amount to the merchant’s balance. Invalid commands do nothing, and final balances are sorted by merchant ID.

Practice: Part 1 — Initializing the System.

Part 2 — Change the amount

Add UPDATE. It can change an intent’s amount only while the intent is still in REQUIRES_ACTION, and the new amount cannot be negative. The state stays the same.

Practice: Part 2 — Change Is Good.

Part 3 — Failure and refunds

Add FAIL and REFUND. FAIL moves a processing intent back to REQUIRES_ACTION so it can be tried again. REFUND subtracts a completed intent’s amount once; a second refund or a refund in the wrong state does nothing.

Practice: Part 3 — Accepting Failure.

Part 4 — Add timing

Every command now starts with a strictly increasing integer timestamp. INIT may include a refund timeout. A refund is accepted through success timestamp + timeout, including that exact boundary. No timeout or a negative timeout means no time limit; zero means refunds are disabled.

Practice: Part 4 — Timing Matters.

The candidate felt the OA went well, but was rejected two days later.