Authorize.Net
Connect your Authorize.Net merchant account to process credit card and ACH transactions through Preczn.
Connect your merchant's Authorize.Net account to process credit card and ACH (eCheck) transactions through Preczn.
Authorize.Net is a direct processor: each merchant holds their own Authorize.Net account, and the two Authorize.Net credentials are stored on that merchant's connection in Preczn. There is no merchant boarding. A merchant must already have an Authorize.Net account before it can be connected.
Supported Capabilities
| Capability | Status | Notes |
|---|---|---|
| Credit Card Transactions | Supported | Full lifecycle: sale, auth, capture, void, refund, and verify |
| ACH (Bank Account) Transactions | Supported | eCheck payments using bank routing and account numbers |
| Level II Data | Supported | Tax and duty amounts |
| CVV Results | Supported | Returned on sale, auth, and verify transactions |
| Apple Pay / Google Pay | Not supported | Wallet transactions cannot be routed to Authorize.Net |
| Merchant Onboarding | Not supported | Merchants sign up with Authorize.Net directly, then link their account |
Supported Transaction Types
| Type | Description |
|---|---|
| Sale | Authorize and capture in a single request |
| Auth | Authorize only (hold funds without capturing) |
| Capture | Capture a previous authorization, in full or in part |
| Void | Cancel an auth or sale before it settles |
| Refund | Return funds from a completed transaction, in full or in part |
| Verify | Validate a card without charging it (see Verify) |
Adding Merchant Credentials
Authorize.Net requires two values, both found in the merchant's Authorize.Net Merchant Interface. Both are required. A connection saved without either one is rejected.
| Credential | API field | CSV column | Description |
|---|---|---|---|
| API Login ID | key | AuthorizeNet_api_login | Identifies the merchant's account |
| Transaction Key | secret | AuthorizeNet_transaction_key | Authenticates requests for that account |
Credential VerificationPreczn verifies Authorize.Net credentials with Authorize.Net when you save them, so a mistyped API Login ID or Transaction Key is caught at configuration time rather than on the first transaction.
Enter them on the merchant's Authorize.Net connection in the Dashboard, or send them to the connection update endpoint. See Linking Existing Credentials. They can also be supplied when importing merchants via CSV, using the column headers in the table above.
Required Payment Form Fields
Authorize.Net lets a merchant mark payment form fields as required, and those settings apply to API transactions too. When a transaction is missing a field the merchant marked required, Authorize.Net rejects it before it reaches the processor. The transaction returns E (Error), with one message per missing field in errors.
Card Code, Authorize.Net's term for the card verification value (CVV), is the field merchants most often have marked required. The Payment Card Industry Data Security Standard (PCI DSS) doesn't allow the CVV to be stored after authorization, so Preczn never keeps it with a stored token. A transaction that uses a stored token therefore never includes a card code, and on these accounts every token transaction fails with "Card Code is required." Card Code must not be required on any merchant that charges stored tokens.
Other required fields cause the same failure. For example, if the merchant requires First Name and Last Name, a transaction without them fails with "Bill To First Name is required." and "Bill To Last Name is required." First and last name reach Authorize.Net only when the transaction also includes billingAddress.
Before you process transactions, have the merchant review these settings in the Authorize.Net Merchant Interface. Authorize.Net controls its Merchant Interface, so the menu names below reflect it at the time of writing and may change. If the merchant can't find the setting, Authorize.Net support can point them to the current Form Fields settings.
- Go to Payments > Payment Settings > Payment Forms > Form Fields.
- Clear Required on Card Code if the merchant charges stored tokens.
- For any other field marked Required, confirm that every transaction you send includes it, or clear Required.
- Save the settings.
Authorize.Net still checks a card code when a transaction includes one.
Processing Transactions
Route transactions to Authorize.Net the same way as any other connection: through a plan or a direct connection reference on the transaction. The sections below cover the behavior specific to Authorize.Net.
Outcomes and Held Transactions
Authorize.Net returns the outcome of every transaction on the API response itself. Most transactions are A (Approved), D (Declined), or E (Error) the moment the request completes.
A transaction that Authorize.Net's fraud filters hold for review returns as P (Pending). The merchant approves or declines a held transaction in the Authorize.Net Merchant Interface.
Held transactions stay Pending in PrecznPreczn does not receive an update when the merchant approves or declines a held transaction in Authorize.Net. The Preczn transaction stays
P(Pending). Check the outcome in the Authorize.Net Merchant Interface.
Verify and Card Checks
A Verify on an Authorize.Net connection is performed as a zero-dollar authorization, so it validates the card without moving money and without a capture to reverse.
Captures and Refunds
Captures and refunds may be for the full amount or a partial amount. A full capture or refund uses the approved amount of the original transaction.
CVV Results
Authorize.Net returns a card-code verification result on sale, auth, and verify transactions, and Preczn normalizes it to its standard values:
| Preczn result | Meaning |
|---|---|
M | Match |
N | No match |
U | Unavailable or not checked |
Send the CVV to get a meaningful result. Transactions that use a stored token carry no CVV, so they return U.
Stored Credentials and Card on File
Preczn does not send a stored-credential or card-on-file indicator to Authorize.Net. A transaction that uses a stored payment token reaches Authorize.Net as a standard card-not-present transaction with no card code, whatever usage type the token carries.
Because no card code is sent, the merchant's Authorize.Net account must not require one. See Required Payment Form Fields.
Level II Data
Authorize.Net accepts Level II data, which can qualify commercial and purchasing-card transactions for better interchange:
| Preczn field | Sent to Authorize.Net as |
|---|---|
tax | Tax amount |
dutyTax | Duty amount |
order | Purchase order number |
Tax and duty are not sent on a Verify. See Level II Data for how to populate these fields.
Data Sent to Authorize.Net
Preczn forwards the following with each sale, auth, and verify:
- Cardholder first and last name
- Billing address and shipping address
- Customer IP address
- Invoice number (
invoice) and description (description) - Metadata, as Authorize.Net user fields
Two fields are truncatedThe invoice number is truncated to 20 characters, and the description to 255 characters. Longer values reach Authorize.Net cut short. The full values stay intact on the Preczn transaction.
Authorize.Net's API has no field Preczn maps the following to, so these are accepted by Preczn and used elsewhere but never reach Authorize.Net:
- Email address and phone number
- Freight amount (
freightTax) - The tax-exempt flag (
taxExempt) - Dynamic statement descriptors
Transaction Status Mapping
| Authorize.Net response | Preczn status | What it means |
|---|---|---|
| Approved | A Approved | The transaction succeeded; processorTransactionId carries Authorize.Net's transaction ID |
| Declined | D Declined | Authorize.Net or the issuer rejected the transaction |
| Held for review | P Pending | A fraud filter held the transaction (see Held Transactions) |
| Error | E Error | Authorize.Net could not process the request, such as a missing required field or invalid credentials |
On a decline or hold, Authorize.Net's own response text is surfaced as processorMessage. On an error, Authorize.Net's error text is returned in errors.
Testing in the Sandbox
- Create a sandbox account at developer.authorize.net.
- Add the merchant's Authorize.Net connection in Test Mode using the sandbox API Login ID and Transaction Key.
- Send transactions using the standard Preczn test cards. Preczn substitutes Authorize.Net's sandbox card and bank account numbers automatically, so no processor-specific test data is needed for approvals.
Test and Live connections are configured separately, and Preczn routes each transaction to the matching Authorize.Net environment based on the mode it runs in.
If you resend the same test card and amount within two minutes, Authorize.Net rejects the second transaction as a duplicate. See the FAQ.
FAQ
Where do I find the API Login ID and Transaction Key?
Both come from the merchant's Authorize.Net Merchant Interface. A merchant who cannot locate them should contact Authorize.Net support. Preczn cannot retrieve them.
Why does a transaction fail with '… is required'?
The merchant's Authorize.Net account marks that field as required, and the transaction didn't include it. Authorize.Net rejects these transactions before they reach the processor, so the cardholder is never charged. The most common case is "Card Code is required." Card Code is Authorize.Net's term for the CVV, which can't be stored with a token under PCI DSS, so a transaction that uses a stored token never carries one. Clear the setting as described in Required Payment Form Fields, or include the field in your transactions, then retry.
Why does a transaction fail with 'A duplicate transaction has been submitted'?
Authorize.Net rejects a transaction that matches one submitted in the previous two minutes. It compares fields such as the card or bank account, amount, transaction type, invoice number, and billing details. Preczn returns the rejected transaction as E (Error) with Authorize.Net's message in errors. Its processorTransactionId is 0 because Authorize.Net doesn't create a transaction. The earlier transaction is unaffected, and the cardholder isn't charged twice.
To send an intentional repeat charge, wait two minutes or give each transaction a unique invoice. Preczn truncates invoice numbers to 20 characters, so two values that differ only after the 20th character still match. Preczn uses Authorize.Net's default two-minute window and doesn't change it.
Why is a transaction stuck in Pending?
Authorize.Net's fraud filters held it for review. Preczn does not receive the outcome when the merchant approves or declines it, so the Preczn transaction stays Pending. Check the transaction in the Authorize.Net Merchant Interface for its final state.
Can I send Apple Pay or Google Pay transactions?
No. Wallet transactions cannot be routed to Authorize.Net. Route wallet volume to a connection that supports it. See Apple Pay on the Web and Google Pay for Web.
Why is my invoice number shortened on the Authorize.Net side?
Authorize.Net's invoice number field accepts 20 characters, and Preczn truncates longer values. The full value stays intact on the Preczn transaction. Only the copy sent to Authorize.Net is shortened. If you reconcile between systems using the invoice number, keep it within 20 characters.
Does a Verify charge the cardholder?
No. A Verify on Authorize.Net is run as a zero-dollar authorization, so no funds are captured and there is nothing to void afterward. It confirms the card is valid and returns a CVV result.
Can I board new merchants to Authorize.Net through Preczn?
No. Preczn connects merchants who already hold an Authorize.Net account. It does not submit applications to Authorize.Net. Once the merchant has their API Login ID and Transaction Key, add them to the merchant's connection and transactions can be routed immediately.
Updated 4 days ago