HubSpot + Moneris integration

Moneris is the processor behind a large share of Canadian card payments: by its own count one in three transactions in the country, at more than 325,000 points of commerce. For a Moneris merchant selling online, the charge, the stored card and the subscription schedule all live inside Moneris. The sales and service teams working in HubSpot see none of it, so a failed renewal or a card payment that clears never reaches the person who owns the customer.

The books can already see it: Moneris announced its own QuickBooks connector in May 2026 to copy transaction data into QuickBooks, and nothing equivalent reaches the CRM. HubSpot’s own payment tools do not close the gap for a Moneris merchant either. HubSpot payments is open to businesses in Canada, the US and the UK, and it uses Stripe infrastructure; the other option HubSpot offers is connecting a Stripe account. Either one means moving processing to Stripe rather than connecting the processor the business already has.

One rule shapes every design here: card data stays with Moneris. HubSpot’s Product and Services Catalog keeps full card numbers and card security codes out of its Sensitive Data feature altogether, and admits the last four digits only as Sensitive Data, an Enterprise feature. The Moneris API returns a card’s first six to eight digits, its last four and its expiry with each payment, so the sync discards them and carries ids, amounts, dates, statuses and the card brand.

Five rows, every one flowing into HubSpot. Moneris customers become contacts. Each payment becomes a HubSpot payment, the object HubSpot’s Payments API offers for revenue collected elsewhere, which cannot charge a card itself. Its statuses have no value for a cancelled or held authorization, so Moneris’s own status, from AUTHORIZED to CANCELED, sits in a custom property beside HubSpot’s. Refunds are separate Moneris records that update the payment they reverse. Subscriptions take a custom object on Enterprise and deal properties below it, and every decline or pause raises a task.

Each row matches on its Moneris id, held in a custom HubSpot property. The order id looks like the obvious home for a HubSpot deal id, but Moneris lets no two purchases or pre-authorizations share one, so a deal paid in two instalments cannot use its id for both. The deal id goes in customData instead, which takes up to ten values of 50 characters and comes back on every payment read. Email is no key either: Create Customer requires only an idempotency key, so a Moneris customer may have no email at all.

Moneris documents three online payment interfaces, and the build reads through the newest. The classic Gateway API, keyed on a store ID and API token, now sits on Moneris’s Legacy Portal, and its calls process transactions and report on the open batch, with none that lists past ones. Moneris Checkout, the hosted form, takes JSON naming an action at one endpoint and reports each result through browser callbacks and a receipt request. The Moneris API is RESTful JSON behind OAuth 2.0 client credentials, with list and read calls for payments, refunds, customers and subscriptions.

The service holds read scopes only, so it cannot charge or refund, and it sends the merchant’s 13-character id and a pinned Api-Version header on every call. Each hour it lists payments and refunds created since its watermark, in windows of at most a day and pages of 20 behind a cursor. Every write is keyed on a Moneris id, so replaying a window rewrites the same records. Lists filter on creation alone, so each night it re-reads, by id, every payment still authorized or processing and every live subscription. Subscription callbacks prompt the same re-read, and every write passes a field allowlist.

What decides the route here is where checkout runs today. A store taking cards through the Moneris API, with Hosted Tokenization keeping the card number inside Moneris’s frame, gives a sync everything it needs. A store on Moneris Checkout, or on one of the cart plug-ins Moneris features beside it, may not: Moneris does not say whether those payments appear in the new API’s lists, so discovery tests that on the merchant’s own account. Where they do not, the receipt request the checkout’s server already makes can hand each result to the sync as well.

A custom API integration covers both cases. Moneris’s partner directory lists no iPaaS connector, so middleware on an iPaaS would call the REST API through generic HTTP steps and rebuild the token handling, the day-long windows and the card-field allowlist in each flow. HubSpot’s own payment tools process on Stripe, so choosing them means leaving Moneris.

1. Scope. We find where checkout runs today, check on the merchant’s own account whether its payments reach the API’s lists, and agree which declines and pauses each owner hears about.
2. Architect. We fix the field allowlist, the Moneris ids as keys, customData as the carrier of the deal id, and whether subscriptions get a custom object or deal properties.
3. Build. The reader, the callback receiver and the consumer are written against the sandbox at api.sb.moneris.io with read-only scopes, and a portal allowlist refuses any HubSpot portal not on it.
4. Validate. We push approvals and declines through the Penny Value Simulator, where the cents decide the response, compare each day’s counts with the API’s lists, and scan every written property for card-shaped values.
5. Operate. Production credentials need a developer portal account on the merchant’s own Moneris email, and sandbox applications do not carry over, so the merchant’s admin creates them at cutover. We rotate through the second client secret Moneris allows and alert on any Sunset header.