Authorize.Net has told merchants in writing that its oldest integration methods are on the way out and that one common shortcut for passing order details can cost a store its gateway account. Knowledge article 000001205, updated to version 3.0 on September 29, 2026, says the Advanced Integration Method (AIM), Server Integration Method (SIM), Direct Post Method (DPM), Relay Response and Silent Post “are now obsolete and in the process of being phased out.” The same article bars merchants from sending card numbers or personal data through merchant-defined fields and says accounts that ignore repeated warnings may be cancelled.
Both warnings land hardest on older stores. Many high-risk sites still run checkout plugins written years ago for AIM or SIM, and some of those plugins stuff customer details into extra fields so they show up on the email receipt.
What Authorize.Net says is being phased out
The support article lists five legacy pieces: AIM, SIM, DPM, Relay Response (which posted SIM results back to the merchant’s site) and Silent Post. Authorize.Net’s developer upgrade guide marks AIM, SIM, DPM and the SOAP API as deprecated and points each one to a current replacement.
- AIM moves to the Authorize.Net API using XML or JSON.
- SIM moves to Accept Hosted, a hosted payment form that the guide describes as PCI DSS SAQ-A compliant.
- DPM moves to Accept.js, a JavaScript library that sends card data straight to Authorize.Net and returns a one-time token for the store’s server to use.
- Relay Response, according to the developer FAQ, was deprecated along with SIM in favor of Webhooks.
No shutdown date has been published. The upgrade guide says Authorize.Net “will soon announce an end of life timeline” for SIM and that DPM’s sandbox and production end-of-life dates “are to be determined.” For now the company says it will fix bugs in SIM and DPM but add nothing new.
How to tell whether a store is still on AIM
AIM comes in two forms, and only one of them needs a rebuild. The upgrade guide says requests built on what Authorize.Net used to call “AIM XML” are now part of the current API and “can continue to be used as is.”
The older name-value version is the one to hunt for. Those integrations post to a URL ending in transact.dll and use form fields whose names begin with x_, such as x_login or x_amount. A search of a plugin folder or custom checkout code for either string is a quick way to find it. Authorize.Net says those requests should be recreated with the payment transaction methods in its current API reference.
Authorize.Net has changed its legacy endpoints before. In support article KA-07157, Authorize.Net said POST requests to its transact.dll endpoints with query strings attached would be rejected, and it ran a temporary disablement test on November 4, 2024.
EC4IM has compared the replacement options in more depth in Authorize.Net Accept.js vs Hosted Form vs API for High-Risk Checkouts. Stores moving off Relay Response or Silent Post will also need to rebuild how they receive transaction results, which ties into how to harden webhooks and retries.
What merchant-defined fields are for
Merchant-defined fields (MDFs) are extra fields a merchant adds to a transaction that Authorize.Net’s API documentation does not define. Authorize.Net returns them in the transaction response and prints them on the merchant email receipt, but does not pass them to the card processor. The company says they exist for order details such as sizes, colors or quantities.
In the current API, MDFs go in the userFields element of a createTransactionRequest call. In AIM, SIM and DPM, any field not listed in the documentation is treated as an MDF. That second rule matters for old plugins, because a custom field added by a developer years ago may be traveling as an MDF without anyone having labeled it that way.
Data Authorize.Net prohibits in those fields
The article says merchants “are prohibited from capturing, obtaining, or transmitting” primary account numbers or personally identifying information through an MDF. Its list of examples includes:
- Card numbers, expiration dates and card verification codes
- Social Security numbers, tax IDs, driver’s license numbers and passport numbers
- Bank account and ABA routing numbers
- Dates of birth
- Names and contact details
Authorize.Net gives two reasons. Because MDFs appear on the email receipt, the data can be intercepted. And because the fields come back in the transaction response, the merchant’s own systems may end up handling that data in ways that break the Payment Card Industry Data Security Standard (PCI DSS). The article also cites state and federal privacy laws, including the Gramm-Leach-Bliley Act, HIPAA and California’s SB 1386.
Including names and contact details stretches the rule well beyond card data. A telehealth checkout that copies a patient’s date of birth into a custom field, or a supplement store that adds the buyer’s phone number to the receipt, would fall inside the prohibition. Those values belong in the fields Authorize.Net’s API defines for billing and customer information.
What happens to accounts that keep sending it
Authorize.Net says merchants found using MDFs for card or personal data will be told about the violation and its possible consequences. If the problem is not fixed after repeated attempts to reach the merchant, the payment gateway account “may be subject to cancellation.” The article adds that merchants acting in good faith who have contacted Merchant Support for help “will not be in danger of having their account canceled.”
For a high-risk merchant, losing a gateway account can mean reapplying with a new provider under fresh underwriting, so the warning is worth taking seriously even though no enforcement date is attached.
What to check before Authorize.Net sets a date
Authorize.Net has now put two separate problems in one article. AIM, SIM, DPM, Relay Response and Silent Post still run, but the company calls them obsolete, has promised an end-of-life timeline for SIM and has no dates yet for DPM. Merchant-defined fields remain available for order details, while card numbers, names, contact details, birth dates and bank data are off limits, with cancellation possible for stores that do not respond to warnings. A developer who searches the checkout code for transact.dll, x_ fields and custom receipt fields can check for both problems in one pass.
Sources
- Authorize.Net Support Center, Knowledge Article 000001205, Merchant-Defined Fields (version 3.0, September 29, 2026)
- Authorize.Net Developer Center, Upgrade Guide
- Authorize.Net Support Center, Authorize.net Integration Methods Explained
- Authorize.Net Developer Center, Frequently Asked Questions
- Authorize.Net Support Center, API Endpoint Breaking Change, POST Method Query String End-of-Life (KA-07157)