Should you retry the two unknown payments?
Separate an unknown outcome from a confirmed payment failure.
“An idempotency key should uniquely identify one specific action” (opens the source)
The question
Meridian Pay and all records are fictional. One batch has 80 customer orders of €80 each. Each order has one payment attempt, a unique payment ID and an idempotency key. A client timeout does not establish the processor’s outcome.
| Orders | |
|---|---|
| Confirmed paid | 74 |
| Confirmed failed | 4 |
| Unknown after timeout | 2 |
The three groups are disjoint and total 80. No order in the failed group was charged.
The fictional processor lets you query an existing payment and safely retry that same operation with its original key and parameters. It retains the key for 24 hours. All events in this case occur within 10 minutes. This is a case rule, not permission to retry with changed parameters.
“Choose your next action and explain the evidence behind it.”
Not saved by this site. Your browser may restore text when you navigate back.
A strong answer, step by step
Open each step in turn. This is one strong answer, not the only one.
Step 1: Count confirmed money
What would you do here? Open the move you’d make.
Keep the unknown payments pending.
The strong move. A network timeout is not a payment state.
Mark both timed-out payments failed.
Tempting, but it misses something. The processor may have completed a payment before the client lost its response.
See how a strong candidate says it
“Confirmed paid value is 74×€80 = €5,920. The two unknown payments represent €160 with no final outcome yet. I would keep them pending.”
Why it works: A network timeout is not a payment state.
Step 2: Keep the same identity
What would you do here? Open the move you’d make.
Query and retry the same operation when permitted.
The strong move. The retry must refer to the same intended payment.
Generate a new key and charge again.
Tempting, but it misses something. A new key identifies a new operation and can charge an already-paid order twice.
See how a strong candidate says it
“I would query each existing payment ID. If a retry is needed under the stated contract, I would keep the original operation, parameters and idempotency key.”
Why it works: The retry must refer to the same intended payment.
Step 3: Apply the event once
One unknown payment resolves to paid. Its authenticated success event, evt-75, arrives twice with the same event ID. The other unknown payment has no final result.
What would you do here? Open the move you’d make.
Record one state transition and one fulfilment.
The strong move. A delivered event is not a new customer order.
Count both event deliveries as payments.
Tempting, but it misses something. Both deliveries have the same event ID and describe the same payment.
See how a strong candidate says it
“One more order is paid, so confirmed value is 75×€80 = €6,000. Four failed orders and one €80 unknown remain. The duplicate event does not add another paid order or trigger fulfilment twice.”
Why it works: A delivered event is not a new customer order.
Step 4: Resolve the last unknown
What would you do here? Open the move you’d make.
Resolve the existing payment before creating another.
The strong move. Recovery needs authoritative state, not an inferred failure.
Create a fresh payment when no webhook arrives.
Tempting, but it misses something. An absent webhook does not prove the original payment failed.
See how a strong candidate says it
“I would query or reconcile the remaining payment and keep an owned recovery task. If the processor retains an error result, repeating the same call is not proof that no charge occurred.”
Why it works: Recovery needs authoritative state, not an inferred failure.
The answer, in short
- Decision
- Resolve the existing attempts and apply each confirmed result once.
- Because
- Seventy-five orders are paid; one remains unknown.
- What would change it
- An authoritative final result for the last payment would settle its status.
Common traps
- Treating a timeout as a decline.
- Counting message deliveries as payments.
Check your answer
- I kept all 80 orders accounted for.
- I used the original payment identity.
- I handled the duplicate event once.
- I left an owner for the unknown result.
Last reviewed Nov 10, 2026