Authorize.net

Authorize.net is a payment gateway rather than a payment facilitator, and that distinction shapes the whole integration. On the gateway side sit the API login identifier and transaction key, the transaction types (authorize, capture, authorize-and-capture, void, refund), the customer profile store for saved payment methods, and the gateway's own fraud filters. Behind the gateway sits a separate merchant account with an acquiring bank or processor, which is where the money actually settles. On the AppBO side sit the contact, the order, the pipeline and the workflows.

You choose it when the merchant account already exists. Established businesses frequently have a negotiated processing arrangement, a long relationship with an acquirer, or an industry classification that a payment facilitator will not accept, and in all those cases the gateway is the component that gets swapped and the underlying processing stays put. It is also common in markets and verticals where the incumbent gateway has been in place for years and the cost of migrating is not merely technical.

What you give up compared with a modern facilitator is breadth and polish: fewer alternative payment methods, an older API surface, a settlement model based on a daily batch rather than continuous capture, and reporting that lives in the gateway's own interface. What you get is continuity with an existing banking relationship. The integration work is to make the platform's automation accurate despite the batch model: specifically, to stop treating an authorization as money received.

1. Confirm the full stack is in place before configuring anything: an active Authorize.net gateway account, an active merchant account behind it, and the two correctly linked. A gateway without a working merchant account will authorize and never settle.
2. Locate the credentials in the gateway's interface. The API login identifier and a transaction key you generate there. Treat the transaction key as a password: generate it, store it in the platform's payment settings, and do not keep copies elsewhere.
3. Generate a signature or hash key if you intend to validate gateway notifications, and store it separately. Verification is only possible if you set this up before you need it.
4. Use the gateway's sandbox environment for all initial work. It has its own credentials and its own endpoint, and it is the only safe place to exercise declines and error conditions.
5. In the AppBO sub-account, open the payments settings, choose Authorize.net, and enter the credentials for the environment you are working in. Confirm the platform reports a successful connection rather than assuming silence means success.
6. Decide the transaction type. Authorize-and-capture is the simpler model and suits immediate fulfillment. Authorize-then-capture suits businesses that ship later, but means your automation must distinguish an approved authorization from a captured payment.
7. Understand and configure the daily batch. Authorize.net settles in a batch at a cut-off time you set; a transaction approved after the cut-off settles the next day. Pick a cut-off that matches your operational day and write it down where your finance team can see it.
8. Review the gateway's fraud filters before going live. Overly aggressive filters hold legitimate transactions for review, and a held transaction is neither approved nor declined: your workflows need a path for it.
9. Decide whether to store payment methods in the gateway's customer profile store for repeat or recurring billing, and if so, store the profile identifier on an AppBO custom field so later charges can reference it.
10. Map the response codes you care about. The gateway returns a response code plus a more specific reason code, and the difference between a soft decline worth retrying and a hard decline that never will be matters for any dunning logic. Take these from the gateway's current reference rather than inferring them.
11. Build the automation on the approved-and-captured signal, and build separate paths for declined, held-for-review and voided. Treating every non-approval identically is how customers get chased for payments that were never actually attempted.
12. Add custom fields for the gateway transaction identifier and, where used, the customer profile identifier. Without the transaction identifier a refund or void cannot be traced back.
13. Test thoroughly in sandbox with the gateway's test card numbers: an approval, a decline, an address-verification failure, and a card-code failure. Confirm each produces the record and the workflow you intended.
14. Move to production credentials and run one small real transaction end to end. Confirm the approval, confirm the platform's record, then watch it settle in the next batch and confirm the funds reach the merchant account. Then void or refund it and confirm the reversal path.
15. Establish reconciliation against the gateway's batch reports, and monitor for the quiet failures: transactions approved but never settled, transactions stuck in held-for-review, and a rising decline rate that usually means something changed at the processor rather than at your end.

Platform to gateway

• Transaction requests: amount, currency, transaction type, and the order reference.
• Payment data captured at checkout, submitted to the gateway for authorization.
• Billing name and address, and the card security code, where address and card-code verification are enabled.
• Customer profile creation and subsequent charges against a stored profile, where that is in use.
• Void and refund requests, referencing a prior transaction identifier.

Gateway to the platform

• The authorization outcome: approved, declined, held for review, or error.
• The response code and the more specific reason code, plus the authorization code on approval.
• The transaction identifier, which is the key for every later void, refund or inquiry.
• Address-verification and card-code verification results.
• The customer profile identifier when a payment method is stored.
• Settlement outcome, which follows the daily batch rather than the authorization.

What does not move

• Full card numbers into platform storage. The card is submitted for authorization and the stored reference is a profile identifier, not a card.
• Merchant account and funding detail. What the acquirer deposits, and when, lives with the acquirer and the bank.
• The gateway's fraud filter configuration and its held-transaction queue, both of which are managed in the gateway's own interface.
• Transactions from before the connection was configured.
• Alternative payment methods and wallets that the gateway does not support. If you need them, you need a second processor alongside.

Scenario: an established supplier with its own merchant account sells a service on an AppBO order form, authorizing at checkout and capturing on dispatch.

1. The connection is configured with production credentials, the transaction type set to authorize-only, and the batch cut-off set to early evening to match the warehouse day.
2. A customer completes the order form. The platform submits an authorization request to the gateway with the amount, the billing address and the card security code.
3. The gateway returns approved, with an authorization code, a transaction identifier, and a passing address-verification result.
4. A workflow fires on the approval: it writes the transaction identifier to a custom field, tags the contact order-authorized, moves the opportunity to Awaiting dispatch, and sends an order confirmation that is careful to say the card has been authorized rather than charged.
5. Crucially, it does not start the fulfillment-complete sequence, because an authorization is not money. That distinction is the whole reason the two paths exist.
6. The warehouse dispatches the next morning. A capture is submitted against the stored transaction identifier, and the gateway confirms it.
7. A second workflow runs on capture: it swaps the tag to order-paid, moves the opportunity to Won, sends the dispatch notification with the receipt, and starts the post-purchase sequence.
8. That evening the batch settles. The following day the funds appear in the merchant account, and finance reconciles the batch report against the platform's records by transaction identifier.
9. A second customer's order is approved but flagged by a fraud filter and held for review. The platform records a held outcome; a workflow tags the contact payment-review, suppresses the confirmation email, and raises a task for finance to make a decision in the gateway interface.
10. Finance approves it in the gateway. The transaction proceeds, the capture path runs normally, and the held tag is removed.
11. A third customer's card is declined with a reason code indicating insufficient funds. A soft decline. The declined-payment workflow sends a polite retry link rather than treating the order as dead, and a different reason code indicating an invalid card routes instead to a workflow asking for a different payment method.

Rate limiting

The gateway applies its own request limits and they are documented on its side; check the current reference rather than assuming, and back off rather than hammering. The more consequential limit is operational: the daily batch. Everything approved after the cut-off settles a day later, which means cash-flow expectations and any automation that keys off settlement must account for the gap.

Retries and idempotency

Treat every payment request as potentially non-idempotent and protect it on your side: before submitting, check whether an approved transaction already exists for that order reference, and store the transaction identifier the moment you receive it. A blind retry after a timeout is how a customer gets authorized twice. Voids and refunds must reference the original transaction identifier, and the choice between them depends on whether the batch has settled, voiding an unsettled transaction is cleaner than refunding a settled one, so build both paths.

Field mapping traps

Response codes and reason codes are two different fields and both matter; collapsing them loses the information that distinguishes a retryable decline from a permanent one. Address-verification and card-code results are separate from the approval itself, so a transaction can be approved while failing verification: decide your policy deliberately. Amount formatting and decimal precision are strict, and the gateway is less forgiving of malformed input than newer APIs. Field length limits on name, address and description fields will reject a transaction outright rather than truncating.

Authorization versus capture

This is the defining trap. An approved authorization is a hold, not a payment, and it expires. The window depends on the card network and the issuer, so check rather than assume. Fulfilling on authorization and never capturing means shipping for free; capturing after the hold expires means a failed capture on an order you have already shipped. Automate the capture step and alert on authorizations that have aged without capture.

Duplicate creation

The gateway has a duplicate-window behavior that can reject an identical transaction submitted shortly after another, which looks like a mysterious decline when a customer legitimately orders the same thing twice. Vary the order reference per transaction so genuine repeat purchases are not blocked, and do not rely on that window as your duplicate protection.

Sandbox versus live

Sandbox and production have separate credentials and separate endpoints, and the classic launch-day failure is production credentials against the sandbox endpoint, or the reverse. The first silently takes no money; the second takes real money during testing. Verify the environment explicitly, and keep sandbox credentials available afterwards for regression testing.

Auth expiry

The transaction key can be regenerated in the gateway interface, and regenerating it invalidates the old one immediately, which breaks the platform connection the moment someone does it for an unrelated reason. Record who is allowed to rotate it and make updating the platform part of that procedure. Watch for the signature key too, if you validate notifications.

What commonly breaks

• Fulfillment triggered on authorization rather than capture.
• Authorizations left uncaptured until the hold expires.
• A transaction key regenerated in the gateway and never updated in the platform.
• Held-for-review transactions with no workflow path, leaving customers in silence.
• Soft and hard declines treated identically, so recoverable sales are abandoned.
• Batch cut-off misunderstood, producing reconciliation differences that are really just timing.
• Sandbox and production credentials crossed at launch.