Skip to content
Current/ Help Center

ConnectBooster / BNG Payments: see who's on autopay (read-only)

6 min read · Updated Jul 17, 2026

ConnectBooster is the payments and billing portal a lot of MSPs use to collect recurring payments from their customers. Under the hood it runs on the BNG payment gateway (part of the NMI family of gateways). This connector reads that gateway — read-only, once a day — and hangs a short payment picture off each matching Current company: whether they have a stored payment method, whether autopay is actually being charged, and when a stored card is about to expire. It is strictly read-only. Current can see the gateway, but it can never charge a card, issue a refund, or change a payment method — it can never move money.

Note
Why Current connects to BNG, not ConnectBooster
ConnectBooster itself has no public API to connect to — there's no ConnectBooster endpoint Current could read. What it does have is the BNG gateway sitting underneath it, and BNG does expose a read-only Query API. So Current connects straight to BNG with a read-only key. Same payment data, just reached through the gateway that ConnectBooster is built on.

What Current syncs, and how often

Once a day, Current makes a small set of read-only calls to BNG and refreshes a short payment summary for each customer with a stored method. It pulls the list of stored payment methods and roughly the last 90 days of charge activity, rolls that up per customer, and matches each one to a Current company. There is no per-transaction ledger and no raw copy of the gateway's payment record — just the rolled-up picture below. Sync now on the tile runs the same pull on demand.

What Current storesWhat it's for
Stored-method summaryThe card type and the last four digits only (e.g. "Visa •• 4242"), plus the expiry month. That is the whole method record Current keeps.
Charge cadence (last 90 days)The date and amount of the most recent charge, how many charges ran, the total charged, and which of the last three months saw activity — enough to tell a live autopay from a card that's just sitting there.
Autopay stateRunning or dormant, worked out from that cadence (see below). Amounts are stored and shown to your team, because knowing what a customer is actually being charged is the point.
Heads up
Current never stores a full card number
This is the important one: Current only ever keeps the last four digits of a card and its expiry month — never the full card number, never the security code, never a raw copy of the gateway's payment record. Full card numbers are masked before they ever reach Current, and nothing in Current — no company card, no to-do, no alert, no email — ever prints more than the last four. There is nothing here a thief could use to charge a card.

Running, dormant, or not enrolled

Every customer lands in one of three plain-English states. Current works these out from what it can see in the gateway — it never asks you to set them by hand.

StateWhat it means
Autopay runningThere's a stored payment method and Current can see it actually being charged on a regular cadence — a recurring charge, or charges in at least two of the last three months. This is a healthy autopay customer.
Autopay dormantA payment method is on file, but Current sees no recent charge cadence against it — the card is sitting there and nothing's running. Worth a look: maybe autopay was switched off, the card stopped working, or they've started paying another way.
Not enrolledNo stored payment method is matched to this company at all. Either they genuinely pay another way, or their gateway record simply hasn't been matched to the company yet (see mapping, below).

The Payments card on a company record

Open any company in the CRM and, once its gateway record is matched, a Payments card appears in the right rail — just after Money & renewals. It shows the autopay state at a glance, the stored method ("Visa •• 4242 · exp 08/26", with the expiry turning red when it's within about 45 days), the most recent charge with its date and amount, and the last-90-days total. If a company has more than one stored method, the card leads with the live one and notes the rest.

SCREENSHOT — coming soon
The Payments card on a company record: the autopay-state pill, the masked stored method with its expiry, and the recent-charge and 90-day figures.
Note
Who can see the Payments card
Everyone on your team with CRM access sees the Payments card, amounts included — account executives, sales managers, and admins alike. This is a deliberate decision: your team needs to know what a customer is being charged. Partner-portal viewers (your customers) never see it — the whole payments feed is blocked from them at the database layer, not just hidden in the interface. And nobody, on any screen, ever sees more than the last four digits of a card.

Expiring-card to-dos and bells

A stored card that expires while autopay is running means a failed charge and an awkward email to the customer. Current heads that off: when a stored card is within about 45 days of expiring, it opens a to-do for that company's account manager (or, if there's no account manager, a member of sales leadership) and rings the notification bell for the account manager plus sales leadership. The to-do names the company and reminds whoever owns it to get the card updated in ConnectBooster before autopay fails. It never shows the card number — just the last four and the month. Companies your PSA has marked inactive are skipped entirely — no to-do, no bell — and if a company goes inactive after a card to-do was already created, that to-do is cleared automatically (it drops off the owner's list and their Microsoft To Do).

Note
It rides Microsoft To Do
The expiring-card reminder is a normal Current to-do, so if the account manager has connected Microsoft To Do it flows straight into their To Do list alongside their other tasks. You get exactly one to-do per expiring card — Current won't pile up duplicates run after run. This nudge always fires for the account manager and sales leadership; it doesn't depend on the tenant-wide integration-alert bell setting.

Matching your gateway customers to your companies

The gateway identifies each customer by a stored vault record. Current matches each vault record to one of your Current companies automatically by normalized name — lowercased, with punctuation and Inc/LLC/Ltd-style suffixes stripped — and links it only when exactly one company matches cleanly. Anything it can't match confidently is left for you to map by hand.

Note
Records named for a person are expected to need hand-mapping
Plenty of gateway vault records are stored under a person's name — "Jane Smith" rather than "Smith Dental, PC" — because that's who signed up to pay. Current can't safely guess which company "Jane Smith" belongs to, so those records land unmatched on purpose. That is not a bug or a failed sync. Open the ConnectBooster tile's mapping panel, and for each unmatched record press Map and pick the right company. A mapping you set by hand is never overwritten by a later sync.
  • Unmatched vault records appear on the ConnectBooster tile's mapping panel — press Map to pick the right Current company.
  • A company-named record usually matches automatically; a person-named record usually needs one hand-map. Both are normal.
  • Unmapped records still sync — their state and cadence are stored — but the Payments card only appears on a company once its record is mapped to it.

Target autopay reminders with a campaign audience

The autopay picture is also a campaign audience, so you can send an enrollment nudge to exactly the right customers. In the campaign audience builder, the "Autopay (ConnectBooster)" filter lets you target customers who are Not enrolled (no stored method on file) or Dormant (a method on file but nothing charging) — or either gap together. Combine it with your other filters as usual; the live recipient count updates as you go. If the ConnectBooster integration isn't connected, the filter simply resolves to zero recipients rather than emailing everyone by mistake.

Create a read-only Security Key in the BNG gateway portal

The key Current needs is created inside the BNG gateway portal (the payment-gateway login behind ConnectBooster — if you're unsure of the URL, ask your ConnectBooster or BNG contact). Make it a read-only key: Current only ever reads, so the key it holds should only be able to read.

  1. 1
    1 · Sign in to the BNG gateway portal
    Log in as an administrator to the gateway portal that sits behind your ConnectBooster account. This is the payment-gateway admin, not the customer-facing ConnectBooster billing site.
  2. 2
    2 · Open Security Keys
    Go to Options ▸ Security Options ▸ Security Keys. This is where the gateway lets you mint API keys for outside tools.
  3. 3
    3 · Create a new read-only key
    Create a new Security Key and give it read-only (query) access — not a full-access key. Name it so a future admin knows what it is, e.g. "Current (read-only)". A read-only key is all Current uses, and it keeps the blast radius to zero.
  4. 4
    4 · Copy the key
    Copy the key value now. If the portal only shows it once, keep it safe until you've pasted it into Current in the next step; if you lose it, delete it in the portal and create a fresh one.

Paste it into Current and Test

SCREENSHOT — coming soon
The ConnectBooster / BNG Payments card in Integrations: the Security Key field and the Test connection button.
  1. 1
    Open the ConnectBooster / BNG Payments card
    In Current's left sidebar open Integrations (it sits under Admin, so Tenant Admins have the link) and find the ConnectBooster / BNG Payments card.
  2. 2
    Paste the Security Key
    Paste the read-only key you copied from the gateway portal into the Security Key field.
  3. 3
    Press Test connection
    Current makes one live read against BNG's Query API to prove the key works. On success the key is stored server-side only — service-role-locked, so the browser never sees it again — and the daily read-only sync takes over from there. A bad or read-blocked key is rejected on the spot with the real reason. You can also press Sync now on the tile any time you don't want to wait for the nightly run.

The read-only guarantee — Current can never move money

Every request Current makes goes to BNG's Query API — the read-only side of the gateway — and passes through a guard that permits only that one endpoint. The endpoints that charge a card, issue a refund, or change a payment method are simply not reachable from Current's code, even by a bug. The read-only Security Key you created reinforces the same limit from the gateway's side. So the worst case here is a stale read, never a wrong charge: Current can show you the payment picture, and it can never touch the money.

On the tile itself you'll see the last sync time, how many stored customers Current found, and how many are still waiting to be mapped — the same at-a-glance health as every other connector.

Heads up
Don't hammer Test with a key that keeps failing
If Test connection fails, read the message and fix the key before trying again — don't sit there re-pressing Test with a key you're not sure about. Payment gateways watch for repeated failed authentication and can throttle or temporarily lock an account that trips it too many times in a row. One careful retry after correcting the key is fine; a dozen rapid retries with a bad key is exactly the pattern that gets a gateway account flagged. When in doubt, delete the key in the portal, create a fresh read-only one, and try that.

When something looks wrong

What you seeWhat it means
Test or sync fails immediatelyUsually the Security Key was mistyped, or it was created as a full-access key the gateway won't let query, or it was deleted in the portal. The message names the real reason — fix the key in the gateway and reconnect.
Lots of customers show as unmappedExpected when many vault records are stored under a person's name. Open the tile's mapping panel and map them by hand — a company-named record matches automatically, a person-named one usually needs one map.
A customer shows Not enrolled but you know they're on autopayTheir gateway record probably isn't mapped to the company yet. Check the mapping panel's unmatched list; once mapped, the Payments card fills in on the next sync.
A customer shows Dormant but pays every monthCurrent looks back about 90 days and needs charges in at least two of the last three months (or a recurring marker) to call it running. A brand-new enrollee, or a customer billed less often than monthly, can read as dormant until more charges land.
Note
Who can do this, and who sees it
Connecting, testing, mapping, and disconnecting the ConnectBooster / BNG Payments tile are Tenant Admin actions. The Payments card and the autopay states are visible to everyone on your team with CRM access, amounts included, and to no one else — partner-portal viewers can never reach them. The read-only Security Key is stored server-side only and service-role-locked: it is never returned to the browser and never logged.
Was this helpful?