authorize.net E00013: merchant login id invalid after a sandbox-to-live key swap

TL;DR

E00013 means the API login ID and transaction key do not form a valid pair for the endpoint you called: after a sandbox-to-live key swap, code usually still points at the wrong environment or carries a stale key. Match each environment to its own login ID, transaction key, and endpoint (sandbox vs production), then retry. Never mix a sandbox key with the production endpoint.

authorize.net E00013: merchant login id invalid after a sandbox-to-live key swap

Use this when

• Authorize.net returns E00013 after moving from sandbox to live
• You just rotated the transaction key
• One environment works while the other fails authentication

Not for this skill when

• The transaction is declined by the issuer (different error family)
• You are debugging AVS or CVV mismatches
• The error is about the request format rather than credentials

Steps

1. Confirm which endpoint your code calls: the sandbox endpoint needs sandbox credentials, production needs live credentials. Expected: You know the endpoint in use.

2. In the Authorize.net merchant interface, verify the API login ID for that environment. Expected: The login ID matches the environment.

3. Generate a new transaction key for that environment and update your config with both values together. Expected: Login ID and transaction key are a fresh, matching pair.

4. Check for whitespace or copy errors in the stored credentials. Expected: The values are clean.

5. Retry the transaction. Expected: E00013 is gone and the request authenticates.

6. Store sandbox and live credentials under separate config keys so a deploy cannot mix them. Expected: Environments can never cross credentials again.

Tool compatibility

Authorize.net API (AIM/ARB/CIM and the modern API endpoints); E00013 is returned by the gateway on credential mismatch.

Variant phrasings

authorize.net E00013 invalid merchant login

Short form of the same authentication error.

authorize.net sandbox to production key swap error

The migration scenario that triggers it.

authorize.net api login id transaction key mismatch

The credential-pair cause stated directly.

Why it happens

Authorize.net authenticates every request with an API login ID plus a transaction key, and both are issued per environment. Sandbox and production are separate accounts with separate pairs, and the gateway validates the pair against the endpoint that received the call. After a sandbox-to-live swap, the usual failure is a stale config: the production endpoint gets the sandbox pair, or the login ID was updated but the transaction key was not. The gateway cannot tell a typo from a wrong-environment key, so it reports the login ID as invalid.

Edge cases / pitfalls

• Generating a new transaction key invalidates the old one immediately: update all servers at once or you will break the ones still on the old key.
• The merchant interface login is separate from the API login ID; do not confuse the two.
• If you use a relay or hosted form, its credentials may live in a different config file than your API calls.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_uwbvnW69rlLKZwCsCl1Yhw