Published and sources checked: 2026-09-24. Scope: TLS 1.3 early data (0-RTT) in front of an HTTP API that accepts payments, with the protocol rules taken from RFC 8470 "Using Early Data in HTTP" (IETF Standards Track, September 2018), RFC 8446 "The Transport Layer Security (TLS) Version 1.3 Protocol" (August 2018) and RFC 9110 "HTTP Semantics" (June 2022). This is specification research, not a claim about any provider's TLS configuration, and not a substitute for testing your own client, proxy and server path.
Why a payment API cares about a transport feature
Early data lets a returning client send requests in the first flight of a connection, before the handshake finishes, which removes a round trip from the first call. The specification is direct about the price: in RFC 8446, "The security properties for 0-RTT data are weaker than those for other kinds of TLS data", including that "There are no guarantees of non-replay between connections."[2]
RFC 8470 turns that into an HTTP problem. A client that optimistically resends after a rejection can be manipulated into sending twice: "Automatic retry creates the potential for a replay attack... If the client then retries requests that were sent in early data, the request will be processed twice."[1] For a request that creates a charge, "processed twice" is the failure mode this article is about.
Only safe methods may ride in early data
The client rule is stated once and without exceptions: "Absent other information, clients MAY send requests with safe HTTP methods ([RFC7231], Section 4.2.1) in early data when it is available and MUST NOT send unsafe methods (or methods whose safety is not known) in early data."[1] RFC 8470 cites RFC 7231 for that definition; RFC 7231 has since been obsoleted by RFC 9110, whose Section 9.2.1 defines the same set: "Of the request methods defined by this specification, the GET, HEAD, OPTIONS, and TRACE methods are defined to be safe", with safe meaning the semantics are "essentially read-only" and the client "does not request, and does not expect, any state change on the origin server".[3]
A payment API's POST, PUT and DELETE are not in that set, so by the specification they do not belong in early data unless you have a better reason and the server agrees. The corollary for readers: a GET that returns a payment status is a different case from a POST that creates one, and the specification treats them differently on purpose. RFC 8470 puts the choice with the client: "By their nature, clients have control over whether a given request is sent in early data, thereby giving the client control over risk of replay."[1]
What TLS promises, and what it does not
RFC 8470 does not describe early data as unprotected. It notes that "TLS [TLS13] mandates the use of replay detection strategies that reduce the ability of an attacker to successfully replay early data", while warning that "These anti-replay techniques reduce but don't completely eliminate the chance of data being replayed and ensure a fixed upper limit to the number of replays."[1] RFC 8446 adds the boundary condition: 0-RTT data "cannot be duplicated within a connection", but across connections "an attacker will not be able to make 0-RTT data appear to be 1-RTT data" only because the keys differ, not because duplication is impossible.[2]
So the guarantee you get is bounded replay tolerance inside TLS, not uniqueness of your business operation. Duplicate-charge prevention is not a TLS feature.
The server has three specified answers
RFC 8470 lists them: "The server can reject early data at the TLS layer" — which discards every request carried in early data; "The server can choose to delay processing of early data until after the TLS handshake completes", which "provides the server with some assurance that the early data was not replayed"; or "The server can cause a client to retry individual requests and not use early data by responding with the 425 (Too Early) status code".[1] The document then says "All of these techniques are equally effective; a server can use the method that best suits it", and that replay tolerance is judged per request.[1]
That is the decision to make once, in configuration, for the payment endpoints: defer, refuse, or reject individually. It is not a decision to leave to whatever the load balancer happens to do.
The header and the status code carry the decision
The Early-Data request header field "indicates that the request has been conveyed in early data and that a client understands the 425 (Too Early) status code", with a single valid value of "1".[1] Intermediaries must add it when they forward a request that may have been replayed and "MUST NOT remove this header field if it is present in a request".[1] The consequence for servers is strict: "A server cannot make a request that contains the Early-Data header field safe for processing by waiting for the handshake to complete... Requests that contain the Early-Data header field and cannot be safely processed MUST be rejected using the 425 (Too Early) status code."[1]
The status code itself: "A 425 (Too Early) status code indicates that the server is unwilling to risk processing a request that might be replayed."[1] It is not issued speculatively — "The server cannot assume that a client is able to retry a request unless the request is received in early data or the Early-Data header field is set to "1"" — and it "is not cacheable by default".[1]
What the client owes the server
Two obligations follow. A client "that uses early data MUST retry requests upon receipt of a 425 (Too Early) status code", and "A user agent SHOULD retry automatically, but any retries MUST NOT be sent in early data."[1] In other words, 425 moves the request out of the risky window instead of dropping it, and the retry itself must travel on the completed connection.
There is a real-world limit to how much of this you can lean on. MDN documents 425 as having "Limited availability" because "This feature is not Baseline because it does not work in some of the most widely-used browsers", and describes early data as what "allows the client to send data to a server in the first round trip of a connection, without waiting for the TLS handshake to complete."[4] A browser you do not control cannot be assumed to implement the retry contract, so a redirect-return POST that depends on 425 behaviour needs to be tested in the browsers you actually support.
What 425 does not protect
The following is editorial reasoning drawn from the texts above, not quoted requirements. 425 covers a request that arrived in early data on a connection whose handshake had not completed; a duplicate that arrives later, on a fully established connection, or on a different connection, is outside that window entirely. The status code says the server declined to process; it does not identify which earlier attempt was the one that ran, and RFC 8470 defines no application-level de-duplication. Anything you need about "charge at most once" has to be answered at the layer where your transfer records live, by something that can see both attempts.
A practical reading: treat early data as a latency optimisation for read-only traffic, keep payment-creating requests out of it unless you have measured why they must be there, and if they can arrive there anyway, answer 425 or defer until the handshake completes rather than processing optimistically.
Sources and limits
Checked 2026-09-24. RFCs are quoted from the RFC Editor text as retrieved; RFC 8446 and RFC 9110 evidence files are clearly marked excerpts of the sections quoted. MDN's page carries its own "last modified" date. No statement is made about any particular vendor, CDN, proxy or gateway default; verify your own configuration.
- [1] RFC 8470: Using Early Data in HTTP — Published: September 2018 (IETF Standards Track); checked: 2026-09-24.
- [2] RFC 8446: The Transport Layer Security (TLS) Version 1.3 Protocol — Published: August 2018 (IETF Standards Track); checked: 2026-09-24.
- [3] RFC 9110: HTTP Semantics — Published: June 2022 (IETF Standards Track, STD 97); checked: 2026-09-24.
- [4] 425 Too Early - HTTP | MDN — Page last modified: 27 February 2026; checked: 2026-09-24.