HubSpot + Authorize.net integration

Authorize.net is a payment gateway, so it sits behind something else: a website checkout, a donation form, a membership renewal, a phone order keyed into its Virtual Terminal. The charge succeeds or fails inside the gateway, the customer profile and the recurring schedule live there too, and only people with a Merchant Interface login can look at any of it. Whoever owns the customer relationship is working in HubSpot, where none of it shows.

Renewals are where that hurts first. Automated Recurring Billing suspends a subscription when its first payment is declined, and terminates it if nobody fixes the problem before the next run date, after which it cannot be reactivated. Authorize.net can email the merchant when that happens, and an email to an accounts inbox is not a task on anybody’s list. An account manager who could have called about an expired card hears about it after the customer has gone. The same blindness runs the other way, with sellers chasing invoices that a customer paid by card days ago.

One rule shapes every design on this page: card data never goes into HubSpot. HubSpot’s own Product and Services Catalog excludes full card numbers and card security codes even from its Enterprise Sensitive Data feature, and it lists even the last four digits as Sensitive Data. Authorize.net makes the rule easy to keep, because its customer profiles hold the card on its own servers and its responses return the number masked. So the integration moves references and outcomes: profile ids, transaction ids, amounts, dates and statuses, with the card brand as the only card detail.

Five rows cover it, and every one flows into HubSpot only. Customer profiles become contacts, or companies where the payment profile is marked business, and each payment profile adds its card brand and nothing else: the masked number and the expiry stay behind, and we never ask for the expiry unmasked. Each charge, refund, void and decline becomes a HubSpot payment, each Automated Recurring Billing subscription a record with its status, amount, interval and next billing date, and each decline or suspension a task for the record’s owner.

Each row matches on its Authorize.net id, which a custom HubSpot property holds. An email address is never the key, because Authorize.net refuses a duplicate profile only when the merchant customer id, description and email all match, so two profiles can share one inbox. To tie a payment to a deal, the checkout puts the HubSpot deal id in the invoice number, which Authorize.net stores and returns in its reports. User fields look tempting, but Authorize.net echoes them back without storing them.

Payments go to HubSpot’s payments object, whose API takes payments made outside HubSpot on every tier from free up and cannot process one. Its documented statuses have no value for a void or a held charge, so Authorize.net’s own status rides in a custom property. Only subscriptions want a custom object, which needs Enterprise; below it, their status and next billing date become deal properties.

Events arrive first and a nightly pass settles the account. An endpoint recomputes the HMAC-SHA512 hash of each notification body with the Signature Key, compares it with the X-ANET-Signature header, answers 200 and queues the event.

A notification carries ids and a few fields, so the consumer reads the full record. Authorize.net says its API is not based on REST: each call posts a JSON or XML body naming the operation to a single endpoint, and JSON is translated into XML, so elements go in the reference’s order. The consumer keeps allowlisted fields only, never free text or the masked card number, upserts on the Authorize.net id, then links each record to its contact and deal.

Each night a sweep reads the previous day’s settled batches and their transactions, up to 1,000 a page, and repairs what the stream missed. Customer profiles and subscriptions have no changed-since filter, so it compares them by id and status. A watermark per settlement date makes a replay rewrite the same records. Authorize.net publishes no request rate limit, so the sweep paces itself and backs off on errors.

The service never handles a full card number: Accept Hosted or Accept.js sends it from the browser straight to Authorize.net, at SAQ A, or SAQ A-EP for Accept.js on your own form.

The choice here turns on what the business wants to see. Receipts copied into HubSpot are a small job. The state of each customer’s billing, with subscriptions, declines and a reconciliation that proves nothing went missing, needs a service that remembers what it has already written.

A custom API integration does both. An iPaaS is a fair smaller step where one already runs: Celigo documents a prebuilt Authorize.net connector that signs in with the API Login ID and Transaction Key, while Zapier lists Authorize.net as not yet supported. HubSpot’s own payments tool is the route people ask about most, and it runs on Stripe infrastructure, so choosing it means changing processor rather than connecting the one you have, with the stored profiles and recurring schedules that live in it.

1. Scope. We trace where cards are captured today, which other websites and carts share the account’s keys, and which failures each owner wants to hear about.
2. Architect. We fix the field allowlist, the Authorize.net ids as keys, the invoice number convention that carries the deal id, and whether subscriptions get a custom object or deal properties.
3. Build. Signature-checked ingest, the queue, the consumer and the nightly batch sweep, written against Authorize.net’s sandbox and a HubSpot test portal; an allowlist of portal ids refuses anything unlisted.
4. Validate. The sandbox runs in Live Mode, because test mode stores nothing and returns a transaction id of zero. We push approvals, declines and held charges through it, compare counts per settled batch, and scan every written property for card-shaped values.
5. Operate. We watch webhook status, signature failures and what the sweep repairs, and rotate keys by a runbook agreed with the account’s owner.