Payment Ledger with Refunds and Date Queries

Implement a lightweight payment ledger that records payments, applies full or partial refunds, tracks net revenue, and retrieves recorded payments by date.

Implement processPaymentLedger. Process the operations in order and return one result string for every operation.

Operation format

• PAYMENT payment_id timestamp amount: record a payment with a unique ID, a strict UTC timestamp in YYYY-MM-DDTHH:mm:ssZ form, and a positive amount. First validate the timestamp, then check whether the ID is already recorded. Return RECORDED on success, INVALID_TIMESTAMP for an invalid timestamp, or DUPLICATE_PAYMENT for a valid-timestamp operation whose ID already exists. A rejected payment has no effect.
• REFUND payment_id amount: refund a positive amount from an existing payment. Multiple partial refunds are allowed, but their cumulative amount may not exceed the original payment amount. Return REFUNDED, PAYMENT_NOT_FOUND, or INVALID_REFUND. A rejected refund has no effect. A successful full refund does not remove the payment from date-query results.
• TOTAL: return the current net revenue as a decimal integer. Net revenue is the sum of recorded payment amounts minus successful refunds.
• PAYMENTS_ON date: return the matching payment IDs as one comma-separated string in original recording order. The date must use strict YYYY-MM-DD form. Return the empty string when no payment matches, or INVALID_DATE when the date is invalid.
• PAYMENTS_BETWEEN start_date end_date: return payment IDs whose payment date is in the inclusive range, ordered by payment date and then by original recording order within one date. Return the empty string when no payment matches. Return INVALID_RANGE when either date is invalid or start_date is after end_date.

Operation lines are otherwise well-formed. Payment IDs are non-empty and contain no spaces.

Interview follow-ups

The interview report also asked how to optimize date lookup for large data, validate timestamps, query a range such as one month, and persist runtime state in a database. This callable exercise judges the in-memory behavior above; database persistence remains a discussion follow-up.