How should I practice For All Intents And Purposes Part 4 - Timing Matters ⏰?

Start by reading the full statement, solve the visible examples, then compare the pattern against related Stripe online assessment problems in FastPrep.

Is For All Intents And Purposes Part 4 - Timing Matters ⏰ associated with Stripe?

FastPrep tags this as a Stripe coding interview or online assessment practice problem when the problem catalog has that company context.

FastPrep

Problem · Design

For All Intents And Purposes Part 4 - Timing Matters ⏰

● MediumStripeINTERNNEW GRADOA

See Stripe hiring insights

🐝 Hi there! The description you are currently reading is just 4^th part of the problem set. It is highly recommended to read ALL THE 4 PARTS before coding as parts may build on top of each other 🐳

For All Intents And Purposes Part 1 - Initilizing the System 🏗️

For All Intents And Purposes Part 2 - Change Is Good! 👍

For All Intents And Purposes Part 3 - Accepting Failure 😌

For All Intents And Purposes Part 4 - Timing Matters ⏰

Last month, we received the new Payment Intent system you built 👏, and merchants have been LOVING how simple it makes accepting payments. Congratulations 🎉!

However, numerous merchants have requested that we augment our refund functionality by letting merchants specify a refund timeout policy: the amount of time after a payment succeeds that refunds are permitted. For example, one merchant, LlmaCorp, only wants to accept refunds within 15 days of a payment succeeding. Being able to return a llama afte 15 days would be absurd after all.

Let's add this functionality to our system, which means we will need to change the format of our commands to handle timing 💪.

Timestamps

All commands will now have an integer timestamp in front. For example, intead of SUCCEED , you will now receiveSUCCEED

You can assume that the timestamps will always be integers (representing a unit of time) and that the timestamps of the list of commands will be strictly increasing

Merchant Refund Timeout Limit

The INIT command that initializes a merchant will now have an optional third argument specifying the merchant's refund timeout limit. The new specification is -

👉 <timestamp> INIT <merchant_id> <starting_balance> <refund_time_out_limit>

If a merchant has a refund_timeout_limit of n, and succeeds a Payment Intent (with the SUCCEED command) at timestamp t, then the timestamp of a REFUND command must be no greater than t + n, otherwise the refund should no succeed.

iF A refund_timeout_limit is not specified during merchant initialization, there is no refund time limit, a a refund should succeed regardless how much time has passed since Payment Intent confirmation. A reund_timeout_limit of 0 means no refunds should be accepted ever, and a negative refund_timeout_limit should be ignore (meaning all refunds should be accepted)

🌷༊·˚Credit to Rachelᥫ᭡.

Examples

01 · Example 1

commands = ["1 INIT m1 0 5", "2 CREATE p1 m1 100", "3 CREATE p2 m1 50", "4 ATTEMPT p1", "5 ATTEMPT p2", "8 SUCCEED p1", "10 SUCCEED p2", "11 REFUND p1", "16 REFUND p2"]
return = ["m1 50"]

In the above example, the reund of Payment Intent p1 succeeded because p1 was succeeded at time 8 and refunded at time 11, which is within merchant m1's refund timeout limit of 5. However, the refund of Payment Intent p2 failed because p2 was succeeded at time 10 and refunded at time 16, and 16 - 10 = 6 > 5, meaning it occured after m1's timeout limit. Because p1 was successfully refunded and p2 was not, the final balance of merchant m1 should be 50 :P

Constraints

🫶