Authorize.Net Integration Methods: Accept Hosted, Accept.js, API and Legacy SIM/AIM

Every business that takes cards has to meet PCI DSS, the card industry's security standard. Most small businesses prove it each year with a self-assessment questionnaire (SAQ). The less card data your own website and servers touch, the shorter that questionnaire is. So the first question isn't "which is easiest to code?" It's "where do card numbers get typed, and where do they go?"

Authorize.Net's developer documentation, checked September 27, 2026, assigns each of its Accept tools a questionnaire:

Authorize.Net bases its SAQ ratings on a white paper by Coalfire, a PCI assessor. Your acquiring bank has the final say on which questionnaire you file, so confirm it with your merchant account provider. For what each questionnaire involves, see our PCI compliance basics.

Simple Checkout is still live. In Authorize.Net's words: "Create a Buy Now or Donate button, share a payment link, or generate a QR code. No website required." The customer lands on a secure payment form that Authorize.Net hosts.

• What you can sell: products (physical or digital), services, and donations where the giver picks the amount.
• Where it goes: a button on any web page, a link in an email or text, or a QR code on a flyer, invoice or counter sign.
• Cost: Authorize.Net's feature page says there's no setup fee; standard transaction fees apply.

It suits a service business, a nonprofit, an event or a small catalog. It's not a store: there's no product catalog beyond your buttons, and no customer accounts. If you mainly bill people after a phone call, invoices and payment links from the Authorize.Net virtual terminal may fit better. For taking payments on a phone or at events, see mobile payment processing with Authorize.Net.

With Accept Hosted, your site hands the shopper to a payment form that Authorize.Net hosts, either as a full page or as a pop-up or frame inside your page. The customer types the card number into Authorize.Net's form, not yours. Authorize.Net rates it SAQ A.

How it works, in short:

1. Your server asks Authorize.Net for a form token, with the amount and order details.
2. Your page opens the hosted form using that token.
3. The customer pays, and Authorize.Net sends them back to your site.
4. Your server confirms the result, ideally through a webhook (see below) rather than trusting the browser.

Accept Hosted is the official replacement for SIM (Server Integration Method), the older hosted form. If your site posts a form with x_fp_hash "fingerprint" fields to Authorize.Net, that's SIM, and Accept Hosted is where you move.

A related tool, Accept Customer, is a hosted form for customers to save and manage their own cards. It's also SAQ A and replaces the retired Hosted CIM forms. Saved cards are covered in our guide to recurring billing and saved cards (CIM).

Accept.js is a JavaScript library that lets the card form sit on your own checkout page. When the customer clicks Pay, the script sends the card details straight from their browser to Authorize.Net. Authorize.Net sends back a one-time token, called a payment nonce. Your server receives only the nonce, never the card number, and uses it to run the charge.

• The nonce is valid for 15 minutes, per the Accept.js documentation. Charge it promptly.
• You need a Public Client Key, generated in the Merchant Interface, in addition to your API keys.
• Two ways to use it: your own form (SAQ A-EP) or Accept.js UI, Authorize.Net's ready-made form embedded on your page (SAQ A).

SAQ A-EP is longer than SAQ A because your page controls the form: if someone tampered with it, they could skim cards before the script runs.

Accept.js replaces DPM (Direct Post Method). DPM posted the card form from your page straight to Authorize.Net, then sent the result back through Relay Response. Relay Response is now obsolete.

The Authorize.Net API is the server-side connection that everything else rests on. It handles charges, refunds, voids, subscriptions, saved customer profiles and reports, using XML or JSON. Here's what a business owner should know before hiring a developer:

• Sandbox first. Developers build against a free sandbox account. It works like the live system but doesn't process real card payments.
• API Login ID and Transaction Key. These two credentials connect your site or cart to your gateway account. You find them in the Merchant Interface under Account › Settings › Security Settings › API Credentials and Keys. Treat the Transaction Key like a password, and never email it.
• Signature Key. A separate key used to check that responses and notifications really came from Authorize.Net (an HMAC-SHA512 hash). You need one before you can receive webhooks.
• Webhooks. Authorize.Net posts a message to your server when something happens, such as a payment settling, a refund or a subscription payment failing. Authorize.Net says webhooks replace Silent Post.

If your developer uses the API to send card numbers from your own server, your servers handle card data and fall inside PCI scope. Pair the API with Accept.js or Accept Hosted to keep card numbers off your servers.

Locking the API to your server's IP addresses also helps. The Authorize.Net Fraud Detection Suite includes a filter that accepts API requests only from IP addresses you authorize, which helps block card-testing attacks.

Many older carts and custom sites still connect through AIM (Advanced Integration Method), SIM (Server Integration Method) or DPM (Direct Post Method). All three are deprecated. Here's what that means, based on Authorize.Net's upgrade guide and support article 000001462, checked September 27, 2026:

• They still work, for now. The upgrade guide calls them "supported but no longer actively maintained or enhanced." In practice that means fixes, but no new features.
• They're on the way out. The support article says AIM, SIM, DPM, Relay Response and Silent Post "are now obsolete and in the process of being phased out."
• No shutdown date yet. For SIM, the guide says Authorize.Net "will soon announce an end of life timeline." For DPM, the dates are "to be determined." When a date comes, you may have little time to react, so plan the move now.
• AIM depends on which kind you have. "AIM XML" requests are now part of the current API and "can continue to be used as is." The older name-value version, which posts x_ fields to a URL ending in transact.dll, should be rebuilt with the current API.

Three changes have already happened, so an old integration may be half-broken already:

• MD5 hash is gone. Authorize.Net removed the MD5 hash setting in 2019. Responses are now verified with transHashSHA2, a SHA-512 hash built with your Signature Key. If your code checks an MD5 hash, it's either failing or skipping the check.
• TLS 1.2 is the floor. Authorize.Net connections use TLS 1.2. Support article 000001526 (last modified August 31, 2026) says TLS 1.3 works on Authorize.Net's portals only for now, with the API to follow. Very old servers that can't use TLS 1.2 can't connect.
• Several methods are already end of life: Hosted CIM forms (returning an error since September 20, 2018), HTTP GET requests and WebLink. The SOAP API is deprecated.

Migration checklist

Not sure what your site uses? Ask whoever built it, or check your cart's payment settings. If a plugin asks only for an API Login ID and Transaction Key, look at its version and release notes. An old plugin is a common sign of an old connection method. If your cart is a hosted platform, see Authorize.Net shopping cart integrations for what each platform supports now.

Authorize.Net supports Apple Pay and Google Pay, but only on certain processors. The processor is the company behind your merchant account that actually handles the card transaction. So whether wallets work for you depends on your merchant account, not just the gateway.

Here's what Authorize.Net's support articles list, checked September 27, 2026:

• No extra gateway fee. Both articles say Authorize.Net doesn't charge a separate fee for Apple Pay or Google Pay.
• Your integration has to support it too. Check that your cart plugin or checkout shows the wallet buttons. A custom build needs developer work, and Apple Pay on the web also needs your domain set up with Apple.
• PayPal is separate. Authorize.Net notes that PayPal Express Checkout through the gateway is "not supported by some resellers."

These lists change, so don't build a checkout around a wallet until you've confirmed it. Ask your provider which wallets your account supports.

Most businesses don't need a developer. If you sell through a hosted cart or WordPress, the integration is a plugin and two keys. If you don't have a website, Simple Checkout covers it. You need a developer when you're building a custom checkout or moving a custom site off SIM, DPM or name-value AIM.

START has worked with Authorize.Net for more than 20 years and has set up over 60,000 Authorize.Net accounts. We set up your merchant account and gateway together, so the account is ready when your site or developer connects. Tell us your platform and how it connects today, and we'll tell you what's involved on the account side.

For an overview of fees, features and setup, see our Authorize.Net payment gateway guide. Before launch, run through the chargeback prevention checklist.