Working with multiple payment gateways

Develop, Build & Integrate APIs & Integrations
1

TLDR: how do I structure the portal to capture and reflect 6 different payment gateways?

I was hired at my company a few months ago and after working within their disastrous GHL setup, I have convinced them to switch to HubSpot.

The company has 6 different payment gateways (all white labelled NMI). I need to figure out how to set up a system so that transaction records are reflected in HubSpot and can be used as similar to native HubSpot Payments/Stripe transaction records as possible.

I have connected a Stripe account to unlock the Commerce Hub features but won’t ever use it.

My first thought is to have the payment gateway send a webhook to HubSpot which creates a payment record via workflow, or sync via API.

I can code, but am cautious to implement a lot of custom coded features as the other 2 super admins on the account can’t code (but are otherwise very tech savvy, especially with integrations, Zapier, etc).

Background:

  • B2C - service based company. Company gets most of their customers from webinar events.
  • Based in US, only US customers
  • Payments are captured in landing page checkouts and manual invoices.
  • 2-5 mill/month in sales
  • The company has 6 payment gateways, and in their GHL account, each gateway is connected to a separate sub account.
  • Presently, successful payments are the trigger to a lot of workflows and that is the main way of thinking at the company.
  • Company does use Quickbooks but I looked through the documentation and I’m not sure it’s right for us - but very open to using!

Any insights would be helpful!

2

You can create HubSpot payment records via API, but I would not recommend using workflows alone for this setup. Since you have 6 external NMI gateways, the best structure is to use a middleware/API layer that receives all gateway webhooks, normalizes the data, prevents duplicates, handles failures/retries, and then creates or updates payment/transaction records in HubSpot via API.

This gives you the closest experience to native HubSpot Payments while keeping NMI as the source of truth.

Then you can use HubSpot workflows based on payment status, gateway name, amount, contact, deal, invoice ID, etc. for downstream automation and reporting.

I’d also strongly recommend implementing proper logging, webhook retry handling, and transaction validation because payment systems at your scale need reliability and traceability.

If this helped, feel free to give an upvote. Also let me know if you need any support with the architecture or implementation.

3

Amazing, thank you! Do you have any suggestions for a middleware solution?

4

Yes — for this setup, I’d suggest a lightweight custom middleware rather than relying only on Zapier/Make.

At your transaction volume, the middleware should handle: Receiving webhooks from all 6 NMI gateways Normalizing payloads into one standard transaction format
Deduping by transaction ID Creating/updating HubSpot payment or transaction records
Logging failures and retrying failed requests Keeping NMI as the payment source of truth
A good stack would be Node.js or PHP with a small database for logs and transaction mapping. You could host it on AWS EC2, DigitalOcean, Render.

Zapier/Make can work for simpler automations, but for payments at $2–5M/month, I’d use custom middleware for better reliability, logging, retries, and control.

5

With six gateways, I’d avoid trying to make HubSpot behave as though there’s one payment processor. The cleaner approach is to treat HubSpot as the system that receives and normalises transaction data, while NMI remains the source of truth for the actual payment.

A webhook/API approach makes sense, but I’d put a small standardisation layer between the gateways and HubSpot. All six gateways may be NMI underneath, but each transaction should arrive in HubSpot using the same structure: gateway/account ID, transaction ID, customer/contact, amount, currency, status, payment date, payment method, invoice/order reference, and refund/void information.

That gives the team one consistent transaction model instead of maintaining six slightly different sets of workflows.

One thing I’d be careful about is using successful payment as the trigger for everything. At $2–5m/month, payments will eventually have refunds, partial refunds, declines, duplicate webhook deliveries, chargebacks, retries, etc. I’d make transaction ID + gateway ID the unique key and design the integration to be idempotent, so the same webhook arriving twice can’t create two payment records or trigger fulfilment twice.

I’d also separate the layers:

NMI/gateways → transaction truth
HubSpot → CRM, lifecycle and operational automation
QuickBooks → accounting/reconciliation

That separation makes troubleshooting much easier. If finance finds a discrepancy, there’s a clear path back to the originating gateway rather than trying to reconstruct the payment from workflow history.

For maintainability, I wouldn’t put lots of business logic into custom code either. Use code/API handling for the difficult bit, receiving, validating, deduplicating and normalising transactions, then expose clean properties/statuses in HubSpot. The other admins can build most downstream automation with normal workflows without needing to touch the integration.

Before building it, I’d actually map every workflow currently triggered by “successful payment” in GHL. That exercise will probably reveal that some are really triggered by invoice paid, some by “first payment received”, some by subscription/payment plan started, etc. Recreating those business events explicitly in HubSpot will be much safer than replacing one generic payment trigger with another.

Given the transaction volume, I’d also test the design against HubSpot API limits and webhook retry behaviour before migrating. That could influence whether events should hit HubSpot directly or pass through a lightweight middleware/queue first.

The six gateways themselves aren’t really the difficult part here. Creating one reliable payment event model that all six feed into is what will keep the HubSpot portal manageable six months from now.