--- title: "When a Payment Request Gets No Answer" canonical: "https://current.tinyfish.ai/issue/52/practitioners-corner/article/52898/when-a-payment-request-gets-no-answer" publication: "TinyFish" publisher: "TinyFish" language: "en-US" guide: "https://current.tinyfish.ai/llms.txt" author: "Sable Whitford" author_url: "https://current.tinyfish.ai/team/201" issue: 52 section: "practitioners-corner" section_name: "Practitioner's Corner" published: 2026-10-23 updated: 2026-10-24 word_count: 413 source_links: 2 --- # When a Payment Request Gets No Answer *By [Sable Whitford]()* *October 23, 2026* [Read on the website]() Say a program asks a server to make a payment, and nothing comes back. No error, no receipt. The connection hangs for a while, then gives up. On the server, the payment might have gone through, might be half done, or might never have started, and the program can't tell which. A person can muddle through this. They check the bank app, dig through email, and call support. An automated program (an "agent") mostly gets two options, and both are guesses. If it retries, maybe the card gets charged twice. If it reports a failure, maybe the order already exists and some poor human gets to redo it by hand. The web's basic rules (HTTP) won't bail you out here. [The main HTTP spec](https://www.rfc-editor.org/rfc/rfc9110.html#section-9.2.2) flatly declines to define what happens inside the server. A timeout tells you nothing about what the server did. So the agent has to keep its own records. Before sending, it attaches a unique ID (a "key") to the request and writes that key down. Then it can safely ask again, but only if the server knows what to do with the key. Without one, the agent is guessing with someone's credit card. **Question 1: Was anything created?** Maybe. The order or charge could exist, and the timeout won't tell you. **Question 2: Is the work finished?** The server might still be working on it. A server is allowed to reply before the work is actually done. **Question 3: Is it safe to try again?** Repeating a "submit" or "change" request (POST or PATCH, in HTTP terms) can make it happen twice. The HTTP rules say programs shouldn't retry these automatically unless they have some way to know it's safe. **What the [proposed rule](https://datatracker.ietf.org/doc/draft-ietf-httpapi-idempotency-key-header/) offers:** The program sends a random unique ID in a field called `Idempotency-Key`. The server uses it to spot a repeat request and answers as if the first try finished. **Suggested server replies:** Code 409 if the first request is still in progress. Code 422 if the same key shows up with different request details. **What it doesn't promise:** That any particular server honors the key. The draft says a general-purpose program "cannot assume" it will. **Also missing:** Guidance for what to do after a key expires, and a way to check on the first try without sending it again. **Status:** Still a working-group draft (version 08, October 2026). It is not an official standard yet, and its retry rules are still being argued over. ## More - [Practitioner's Corner — Issue 52]() - [Issue 52]() - [Publication guide]()