Description
Solutions
For All Intents And Purposes Part 1 - Initializing the System πŸ—οΈ
🀘 INTERNπŸ‘©β€πŸŽ“ NEW GRAD

🐝 Hi there! The description you are currently reading is just 1st part of the problem set. It is highly recommended to read ALL THE 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 ⏰

    • Background

    Stripe processes billions of dollars of payments to businesses every day through dozens of different payment methods like cards, bank debits, and even papaer cheques.

    We don't want merchants (the businesses who use Stripe to accept peyments) to have to worry about the details for each specific payment method. For example, for many payment methods, payments are not completed instantly and can take a few days to process and be confirmed or fail, while others are processed much more quickly. Stripe abstracts this payment flow with a simple state machine object called a Payment Intent.

    Today, imagine you are an engineer working at Stripe in its early days. You will implement a system that handles the creation and management of these Payment Intens, helping merchants easily setup and accept payments from customers.

    Please read all instructions for each part before you begin coding for that part.

    What is a Payment Intent?

    A Payment Intent tracks a payment through its flow from initilization to processing to confirmation. We model this flow as a state machine: an abstract object that can exist in one of a number of states and transition between states.

    A Payment Intent stores information like the merchant receiving the peyment and the monetary amount. It also should keep track of its state, which can be one of three values

  • REQUIRES_ACTION

    • πŸ‘‰ The initial state of a Payment Intent upon creation. Can transition to PROCESSING.

  • PROCESSING

    • πŸ‘‰ The customer has attempted to pay but the attempt has not yet succeeded or failed. Can transition to either REQUIRES_ACTION or COMPLETED

  • COMPLETED

    • πŸ‘‰ The attempt to pay succeeded and the Payment Intent amount was added to the merchant's balance.

    You Task

    You will implement a function that executes a chronologically ordered list of commands to create and manage Payment Intents for different merchants and then returns the account balances for each merchant after executing all commands.

    Input

    You will receive a chronologically ordered list of commands in the form ['INIT m1 0', 'CREATE p1 m1 100'] where each command is a single string. You will also receive the part number, corresponding to the pairs in the problem description. The commands you need to support are decribed below.

    Output

    A list of merchant balances in the form ['m1 100', 'm2 200'] representing the balance for each merchant after executing all commands. The list should be sorted by merchant ID in ascending alphabetical order.

    Part 1: Good Intentions

    To build the initial version of our system, we will support a few basic commands for initializing a merchant, creating a Payment Intent, attempting a Payment Intent, and succeeding a Payment Intent.

    Commands

    For this part, your system should handle the following commands -

    INIT <merchant_id> <starting_balance>

  • Initializes a merchant with a unique identifier string and starting balance (the amount of money in their account)
  • If a merchant with the given identifier has already been created, this command should do nothing.

    • CREATE <payment_init_id> <merchant_id> <amount>

  • Creates a Payment Intent for a merchant with a given amount. After creation, the state of the Payment Itent should be REQUIRES_ACTION.
  • If a Payment Intent with the given identifier already exists, or if a merchant with the given identifier doe snot exist, or if the amount is negative, this command should do nothing

    • ATTEMPT <payment_init_id>

  • Transitions a Payment Intent with a given identifier from the REQUIRE_ACTION state to the PROCESSING state.
  • If no Payment Intent with the given identifier exists, or if the state of the Payment Intent is not REQUIRES_ACTION, this command should do nothing.

    • SUCCEED <payment_init_id>

  • Transitions a Payment Intent with a given identifier from the PROCESSING state to the COMPLETED state
  • If no Payment Intent with the given identifier exists, or if the state of the Payment Intent is not PROCESSING, this command should do nothing.

    • πŸ³β‹†ο½‘Λšβ‹†β€ πŸšπŸ«§π“‡Ό Λ–Β°Credit to Rachelα₯«α­‘.

    Example 1: 

    Input:  commands = ["INIT m1 0", "INIT m2 10", "CREATE p1 m1 50", "ATTEMPT p1", "SUCCEED p1", "SUCCEED p1", "CREATE p2 m2 100", "ATTEMPT p2"]
    Output: ["m1 50", "m2 10"] 
    Explanation:
    

Let's look at what happened for each command 🐼


  • INIT m1 0 initializes merchant m1 with a starting balance of 0
    • 


  • INIT m2 10 initializes merchant m2 with a starting balance of 10
    • 


  • Create p1 m1 50 creates a Payment Intent p1 for merchangt m1 with an amount of 50 and initial state of REQUIRES_ACTION initializes merchant m2 with a starting balance of 10
    • 


  • ATTEMPT p1 transitions p1 from REQUIRES_ACTION to PROCESSING
    • 


  • SUCCEED p2 transitions p2 from PROCESSING to COMPLETED and increments merchant m1's balance by 50
    • 


  • CREATE p2 m2 100 creates a Payment Intent p2 for merchant m2 with an amount of 100 and initial state of REQUIRES_ACTION
    • 


  • ATTEMPT p2 transitions p2 from REQUIRES_ACTION to PROCESSING
    • 

Because only p1 was successfully completed, at the end of executing all of the commands, m1 should have a balance of 50 and m2 should have a balance of 10 :D
    Constraints:
      🫢
    Thumbnail 0
    Testcase
    Result
    Case 1

    input:

    output: