I know it was intended flippantly but the attackers do not get the HTTP response code - they're obliged to conduct this attack blind, if they can decrypt the messages then your problem isn't a replay attack but some previously unimagined TLS flaw.
So, suppose your system sees three versions of a transaction to transfer $1M to Dr Evil. You're not worried because two of them "won't commit" but do your end users understand that? (hint: they do not). Let's call these versions A, B and C. The real user's web browser believes transaction A succeeded, and is unaware of B and C.
Dr Evil complains that the money never arrived, and our user checks, alas they see that eventually transaction A failed (it was judged a duplicate of B, and so was C) and this explains the problem. They initiate a new transfer, let's call that Z. This succeeds and Dr Evil is satisfied.
Unfortunately now Dr Evil has $2M instead of $1M.
Yes, do this. Processing the request isn't bad as long as it doesn't commit.
Most evil attackers won't come back to you complaining that your server gave back an HTTP200 response when it should have returned an HTTP400 because they'd reused a nonce.