Skip to main content
Authorize.Net logo

Is Authorize.Net Down?

No — Authorize.Net is up

Reachable from all 8 checked regions

Average response time: 356ms

Last checked · checks run every 6 hours

Official status page: https://status.authorize.net

Authorize.Net uptime

100%
Last 7 days
100%
Last 30 days
100%
Last 90 days
429ms
Avg response, 30 days

Measured from multiple regions every 6 hours. Percentages count only checks that returned an availability answer — 75 days measured so far. A dash means that window does not yet hold enough measured days to publish a figure.

30-day history

75-day clean streak
Sep 14: 100.00% uptime, 32 checks
Sep 15: 100.00% uptime, 32 checks
Sep 16: 100.00% uptime, 31 checks
Sep 17: 100.00% uptime, 30 checks
Sep 18: 100.00% uptime, 40 checks
Sep 19: 100.00% uptime, 32 checks
Sep 20: 100.00% uptime, 32 checks
Sep 21: 100.00% uptime, 31 checks
Sep 22: 100.00% uptime, 32 checks
Sep 23: 100.00% uptime, 32 checks
Sep 24: 100.00% uptime, 32 checks
Sep 25: 100.00% uptime, 24 checks
Sep 26: 100.00% uptime, 32 checks
Sep 27: 100.00% uptime, 32 checks
Sep 28: 100.00% uptime, 32 checks
Sep 29: 100.00% uptime, 32 checks
Sep 30: 100.00% uptime, 32 checks
Oct 1: 100.00% uptime, 29 checks
Oct 2: 100.00% uptime, 31 checks
Oct 3: 100.00% uptime, 32 checks
Oct 4: 100.00% uptime, 32 checks
Oct 5: 100.00% uptime, 32 checks
Oct 6: 100.00% uptime, 32 checks
Oct 7: 100.00% uptime, 31 checks
Oct 8: 100.00% uptime, 32 checks
Oct 9: 100.00% uptime, 32 checks
Oct 10: 100.00% uptime, 32 checks
Oct 11: 100.00% uptime, 32 checks
Oct 12: 100.00% uptime, 32 checks
Oct 13: 100.00% uptime, 32 checks
Sep 14 Today
No downtime Partial Downtime Not measurable No data

Reachability by region

Each region runs its own request from a different part of the world. A service can be up for one continent and down for another, which is usually the first sign of a routing or CDN problem.

ams
285ms
DNS 91ms TCP 2ms TLS 17ms TTFB 279ms
arn
246ms
DNS 64ms TCP 1ms TLS 9ms TTFB 242ms
cdg
215ms
DNS 63ms TCP 1ms TLS 14ms TTFB 210ms
dfw
359ms
DNS 77ms TCP 1ms TLS 13ms TTFB 331ms
ewr
175ms
DNS 37ms TCP 2ms TLS 14ms TTFB 170ms
fra
383ms
DNS 140ms TCP 1ms TLS 12ms TTFB 371ms
syd
833ms
DNS 368ms TCP 1ms TLS 8ms TTFB 825ms
yyz
359ms
DNS 100ms TCP 1ms TLS 15ms TTFB 340ms

What Authorize.Net does

Authorize.Net is a payment gateway that carries card and eCheck transactions from a merchant's checkout to the bank that actually settles them. Shops reach it through the Accept Suite, the older AIM and SIM integration methods, or the Virtual Terminal for phone orders, which makes it the link every online payment crosses rather than the processor of record.

What an outage looks like

Checkout returns a gateway error or times out at the moment payment is submitted, while the rest of the store loads normally. Recurring billing runs skip, and webhooks stop arriving so orders never move out of pending. The Merchant Interface will not accept a login. Failures are often limited to one acquiring bank, so some cards decline while others succeed.

What to do about it

Check status.authorize.net, which is unusually specific: it lists each acquiring bank separately, including Chase Paymentech, Worldpay, Elavon, TSYS, Global Payments, First Data and American Express Direct, alongside the API, Webhooks, Recurring Billing and Virtual Terminal. Find your own processor in that list before assuming the gateway is down. Do not re-run a transaction that timed out until you confirm it did not settle.

Is it down for everyone, or just you?

If this page says Authorize.Net is up but it is not loading for you, the problem is between you and them. Run a check against any URL from up to 17 cities across three regions to find out where it breaks.

Test it yourself

Related services

Authorize.Net outage FAQ

Is the whole gateway down or just my processor?
Usually just one processor. The Authorize.Net status page tracks every acquiring bank as an individual component, so an incident on Chase Paymentech or Worldpay leaves merchants on Elavon or TSYS unaffected. That is why one store reports total failure while another takes payments normally. Find the bank that settles your transactions in the list rather than reading the summary at the top.
If a payment timed out, was the customer charged?
Possibly, and this is the main risk during a gateway incident. A timeout means the response never came back, not that the transaction failed, so an authorisation can exist without your system recording it. Check the Merchant Interface for the transaction before refunding or re-charging, and avoid letting customers retry blindly, which is how duplicate charges happen.
Do recurring billing and subscriptions catch up afterwards?
Recurring Billing is a separate component and scheduled runs that fall inside an outage window can be missed rather than deferred. Once service returns, review which subscriptions were due during the incident instead of assuming they retried. Failed webhooks are the related problem: orders can sit unfulfilled because the notification never arrived, even though the payment succeeded.
Can I still take payments while the gateway is having problems?
Only through a path that does not use the affected component. The Virtual Terminal, Card Present processing and the API are listed separately, so if one is degraded another may still work for manual orders. If the acquiring bank itself is the failure, no route through Authorize.Net will complete, and taking card details to key in later is the safer fallback.
Is Authorize.Net the same thing as my payment processor?
No, and the distinction matters during an outage. Authorize.Net is the gateway that transports the transaction; a separate acquiring bank authorises and settles it. An outage can sit on either side. The status page reflects this by splitting API and endpoint components from the long list of individual banks under payment gateway processing.

How we measure this

  • We request Authorize.Net's public endpoint every 6 hours from Fly.io regions across six continents — the most recent check ran from 8 of them.
  • A region counts as down only when it gets no usable HTTP response. A 403 or 429 means the origin answered and refused us, which we report as blocked, never as an outage.
  • A single failing region is treated as probe noise. We only change the verdict when two consecutive cycles agree.
  • Response times average only the regions that actually served the page, so a timeout never inflates the number.
  • Where Authorize.Net publishes an official status feed we read it too. An all-clear from the vendor can soften an unconfirmed degradation; a vendor-declared outage only worsens our verdict when our own checks corroborate it.

Get alerted when Authorize.Net goes down

This page refreshes every 6 hours. Your own monitors run as often as every 30 seconds, from up to 17 cities across three regions, and tell you the moment something breaks.

Start Free Monitoring
Free plan available No credit card required