Authorize.net

Adapter 0.2.0, documentation reviewed 2026-10-25. Overall status: limited.

Capabilities

Supported input

Notification delivery

• Repeated deliveries are recognized by notificationId.
• Delivery order: not documented by the provider.
• Make the webhook handler idempotent: record processed notificationId values and check the transaction with getTransactionDetails before acting. Authorize.net retries a failed delivery up to 10 times (3 at three-minute intervals, 3 at eight-hour intervals, 4 at 48-hour intervals) and then deactivates the webhook; its notification history groups all attempts under one notificationId, but the documentation does not state that retries reuse it.

Known limitations

• Two result layers are decoded separately: transactionResponse.responseCode (1 approved, 2 declined, 3 error, 4 held for review) and the transaction response reason codes in errors[].errorCode and messages[].code. Reason codes 1-4 have different meanings from responseCode 1-4, so the two values are never looked up in each other's table. The API-level messages.resultCode (Ok/Error) and its I/E codes form a third, independent table; E00027 only says that the transaction layer carries the reason.
• Many reason codes share the same customer-facing text and differ only in Authorize.net's integration suggestions; the decoded meaning follows the suggestions. Code 38 has conflicting meanings in Authorize.net's two response code files, codes 104-110 say under review while their suggestions describe eCheck validation failures, code 103 is documented as no longer in use and code 2201 appears only in the second file; these are decoded with possible confidence. Processor-specific codes (FDC Omaha, Concord EFS, Wells Fargo SecureSource, TSYS, WePay) are decoded as documented, but the documentation does not say which of these processors are still in use.
• Authorize.net publishes no example of a declined (responseCode 2) or held (responseCode 4) createTransactionResponse, so the API-level code that accompanies them is not documented. responseCode 3 is treated as an unknown outcome when its reason code describes a processor, network or unexplained error, because the original may have been processed.
• createTransactionResponse does not echo transactionType. A response without refTransID is shown as a payment, one with refTransID as a follow-up (stage other) because a capture, void, refund or PayPal continue step cannot be told apart. transId 0 is returned for errors and in test mode and is not used as a reference.
• createTransactionResponse has no amount, currency or timestamp. Prepaid requested and approved amounts are shown as supplied; no amount is converted to minor units and amount checks do not run.
• Webhook payloads are known only from examples: they carry the transaction's own id, responseCode, authCode, avsResponse and authAmount, but no reason code, no parent transaction id, no currency and no invoice number. A refund webhook therefore cannot be linked to its original sale unless the refund's API response (transId with refTransID) is also supplied. Declines and errors in webhooks are shown without a reason; call getTransactionDetails for the reason and the current status.
• Webhook responseCode values other than 1-4 (the documentation's failed-delivery example shows 0) are shown as undocumented. Whether capture.created is also sent for captureOnly transactions, and whether payment events are sent for declines, is not documented. A refund.created event is shown as pending because the refund settles in a later batch.
• net.authorize.customer.subscription.failed has no description beyond its name and is shown as a subscription failure; subscription events carry the subscription id only and are not linked to the transactions they create. Customer profile and payment profile events are shown without their profile ids.
• The X-ANET-Signature header (HMAC-SHA512 with the merchant's Signature Key) is sensitive and is never verified or copied; only its presence is shown. Its exact value format is not documented. transHash and transHashSha2 are integrity values tied to the Signature Key and are never copied.
• Webhook delivery order is not documented. notificationId is used as the delivery key: the notification history groups all attempts under it, but the documentation does not state that retries reuse it.
• AVS, card code and CAVV results are informational; a no-match result is mentioned on a decline only as a possible factor. Filter rejections appear as reason codes (27, 44, 45, 65, 127, 165). merchantAdvice codes (TSYS) are shown but not interpreted because their values are not documented. rawResponseCode, testRequest and SupplementalDataQualificationIndicator have no documented meaning and are not read.
• Card numbers, expiration dates, card codes, bank account data, track and EMV data, opaque wallet data, names, addresses, emails, IP addresses, PayPal payer data and URLs, user fields, auth codes and the masked accountNumber are never copied. API Login ID, transaction key and access tokens are never copied.
• XML is read only from documents whose root element is declared in the AnetApiSchema.xsd namespace (AnetApi/xml/v1/schema/AnetApiSchema.xsd) and ends in Response; XML without that namespace declaration and XML requests are not recognized. The XML lists (<messages><message>, <errors><error>, <splitTenderPayments><splitTenderPayment>) are read as the JSON arrays, a single item included, and attributes such as xsi:nil are ignored. One documented XML example places <message> directly under <transactionResponse>; that form is accepted too. NMI runs an Authorize.Net emulator that covers XML; whether it answers with this namespace is not documented, and if it does, the document alone cannot tell the two apart.
• getTransactionDetails responses (JSON or XML), notification history records and partner boarding webhooks are recognized but not analyzed. Legacy AIM, SIM, DPM, Silent Post and Relay Response formats and the Accept Hosted transactResponse message are not recognized; an Authorize.net-shaped legacy payload may also come from another gateway's emulator.
• Category and retry guidance per code are PandaPayLens suggestions based on Authorize.net's descriptions and integration suggestions, not Authorize.net statements.

Examples

• Authorize.net: capture and refund: Authorization and capture webhooks, the refund response and the refund webhook in one transaction.
• Authorize.net: card declined: The transaction reason code decoded separately from the response code, with AVS and card code results.

Provider documentation

• Response code reference
• Response code list (JSON)
• API reference
• Webhooks
• Payment transactions
• Transaction reporting
• Recurring billing
• Testing guide
• Transaction hash upgrade
• Upgrade guide (legacy methods)
• API schema (XSD)

PandaPayLens is not affiliated with Authorize.net. Pasted notifications are never treated as verified: PandaPayLens does not check webhook signatures.