Idempotent Charge Requests

Networks drop responses, so clients retry. A payments API that treats every retry as a new request charges people twice. The standard defence is an idempotency key: the client sends the same key with every attempt of one charge, and the server answers a retry with the original result instead of charging again.

You are given the charge requests in time order. Request i arrives at second times[i] with key keys[i] and asks to charge customer customers[i] the amount amounts[i]. Charges get ids 1, 2, 3, ... in the order they are created. Answer each request:

• If its key created a charge less than 24 hours (86,400 seconds) ago and the customer and amount are the same as that charge's, it is a retry: answer "replayed:<id>" with that charge's id and create nothing.
• If its key created a charge less than 24 hours ago but the customer or the amount differs, the key is being misused: answer "conflict" and change nothing.
• Otherwise (the key is new, or its charge was created 86,400 seconds ago or more), create a new charge, answer "created:<id>", and from now on the key refers to this new charge.

Keys are case-sensitive. Return the answers in order.

Example

Key k1 creates charge 1 at second 0. Its retry at second 5 is replayed; at second 6 the same key arrives with a different amount, a conflict. Key k2 creates charge 2. At second 86,399 k1 is still within 24 hours of charge 1 and is replayed, but at 86,400 the 24 hours are up, so it creates charge 3. At 86,401 k1 refers to charge 3, and a different customer is a conflict.

The answer is ["created:1", "replayed:1", "conflict", "created:2", "replayed:1", "created:3", "conflict"].