A payment request can cross the service boundary and succeed even when the response does not return. The client then has to choose between waiting, checking, or trying again.
Failure modes
A retry without a stable operation identity may create a second payment. A stable idempotency key may allow the payment boundary to return the original result, but only if the boundary stores and applies that identity consistently.
A status lookup changes the interaction: the client asks about an operation rather than repeating it. It also introduces retention, ownership, and recovery questions.
Tradeoffs
There is no universally correct choice. The right approach depends on who owns the operation identity, how long the result must remain discoverable, what the provider documents, and what happens when the idempotency record is unavailable.
The recommendation is to make the operation identity explicit, document the provider contract, and test duplicate behavior before automatic retries become a default assumption.
Context
A payment operation succeeds, but the response is lost before the client receives it.
Decision
Choose how the client identifies, retries, checks, and reconciles a payment operation.
Constraints
The payment provider contract, operation retention period, recovery path, and ownership of the resulting state constrain the design.
Tradeoffs
Idempotency keys reduce duplicate risk but require durable identity and provider support. Status lookup avoids repeating the operation but adds state and recovery behavior. Blind retries are simple but can make a successful operation happen twice.
Recommendation
Make operation identity explicit, use the provider-supported idempotency mechanism where available, and test the lost-response path before enabling automatic retries.
Reversibility
The choice becomes harder to change after payment records, reconciliation jobs, and client expectations depend on its semantics.