Setting up payment processing in healthcare isn't optional, it's infrastructure. Whether you're collecting co-pays for patient transport, invoicing for durable medical equipment deliveries, or managing recurring billing for home health services, you need a gateway that works. That's where Authorize.Net payment gateway documentation comes in: it's your starting point for building reliable, PCI-compliant payment flows into the systems your organization depends on.

At VectorCare, we built our Pay module to handle the billing complexity that healthcare logistics creates, custom invoicing, ACH and credit card processing, automated notifications. We understand firsthand how critical it is to get payment integrations right the first time. Authorize.Net remains one of the most widely adopted gateways in the industry, and knowing how to work with its API gives your development team a real advantage.

This guide walks you through the essentials: API authentication, sandbox testing, transaction endpoints, and the core request/response structures you'll encounter during integration. Whether you're a developer wiring up payments for the first time or an operations lead evaluating technical feasibility, you'll leave with a clear path from documentation to working implementation.

What Authorize.net provides and how the docs fit together

Authorize.Net is a payment gateway owned and operated by Visa that processes credit cards, debit cards, eChecks, and select digital wallets through a single API layer. It sits between your application and the card networks, handling authorization, settlement, fraud screening, and PCI-DSS compliance so your team doesn't have to build those layers independently. For healthcare organizations running billing across multiple service lines, such as transport co-pays, DME invoicing, and home health recurring charges, that abstraction layer removes significant risk and development overhead. You get a proven, compliant payment pipeline without rebuilding financial infrastructure each time you add a billing workflow.

The core products in the Authorize.net ecosystem

Authorize.Net is not a single monolithic product. It bundles several tools together, and knowing which one applies to your use case will save you considerable time when working through the authorize.net payment gateway documentation. Each component targets a distinct integration scenario:

Product	What it does
Accept.js	A hosted JavaScript library that tokenizes card data in the browser, keeping raw card numbers off your server
Accept Hosted	A fully hosted payment form that Authorize.Net serves directly, reducing your PCI scope to the minimum level
Customer Information Manager (CIM)	Stores customer payment profiles on Authorize.Net's servers for repeat or recurring billing
Transaction Reporting API	Retrieves settled and unsettled transaction records for reconciliation and audit purposes
Webhooks	Pushes real-time event notifications to your endpoint when a transaction changes state

Your integration path depends entirely on which of these products your application requires. A one-time charge for a durable medical equipment order looks very different from a recurring home health billing cycle that depends on stored payment profiles and automated retries through CIM.

Choosing the wrong product early is the most common reason development teams restart integrations. Match your billing workflow to the specific Authorize.Net component before writing a single line of code.

How the documentation sections are organized

Authorize.Net organizes its developer resources across several distinct areas, and navigating them without a clear map wastes hours. The API reference section documents every endpoint, request parameter, error code, and response field. The integration guides cover specific scenarios like card-present transactions, subscription creation, and eCheck processing. The sandbox environment uses a completely separate URL and its own credentials, which catches many developers off guard during their first setup.

The documentation also separates REST-style JSON calls from the older XML-based API. Both remain supported, but the JSON path is the recommended approach for any new integration you build. Code samples appear in PHP, Java, Ruby, Python, and .NET, and each sample connects directly to the sandbox endpoint so you can run it immediately without touching production credentials. Keep the API reference and the integration guides open side by side because a real build requires both constantly.

What the request and response model looks like

Every call to the Authorize.Net API follows the same structural pattern. You send a JSON or XML payload to a single endpoint URL, either the sandbox or the production host, and you receive a structured response containing a result code, a response code, and any relevant transaction IDs or error messages. There is no REST resource model distributing actions across multiple URL paths. Instead, the transaction type is declared inside the request body itself, which means your HTTP client setup stays minimal regardless of what action you are performing.

This design keeps your integration predictable. One base URL, one authentication block, and one content-type header handle every operation from an initial charge to a void or refund. Once you understand the envelope structure, every transaction type follows the same pattern.

Prerequisites before you start the integration

Before you touch any authorize.net payment gateway documentation or write a single line of code, gather everything this section lists. Missing one item mid-integration forces you to pause, track down credentials or server details, and restart context that took time to build. Thirty minutes of preparation now eliminates hours of debugging later.

Get an Authorize.Net merchant account

Authorize.Net requires a live merchant account tied to a payment processor before you can move transactions into production. If your organization doesn't have one yet, you apply directly through Authorize.Net's website and connect an acquiring bank during signup. The process typically takes one to three business days for approval.

You also get sandbox access automatically when you create a developer account, which is completely free and separate from the live merchant account. Use the developer account for all testing described in this guide. Never run test transactions against production credentials, even if the amounts are small.

Create your free developer account at sandbox.authorize.net before anything else. Every step in this guide depends on having sandbox credentials ready.

Confirm your technical stack and PCI scope

Your server environment and PCI compliance level directly determine which integration path is available to you. Answer these questions before choosing a method:

• Does your server currently store, process, or transmit raw card numbers?
• Do you have an SSL/TLS certificate installed on your domain?
• Does your application run server-side code (PHP, Python, Node.js, .NET, Java, Ruby), or is it a front-end-only build?
• Will you handle one-time charges only, or do you need stored profiles for recurring billing?

If your server touches raw card data, your PCI scope expands significantly. Choosing Accept Hosted or Accept.js moves card tokenization off your server entirely and reduces that scope to the minimum possible level.

Gather the tools you'll need before writing code

Having the right tools configured upfront keeps your workflow clean. You need a REST client like Postman or Insomnia to inspect raw API requests and responses before wiring them into application code. You also need access to your server logs and a reliable way to receive webhook POST requests during testing, such as a tunneling tool that exposes your local environment to the internet.

Confirm you have the following ready before Step 1:

Item	Why you need it
Developer sandbox account	Provides test API credentials
REST client (Postman or similar)	Tests raw API calls independently
SSL certificate on your domain	Required for live and most sandbox flows
Webhook receiver URL	Captures real-time transaction events
Server-side runtime environment	Executes signed API requests securely

Step 1. Create a sandbox and generate API credentials

The Authorize.Net sandbox is a fully isolated testing environment that mirrors production behavior without processing real money. Every API endpoint, error code, and response structure behaves identically in both environments, which means any code you validate in the sandbox transfers to production without rewrites. Your first task is creating that sandbox account and pulling the two credentials that authenticate every API call you will make throughout this integration. Skipping this step and testing against production credentials is a serious risk your team cannot afford to take.

Never include your Transaction Key in client-side JavaScript or commit it to a version control repository. Treat it with the same care as a database password.

Navigate to the sandbox dashboard

Go to sandbox.authorize.net and click "Sign Up" to create a free developer account. Authorize.Net asks for your name and email address only. No payment method, no business documents, and no merchant account approval is required at this stage. Once your account is confirmed, log in and you will land on the sandbox merchant interface, which mirrors the production control panel layout exactly. Everything you see here maps directly to what the authorize.net payment gateway documentation describes for live accounts, so navigating the sandbox also teaches you the production environment before you touch real billing infrastructure.

After logging in, follow these steps to reach your API credentials:

1. Click the Account tab in the top navigation bar.
2. Select Settings from the dropdown menu.
3. Under the Security Settings section, click API Credentials and Keys.

Locate and record your API Login ID and Transaction Key

Your API Login ID appears immediately on the credentials page. Copy it and store it in a secure location such as an environment variable file or a secrets manager your organization already uses. To generate your Transaction Key, select "New Transaction Key," confirm your secret answer, and submit the form. Authorize.Net displays the key a single time only. If you close the page before copying it, you must generate a new one, which also invalidates the previous key immediately.

Both values authenticate every request you send. The structure below shows exactly where they appear inside a JSON request body:

{
  "createTransactionRequest": {
    "merchantAuthentication": {
      "name": "YOUR_API_LOGIN_ID",
      "transactionKey": "YOUR_TRANSACTION_KEY"
    }
  }
}

Store these credentials in environment variables rather than hardcoding them into source files. A pattern like process.env.AUTHNET_LOGIN_ID in Node.js or os.environ.get("AUTHNET_LOGIN_ID") in Python keeps both values out of your codebase and eliminates the risk of accidental exposure during code reviews or repository pushes.

Step 2. Choose an integration path that matches your app

Authorize.Net offers four distinct integration methods, and picking the wrong one early creates rework that costs real development time. Before referencing the authorize.net payment gateway documentation for specific endpoints, match your application's architecture, PCI obligations, and billing requirements to one of the paths below. Each method trades control for simplicity at a different point on the spectrum, so your existing stack largely dictates the decision before you open a code editor.

Accept Hosted: the lowest-friction option

Accept Hosted is the right choice when reducing your PCI scope is the primary concern. Authorize.Net serves the entire payment form from its own servers, meaning your application never handles card data directly. Your server requests a form token, passes it to the front end, and the gateway takes over from there. Once the transaction completes, Authorize.Net redirects the customer back to your specified URL with a result parameter your server verifies. This path requires the least code and the fewest security controls on your infrastructure.

Accept.js: tokenize in the browser

This library gives you full control over your payment form's visual design while still keeping raw card numbers off your server. You load the Authorize.Net JavaScript library into your checkout page, capture the card fields, and exchange them for a nonce token before any data reaches your backend. Your server then sends that token to the API instead of the actual card number. This approach suits teams that need a branded checkout experience but want to avoid the broader PCI requirements that come with server-side card handling.

Use Accept.js when design requirements prevent you from using Accept Hosted but you still want to limit your PCI surface area.

Direct API calls: full server-side control

The direct API path sends card data or stored payment profile IDs from your server directly to the Authorize.Net endpoint. This approach gives you complete control over the request and response cycle but increases your PCI scope because your server participates in card data handling. It is the correct choice for back-office billing systems where no browser session is involved, such as automated recurring charges triggered by a scheduling engine or a DME invoicing workflow.

Match each path to your billing scenario

Use this table to confirm your decision before moving to Step 3:

Billing scenario	Recommended path
One-time patient co-pay via web form	Accept Hosted
Branded checkout with custom form design	Accept.js
Automated recurring home health billing	Direct API with CIM profiles
Back-office DME invoicing	Direct API

Step 3. Validate authentication and run a first test charge

Before you build any transaction logic, confirm that your API credentials work correctly by sending a simple authentication validation request. This single call tells you whether your API Login ID and Transaction Key are configured properly without creating any transaction records. Skipping this step means you won't know if a credential problem or a code problem is causing failures when you get to actual charges, which wastes significant debugging time.

Send a test authentication request

The authenticateTestRequest call is the fastest way to verify your setup against the Authorize.Net sandbox endpoint. Send the following JSON payload to https://apitest.authorize.net/xml/v1/request.api using your REST client:

{
  "authenticateTestRequest": {
    "merchantAuthentication": {
      "name": "YOUR_API_LOGIN_ID",
      "transactionKey": "YOUR_TRANSACTION_KEY"
    }
  }
}

Set your Content-Type header to application/json and use a POST request. A successful response returns a messages object with a resultCode of Ok and a message code of I00001. If you see an error instead, double-check that you copied both credentials without trailing spaces, and confirm you are pointing at the sandbox URL rather than the production endpoint.

The sandbox URL (apitest.authorize.net) and the production URL (api2.authorize.net) use completely separate credential sets. A credential mismatch between environments is the most common authentication failure developers encounter.

Interpret the response codes

Every response from the authorize.net payment gateway documentation reference follows a consistent structure that you will read throughout your integration. The resultCode field tells you whether the request itself succeeded at the API level, while the responseCode inside a transaction response tells you what happened to the charge. Understanding both fields independently prevents misreading a failed transaction as an API error.

Field	Value	Meaning
resultCode	Ok	The API accepted and processed the request
resultCode	Error	The API rejected the request before processing
responseCode	1	Transaction approved
responseCode	2	Transaction declined
responseCode	3	Error in request data

Run your first test charge

Once authentication passes, send a minimal charge request using Authorize.Net's published test card number 4111111111111111 with any future expiration date and any three-digit CVV. This card always returns an approval in the sandbox environment, giving you a clean baseline before you introduce real card data or stored profiles.

{
  "createTransactionRequest": {
    "merchantAuthentication": {
      "name": "YOUR_API_LOGIN_ID",
      "transactionKey": "YOUR_TRANSACTION_KEY"
    },
    "transactionRequest": {
      "transactionType": "authCaptureTransaction",
      "amount": "1.00",
      "payment": {
        "creditCard": {
          "cardNumber": "4111111111111111",
          "expirationDate": "2027-12",
          "cardCode": "123"
        }
      }
    }
  }
}

Copy the transId value from the response and log it. You will need transaction IDs later when testing voids and refunds in Step 4.

Step 4. Implement the core transaction flows

With your test charge confirmed, you can now build the transaction types your billing workflows actually require. The authorize.net payment gateway documentation organizes these into a small set of core operations that cover the vast majority of healthcare billing scenarios: authorize-and-capture, void, refund, and stored profile charges. Each one uses the same request envelope you saw in Step 3, with only the transactionType field and a few parameters changing between them.

Authorize and capture in a single request

The authCaptureTransaction type is the most common call in any integration because it approves and settles the charge in one step. Use this for one-time co-pays, equipment delivery charges, or any billing event where you want funds to move immediately. The request structure below extends the test charge from Step 3 with billing address and order information, which improves AVS fraud screening and produces cleaner settlement records:

{
  "createTransactionRequest": {
    "merchantAuthentication": {
      "name": "YOUR_API_LOGIN_ID",
      "transactionKey": "YOUR_TRANSACTION_KEY"
    },
    "transactionRequest": {
      "transactionType": "authCaptureTransaction",
      "amount": "75.00",
      "payment": {
        "creditCard": {
          "cardNumber": "4111111111111111",
          "expirationDate": "2027-12",
          "cardCode": "123"
        }
      },
      "billTo": {
        "firstName": "Jane",
        "lastName": "Smith",
        "zip": "90210"
      }
    }
  }
}

Void and refund settled transactions

Your billing team will inevitably need to reverse a charge. Voids cancel a transaction before it settles, while refunds reverse a transaction that already settled. Use voidTransaction with the original transId for same-day cancellations. For settled charges, send refundTransaction with the transId, the last four digits of the card, and the refund amount:

{
  "createTransactionRequest": {
    "merchantAuthentication": {
      "name": "YOUR_API_LOGIN_ID",
      "transactionKey": "YOUR_TRANSACTION_KEY"
    },
    "transactionRequest": {
      "transactionType": "refundTransaction",
      "amount": "75.00",
      "payment": {
        "creditCard": {
          "cardNumber": "1111",
          "expirationDate": "XXXX"
        }
      },
      "refTransId": "ORIGINAL_TRANSACTION_ID"
    }
  }
}

Partial refunds are supported: set amount to less than the original charge and Authorize.Net processes only that portion.

Charge stored profiles for recurring billing

When your billing cycle requires repeated charges against the same patient or account, create a customer payment profile using the createCustomerProfileRequest endpoint first. Subsequent charges reference the stored customerProfileId and customerPaymentProfileId instead of raw card data, which keeps card numbers off your server entirely and simplifies PCI compliance for automated workflows like home health recurring billing.

Step 5. Go live with the right settings and monitoring

Moving from sandbox to production is a two-part process: swap your credentials and endpoint, then configure the monitoring and fraud controls that protect your billing pipeline from day one. Skipping either part exposes your organization to financial and operational risk that becomes expensive to unwind after the fact. The authorize.net payment gateway documentation covers both areas in separate sections, so treat this step as a checklist rather than a single code change.

Switch your credentials and endpoint to production

Your production API Login ID and Transaction Key live in the live merchant interface at login.authorize.net, not the sandbox dashboard. Log in, navigate to Account, then Settings, then API Credentials and Keys, and generate a new Transaction Key using the same process you used in Step 1. Store both values in your production environment variables and verify that no sandbox credentials remain in your deployment configuration before you release.

Update your base URL from the sandbox endpoint to the live endpoint in every location it appears in your codebase:

Environment	Endpoint URL
Sandbox	https://apitest.authorize.net/xml/v1/request.api
Production	https://api2.authorize.net/xml/v1/request.api

A single hardcoded sandbox URL left in a production config file will silently fail every transaction without throwing a clear error. Search your entire codebase for apitest before deploying.

Configure fraud filters before processing real charges

Authorize.Net provides a fraud filter suite called Advanced Fraud Detection Suite (AFDS) that you activate through the merchant interface before your first live transaction. At minimum, enable the velocity filter to cap how many transactions a single card can attempt in a short window, and enable the IP address blocking filter to reject requests from flagged sources. Both filters activate under Account, Settings, Security Settings, Advanced Fraud Detection Suite in the live dashboard.

Set your velocity filter threshold conservatively at first, then loosen it based on actual transaction patterns over your first 30 days. Healthcare billing tends to cluster around specific appointment windows, so your legitimate traffic has predictable timing that makes anomaly detection more accurate than it would be in a general retail environment.

Review settlement timing and set up webhook alerts

Production transactions settle on a daily batch schedule that Authorize.Net processes at a time you configure in your merchant settings. Verify that your batch settlement time aligns with your organization's reconciliation workflow so your finance team sees cleared funds at a predictable point each day.

Configure webhook event subscriptions through the merchant interface or the API to notify your system when transactions change state. Subscribe at minimum to net.authorize.payment.authcapture.created, net.authorize.payment.refund.created, and net.authorize.payment.void.created to maintain a real-time audit trail without polling the transaction reporting endpoint.

Wrap-up and next steps

You now have a complete path from reading the authorize.net payment gateway documentation to running live transactions: sandbox credentials, authentication validation, core transaction types, and production cutover with fraud controls. Each step builds directly on the last, so your integration has a solid foundation before real billing begins.

Your next priority is adding webhook handling and error retry logic to make your payment pipeline resilient under real-world conditions. From there, consider how your payment layer connects to your broader patient logistics workflows. Healthcare billing rarely lives in isolation; it ties to scheduling, service coordination, and vendor management across multiple service lines.

If your organization needs a platform that connects payment collection to the full logistics cycle, from transport scheduling to DME invoicing and home health coordination, explore VectorCare's patient logistics platform to see how a unified system removes the gaps between billing and operations.