2 months ago
I have repeated failures of calls from the Rust server to Authorize.net for payments today. Nothing has changed on the payment side. Payments were working yesterday and are fully broken today. I've confirmed that they should work through local testing of the code, independent testing via curl and logging on the system. This is a Railway issue:
- The token is not consumed by the failed Railway request (reusable from local)
- HTTP/1.1 forced (no h2 negotiation) — same failure
- Multiple deployments, cache busts, credential rotations — same failure
- Payments worked from this same service yesterday (April 3)
Question: Does Railway's egress proxy modify outbound HTTPS request bodies, add/strip headers, perform TLS interception, or apply any transformation to outbound traffic to external APIs? Has something changed in the Railway infrastructure in the the last 24-36 hours?
FYI, while caching has been a huge problem with railway deployments, but I don't think that applies here. I have confirmed creds are correct on the send to the gateway. Anything you guys can provide to shed some light on this would be helpful.
Pinned Solution
2 months ago
It turns out that the sandbox account was corrupted. I did not know this was possible. I rotated all keys multiple times. Confirmed correctness across the board...but a new sandbox account fixed the error. Difficult to say whether there was a caching error on their side or that some records were failing to update within their database. In any case, it required an entirely new sandbox account to solve the issue. Frustrating for sure.
2 Replies
Status changed to Awaiting Railway Response Railway • about 2 months ago
2 months ago
This thread has been marked as public for community involvement, as it does not contain any sensitive or personal information. Any further activity in this thread will be visible to everyone.
Status changed to Open Railway • about 2 months ago
2 months ago
What your evidence actually points to
The token surviving on Authorize.net's end means the request either isn't reaching them or is being rejected before processing. Combined with HTTP/1.1 forced and no h2 negotiation, this looks like a TLS or proxy-level failure happening at the egress layer, not in your code.
Specific things worth ruling out
Railway does route outbound traffic through an egress proxy. It doesn't officially document body modification, but the proxy can affect TLS handshakes, SNI headers, and connection behavior,particularly if something changed on their infrastructure side in the last 24-36 hours.
Check whether Authorize.net made any changes their end too. They occasionally update TLS requirements, IP allowlists, or cipher suite requirements with little notice. Worth hitting their status page and checking if your Authorize.net account shows the failed attempts at all,if they show zero hits, the requests aren't leaving Railway's network cleanly.
What to actually send Railway support
Tell them you need to know if egress proxy behavior or outbound TLS handling changed between April 3 and April 5. Ask specifically about europe-west4 or whichever region you're on. The 24-36 hour window you're describing aligns with the kind of rolling infrastructure change that wouldn't show on a status page.
You have a strong case given the timeline and local reproduction working fine.
2 months ago
It turns out that the sandbox account was corrupted. I did not know this was possible. I rotated all keys multiple times. Confirmed correctness across the board...but a new sandbox account fixed the error. Difficult to say whether there was a caching error on their side or that some records were failing to update within their database. In any case, it required an entirely new sandbox account to solve the issue. Frustrating for sure.
Status changed to Solved brody • about 2 months ago