Lock down your Authorize.Net account.

A shared login makes it impossible to tell who did what, and one leaked password compromises everyone. Stop sharing the owner username and password. Create a separate login for each person and grant only the permissions their job needs. A cashier doesn’t need refund or user-management rights.

Reused passwords are one of the most common ways payment accounts get taken over, and it is usually not Authorize.Net that was breached but a password recycled from somewhere else. Use something long and unique, generated by a password manager, and change it immediately if it has ever been used elsewhere.

A stolen password is useless from a blocked location. If your team always logs in from the same office, store, or VPN, turn on IP-based login restriction so the portal refuses connections from anywhere else. Credential stuffing runs from wherever the attacker happens to be, so a portal that only accepts your own addresses takes that whole category off the table.

This is Authorize.Net’s built-in fraud engine, but several filters ship set to monitor-only, which doesn’t stop anything; it just tells you afterward. At minimum, enable AVS Mismatch, Card Code (CVV) Mismatch, and Velocity (hourly/daily), and set each to decline.

A CVV or address mismatch is the strongest early signal you have that a card number was stolen rather than typed by its owner. For card-not-present transactions, require both CVV and AVS to match before a charge is accepted, not just recorded as a note on the transaction.

This is the most common gap we find: a former employee’s login still active months, sometimes years, after they left. Disable or delete the login the day a staff member or contractor’s relationship with you ends, not at the next convenient review.

Duplicate charges generate disputes, and disputes generate chargebacks, which count against your merchant standing. Set a sensible detection window (Authorize.Net defaults to 120 seconds) so an accidental page refresh or double-click doesn’t charge a customer twice.

You want to know about a fraud spike within minutes of it starting, not when you reconcile the books at month end. Set up email or SMS alerts for declines, refunds, and anything the fraud filters flag.

This is the change that most reduces both your risk and your annual paperwork. Confirm with your web developer that card numbers are typed directly into an Authorize.Net-hosted field, via Accept Hosted or Accept.js, and never pass through your own server. Which PCI questionnaire you then qualify for depends on how the page is built: a fully hosted payment page is normally the shortest one, while a form served by your own site can land on a longer version.

An endpoint that trusts content alone can be sent a forged "payment succeeded" message by anyone who finds the URL. If anything on your site listens for payment confirmations, confirm with your developer that it checks the signature Authorize.Net sends, not merely that the message arrived over HTTPS. Silent Post is the older mechanism and webhooks are the current one, so an older site is worth asking about specifically.

This is where Tier 1’s "cut access on exit" quietly breaks down over time: it only works if someone occasionally checks. Open User Administration and check each account against someone who actually still works with you today.

These credentials can move money and issue refunds programmatically, so they deserve the same care as a password, and they’re often forgotten because no one types them by hand. Regenerate your API Login ID and Transaction Key (or Signature Key) on a regular schedule, and immediately if anyone with access leaves.

A stored card number is a liability from the moment it exists, and a token is not. Keep full numbers out of email, spreadsheets, chat and your own database. For recurring billing, use the Customer Information Manager (CIM) so Authorize.Net stores the card and hands you a token instead.

Fraud patterns shift. A filter set correctly last year can be quietly under-protecting you now, with no alert telling you so. Look for filters triggering constantly, which may need tuning, and filters that never trigger, which may be misconfigured or too loose.

It is a card network requirement rather than an option, and a useful check on whether your setup has drifted. Which questionnaire applies depends on how card entry is built, and your acquirer confirms which one you are on, so ask them rather than assuming the shortest.