Stripe SDE Interview Problem #2: Authorization Requests & Fraud Rules

11 Views
No Comments

Part 1 — Authorization Requests

Stripe accepts payments on behalf of merchants. These payments begin as Authorization Requests, which represent an intent to transfer funds from an end user’s credit card to a merchant. Our system receives these requests and decides the Outcome of each Authorization Request. For now, the system’s policy is to APPROVE all requests.

Authorization Requests arrive in the following format:

timestamp_seconds,unique_id,amount,card_number,merchant

Input example

5,R1,5.60,4242424242424242,bobs_burgers
10,R2,500.00,4242111111111111,a_corp

No data fields in this file will include commas, and there will be no whitespace surrounding the field values. Field values are limited to alphanumeric characters, underscores, and periods. You can assume the input has already been checked for correctness. Each timestamp is in seconds and is an integer greater than zero. Each amount is a greater-than-zero decimal value.

We have been asked by various colleagues for a human-readable report of these requests. The report should include the timestamp, unique ID, amount, and outcome — in that order, separated by spaces.

Expected output for the above input

5 R1 5.60 APPROVE
10 R2 500.00 APPROVE

Task

Write a function that produces a report for all requests, ordered chronologically, in the described format. In addition to this function, you should use tests to demonstrate that it is correct.

An example would be:

input = [
  "5,R1,5.60,4242424242424242,bobs_burgers",
  "10,R2,500.00,4242111111111111,a_corp"
]

output = [
  "5 R1 5.60 APPROVE",
  "10 R2 500.00 APPROVE"
]

Part 2 — Fraud Rules Stream

Certain colleagues upstairs have let us know that our policy of approving every Authorization Request is frowned upon by our investors. Luckily, they informed us of a separate system that our data science department built which can detect Authorization Requests that are fraudulent. With fraud, the data scientists say, nothing is set in stone. The criteria for fraud change constantly, so their system develops new Fraud Rules all the time. They’ve given us access to their system’s stream of Fraud Rules, in the following format:

time,field,value

Example

1,merchant,bobs_burgers
20,card_number,4242111111111111

Interpretation:

  • The first Fraud Rule indicates: “from 1 second onward, any Authorization Request with merchant bobs_burgers is fraudulent.”
  • The second indicates: “from 20 seconds onward, any Authorization Request with card_number 4242111111111111 is fraudulent.”

Once a Fraud Rule is introduced, it is applicable in perpetuity (from its introduction time forward).
A new Fraud Rule cannot be applied retroactively to a previous request (i.e., rules are effective at or after their time).

Updated Task

Given a list of transactions (Authorization Requests) and a list of Fraud Rules, produce the same human-readable report as in Part 1, but now with REJECT for any request that matches an active Fraud Rule at the time of that request; otherwise APPROVE. The output must still be chronologically ordered by timestamp.

Example

transactions = [
  "5,R1,5.60,4242424242424242,bobs_burgers",
  "10,R2,500.00,4242111111111111,a_corp"
]

fraud_rules = [
  "1,merchant,bobs_burgers",
  "20,card_number,4242111111111111"
]

output = [
  "5 R1 5.60 REJECT",
  "10 R2 500.00 APPROVE"
]

Summary

This problem is essentially a stateful stream processing problem. Interviewers focus on:

In actual Stripe interviews, this type of question is used to assess whether candidates can:

If you want to further practice these “system logic + data structure” problems, we offer Stripe / Meta / Amazon Coding Mock Interview support services, including complete problem explanations, code reasoning, and simulated answering processes. This helps you express yourself clearly and confidently achieve high scores in real interviews.

END
 0