Skip to main content

Is Authorize.Net Down?

No — Authorize.Net is up

Reachable from all 8 checked regions

Average response time: 506ms

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
374ms
Avg response, 30 days

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

30-day history

24-day clean streak
Jul 25: no data
Jul 26: no data
Jul 27: no data
Jul 28: no data
Jul 29: no data
Jul 30: no data
Jul 31: 100.00% uptime, 24 checks
Aug 1: 100.00% uptime, 31 checks
Aug 2: 100.00% uptime, 32 checks
Aug 3: 100.00% uptime, 40 checks
Aug 4: 100.00% uptime, 32 checks
Aug 5: 100.00% uptime, 31 checks
Aug 6: 100.00% uptime, 40 checks
Aug 7: 100.00% uptime, 32 checks
Aug 8: 100.00% uptime, 40 checks
Aug 9: 100.00% uptime, 32 checks
Aug 10: 100.00% uptime, 32 checks
Aug 11: 100.00% uptime, 32 checks
Aug 12: 100.00% uptime, 32 checks
Aug 13: 100.00% uptime, 32 checks
Aug 14: 100.00% uptime, 32 checks
Aug 15: 100.00% uptime, 32 checks
Aug 16: 100.00% uptime, 32 checks
Aug 17: 100.00% uptime, 32 checks
Aug 18: 100.00% uptime, 32 checks
Aug 19: 100.00% uptime, 24 checks
Aug 20: 100.00% uptime, 40 checks
Aug 21: 100.00% uptime, 40 checks
Aug 22: 100.00% uptime, 32 checks
Aug 23: 100.00% uptime, 32 checks
Jul 25 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.

bom
336ms
DNS 24ms TCP 3ms TLS 13ms TTFB 321ms
cdg
221ms
DNS 32ms TCP 1ms TLS 9ms TTFB 213ms
dfw
361ms
DNS 115ms TCP 1ms TLS 9ms TTFB 333ms
ewr
169ms
DNS 47ms TCP 2ms TLS 10ms TTFB 158ms
fra
263ms
DNS 67ms TCP 3ms TLS 13ms TTFB 255ms
gru
414ms
DNS 199ms TCP 3ms TLS 11ms TTFB 403ms
iad
507ms
DNS 240ms TCP 1ms TLS 10ms TTFB 471ms
jnb
1785ms
DNS 218ms TCP 0ms TLS 9ms TTFB 1654ms
lax
331ms
DNS 226ms TCP 1ms TLS 10ms TTFB 324ms

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 all 18 regions to find out where it breaks.

Test it yourself

Related services

Stripe
Stripe
Square
Square
Affirm
Affirm
QuickBooks Online
QuickBooks Online

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 — 8 of them answered the most recent check.
  • 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 the same 18 regions, and tell you the moment something breaks.

Start Free Monitoring
Free plan available No credit card required