Authorize.Net's sandbox is a separate test environment with its own login and its own API credentials, built so you can run full transactions against published test card numbers without ever touching a real charge. It tells you whether a call works. It doesn't tell you what your business is supposed to do once a real one settles, declines, or comes back flagged for review. We build that second part.
1. Create a sandbox account. Sign up separately at Authorize.Net's own sandbox environment, a different URL and login from your live Merchant Interface, which gives you an API Login ID and Transaction Key scoped only to test mode.
2. Pull your sandbox credentials. The path is the same as production: Account, then Security Settings, then API Credentials & Keys, just inside the sandbox account instead of the live one.
3. Use a current test card number. Authorize.Net publishes a fixed list of test card numbers for each major card brand in its own developer documentation, and that list occasionally changes. Pull it from developer.authorize.net directly when you need it rather than relying on a number copied from somewhere else that might be stale.
4. Check the response code, not just whether the call returned. Every transaction response carries a numeric response code: 1 means approved, 2 means declined, 3 means an error, 4 means held for review. An integration that only checks whether the API call succeeded, without branching on that code, can treat a declined card as a completed sale.
5. Swap in live credentials once it's verified. Moving to production means changing the API Login ID, Transaction Key, and endpoint URL. The request structure your code sends doesn't change at all between sandbox and live.
Confirming a test call works tells you the connection is right. It doesn't tell you what should happen inside your business when a real transaction declines, errors out, or comes back days later during batch settlement instead of at the moment of the original charge.
Response code 4, held for review, is the one most integrations handle worst. It isn't approved and it isn't declined, it's sitting in Authorize.Net's own fraud review queue waiting on a decision, and plenty of integrations only ever check for a clean approval, so a held transaction just disappears from view until a customer asks where their order is.
If you're seeing errors and suspect Authorize.Net itself is down rather than your integration, check Authorize.Net's own status page first. It's a quick way to rule out your own code before spending an afternoon debugging something that isn't actually broken on your end.
A code 3 or a code 4 gets flagged to the right person the moment it comes back, instead of getting lumped in with a normal decline or missed entirely because the integration only checked for success.
When credentials flip from test to live, an automation can confirm the first real transaction actually settles correctly before anyone fully retires the manual fallback that was covering the gap.
Tell us what your integration currently does, or doesn't do, when a real transaction comes back as anything other than a clean approval, and we'll look at where that logic actually needs to live.
A sandbox test proves the call works. It's the transaction that comes back declined, errored, or held for review days later that actually needs a decision built around it, and most of that decision doesn't need to wait on a person checking a report. Authorize.Net is just this page's example; n-frames builds the same kind of response logic around any integration that currently only has a plan for the happy path.
Let's talk →In Authorize.Net's own developer documentation at developer.authorize.net. The published list covers each major card brand and is specific to the sandbox environment, and since it can change, it's worth pulling the current version rather than reusing a number from an old reference.
Sandbox credentials run against test card numbers in a separate test environment, so you can build and verify an integration without moving real money. Switching to production puts the same calls in front of live cardholder transactions. The API call structure itself doesn't change between the two.
1 means the transaction was approved. 2 means it was declined. 3 means there was an error processing it. 4 means it's being held for fraud review. An integration that only checks for success without branching on this code risks treating a decline or a hold as a completed sale.
It means the transaction triggered one of Authorize.Net's fraud detection filters and is sitting in a review queue instead of being approved or declined outright. It needs a manual decision, through the Merchant Interface or an automated rule, before it settles either way.
Check Authorize.Net's own status page before assuming the problem is in your own integration. It's a quick way to rule out a platform-wide issue versus something specific to your code or credentials.
No. The sandbox is a separate, free test environment specifically so you can build and verify an integration before it ever touches a real transaction or a live merchant account.