Release Notes
What's new in ClientLoop, newest first.
October 12, 2026
- Pay with ClientLoop on a WooCommerce store — a new WooCommerce payment gateway embeds ClientLoop checkout in the store's own checkout, so shoppers pay by card (3D Secure 2 included), ACH bank account, or whatever else the organization's checkout configuration enables, without leaving the store. It covers block checkout, classic checkout and the "Pay for order" page, and offers full and partial refunds from the order screen. An order is completed only from ClientLoop's own record of the payment, matched to that order's session, amount and currency; anything that doesn't match is held for review rather than completed. USD only for now. Each store's domain must be registered as an origin of its organization before payments work.
- See when a payment's funds become available — the Available Date on a CLP payment was always blank. It now reports the date the funds become available to the merchant. Payments captured before this update will be filled in by a separate backfill.
- Fees on the payment detail page — a Fees row now sits between Net amount and Refunded amount. Where both are reported, the net amount plus the fees is the amount charged, and refunds are netted into neither. A fee the processor has not reported yet reads "Not reported yet" rather than
$0.00, since that is not a confirmed zero. - Links read as links — links in the portal are coloured in the brand blue on both the light and dark themes: underlined in running text, and on hover in dense tables so a long list isn't a wall of underlines.
- For integrators:
createPaymentSessionandcreatePaymentPlanSessionacceptmetadata— up to 25 key-value pairs, returned unchanged onPaymentSession.metadataandPaymentPlanSession.metadata— so your own references, such as an order or customer id, can travel with the session. Each key is unique and is 1–40 characters of letters, digits,_,-and.; each value is at most 500 bytes of UTF-8 and may be empty. Metadata is set at creation only, is never shown to the customer, and is visible on the payment detail page. The change is additive. - For integrators: reading a payment session or a payment plan session now also requires access to the organization that owns it, wherever the session is reached, and creating or updating a payment plan session requires write access to that organization. Callers working within their own organization see no change.
- For integrators:
expectedSettlementDateis deprecated in favor ofexpectedFundsAvailableDateonPayment, on both payment inputs, on the Plaid transfer result types and on the payment change event. It still resolves and is still populated, so nothing breaks — but move toexpectedFundsAvailableDate, the date funds can be withdrawn from the ledger balance. - For integrators: the API reference now describes the
Paymenttype — what it covers, that its id is named in every payment webhook and is the key to reconcile against, and how refunds and their events behave.
October 11, 2026
- Correct fees and net amounts on CLP payments — a CLP payment could record an incomplete processing fee, and sometimes an overstated net amount. Where a merchant's configuration makes them liable for the processing fee, the fee charged against their own account was left out of both figures; and fee entries that arrived in the same instant as the capture could be missed altogether. Both are now counted in full, fees that arrive late are reconciled automatically rather than being lost, and the payments already recorded are corrected by a separate backfill.
- Refund from the payment detail page — the refund action has moved off the payments list and onto the payment detail page. A refund is irreversible, and the amounts, provider and status that decide one are on the detail page rather than in a table row.
- The whole payment payload for developers — the JSON button on a payment now shows the payment session and contact alongside the payment, so a payment can be reconciled against the invoice, transaction and contact references your integration set — those live on the session, not on the payment. The view names the fields it does not include.
- Link a funding account without an account — the New funding account flow is back: pick one of the organization's Plaid transfer configurations and share the link it generates, and the recipient links a checking account from a page that needs no sign-in. Links are single-use and expire after 72 hours.
- Submit an approved application to Plaid — a Submit to Plaid button now sits beside Submit to CLP on the application. It confirms first, because the pass creates a real Plaid customer, and a claim on the submission stops a rerun from overwriting a review or a decision already in flight.
- Tighter controls on Plaid configurations and raw records — reading a Plaid transfer configuration now requires a platform grant rather than merely being signed in, the client secret is withheld from read-only platform roles, and the raw record viewer is limited to platform administrators. Minting a funding-account link now records who asked for it.
- For integrators:
PlaidOnboardingStatusgainsInProgress. The change is additive.
October 10, 2026
- Payments taken on the hosted payment form are linked to their checkout session — a charge completed on the hosted form was never tied back to the session that produced it, so the payment carried no session and the session was left open with no payment. This affected every ACH payment, which can only be taken on that form, and some card payments. Both sides of the link are now written as the payment arrives, and the payments already recorded have been repaired.
- Hide ACH Direct Debit on a checkout — a checkout configuration can now hide ACH Direct Debit, as it can already hide card payments, leaving cards, Pay by Bank and FlexPay. A checkout left with nothing visible now reports itself unavailable instead of rendering an empty box. The processor reference stays in place, so refunds are unaffected.
- Your organization ID on the API credentials page — some API calls take the organization ID, so it now appears under the subtitle on every scope tab, with a copy button. Documentation has moved to the end of the Developers menu, after Webhooks.
- Copy buttons say whether they worked — every copy button in the portal now reports "Copied" only once the clipboard write has actually succeeded, and reports a failure when the write is denied or unavailable. Several gave no feedback at all, and two said "Copied" even when the write had failed. The new-API-key dialog also gains the manual-copy hint the webhook secret dialog already showed, since that key is likewise shown only once.
- For integrators:
achPaymentsHiddenon the checkout configuration, also returned on the checkout payment session. Configurations written before it read as not hidden.
October 9, 2026
- Owners in China and Mexico — an application can now list owners, people or companies, who live in China or Mexico. Each is asked for the identifier their country uses: a Resident Identity Card number for a Chinese person, a CURP for a Mexican person, a Unified Social Credit Code for a Chinese company and an RFC for a Mexican company. Every address also takes a second line for a suite, floor or building.
- Company owners in Canada — a Canadian company can own part of an application's business, with its Business Number and, optionally, its Business Incorporation Number.
- Delete a business owner from the owner form — an owner is now deleted from their own edit form rather than straight from the wizard's owner list, and a confirmation names the owner before anything is removed. A company that still has owners of its own cannot be deleted until they are, and says so. Saving or deleting an owner now also extends the apply session, so the countdown no longer warns about an expiry that has already moved.
- For integrators: street and city fields now accept accented letters, such as
Ciudad de México. Letters from other scripts, such as Chinese characters, are still refused. - For integrators: the documentation site's new Owner Identifiers by Country guide sets out what
taxInfo,identificationandregistrationNumberare each for, and which identifier every country uses. - For integrators:
Countrygainschnandmex, andTaxInfoTypegainscn_id(a Chinese person's Resident Identity Card number) andrfc(a Mexican company's RFC). The deprecatedssnandeinhold a US or Canadian id only and are refused for an owner in China or Mexico. - For integrators: owners have a new
identificationlist, for a person's identity numbers that are not tax ids. Its only type so far iscurp, required for a person in Mexico. Like a person'staxInfo, its full numbers are returned only to callers with the owner PII permission, and the apply-session types give onlymaskedNumber. - For integrators: business owners have a
registrationNumber, the company's number in its registry: a Canadian Business Incorporation Number or a Chinese Unified Social Credit Code. It is optional, and refused for any other country and on a person. - For integrators: the applicant and every owner have an
address2, a second street line, sent to CLP with the address. - For integrators: applications have a
country, and are accepted from US businesses only for now. A request that sets an applicant's country to anywhere else is refused. - For integrators: a request that moves an owner with an identifier on file to another country must send the new country's identifier, and is refused otherwise.
- For integrators: setting or clearing the deprecated
ssnoreinnow also removes any stored tax id from another country, so an owner moved to the US or Canada keeps no Chinese or Mexican id beside the new one.
October 8, 2026
- Breaking: reading a payment now requires access to the organization that owns it.
payment(id:),Org.payment,PaymentSession.paymentand the organization-scopedpaymentslisting previously ran no access check at all, so an organization-scoped API key could name any organization inpayments(input: {orgId:})or fetch any payment by its id. Those calls now returnFORBIDDEN. An agency-scoped listing requires read access to the agency, and a listing filtered byconfigurationIdrequires unconditional payment read access, because a payment belonging to one organization can sit on another's configuration. An integration reading only its own organization's payments is unaffected. - Breaking:
createPaymentandupdatePaymentnow require unconditional payment write access. Both accept anorgIdand rewrite the index keys, so any authenticated caller could previously re-home another organization's payment, and a create over an existing id replaced that payment outright — a collision is now a conflict. A caller using an organization or agency API key, or a non-administrator portal session, now receivesFORBIDDEN. - Refund a payment from the portal — the payments page gains the refund control it was missing. It is offered only for a payment whose provider can actually reverse it (CLP or NMI), so a captured Plaid payment no longer opens a dialog that can only fail, and only to someone holding the refund permission for that payment's own organization rather than for whichever organization the page is open on. Repeating the same refund returns the first outcome instead of refunding twice, from any tab or device; Start a new attempt is there for when a second, identical refund is genuinely intended. The amount is optional for CLP, which refunds everything still refundable, and required for NMI, which would otherwise request the whole original charge.
October 7, 2026
- For integrators: applications and owners now carry their tax identifiers as a list,
taxInfo, where each entry names the issuingcountry, itstype(ein,ssn,bnorsin), thenumberand amaskedNumbershowing only its last group. It is accepted on every input that tookeinorssn. A person's tax identifiers are returned only to callers with the owner PII permission, a business's to any caller, and on the apply-session typesnumberis always null and onlymaskedNumberis given.ein,ssnandmaskedSsnare deprecated in favor oftaxInfo. They keep working and stay in step with it: setting one replaces that tax id intaxInfoand null removes it, leaving any other. A request sends eithertaxInfoor the deprecated field, not both, and the published schema marks them deprecated where it shows them.
September 27, 2026
- See how each payment was made — the payments list has a new Instrument column, and the payment detail page a matching row, showing whether a payment was taken by card, ACH debit, Plaid or FlexPay. Payments made before this update show
—. - For integrators:
Payment.instrumentreports the same value through the API (Card,AchDebit,AchCredit,PlaidDebit,PlaidCredit,FlexPay).AchCreditis an ACH credit entry, not a credit card. The change is additive.
September 26, 2026
- Document upload requirements — the documentation site has a new guide listing every document CLP may request during an application, and what each must show: file formats and sizes, legibility, and the accepted documents by country.
- Business owners who live outside the US can complete an application — an application for a US business whose owner lives in another country, such as Canada, failed at the Link bank account step with "Internal server error". The owner's own country is now used, and owners outside the US are asked for their own national ID number (such as a Canadian SIN) instead of an SSN. When the payment processor rejects a detail, the application now names the field that needs correcting instead of showing a generic error.
- Fixed CLP payments that could fail to appear — payments for some merchants were not being recorded after capture. They are now recorded reliably, and a temporary processor problem is retried rather than dropping the payment.
- Tighter controls on user management — only platform administrators and agency or organization managers can create or edit users, and removing a user now also removes every role they held, so re-adding the same email address no longer restores their old access.
September 25, 2026
- Customer names on CLP payments — card and ACH payments taken through hosted checkout were showing a blank customer in the payments list. New payments now record the customer from the checkout session.
September 23, 2026
- Correct amounts on CLP payments — a CLP payment was recorded at the merchant's share after fees rather than the amount the customer paid (a $40.00 charge showed as $38.40). Payments now record the full amount, along with the net amount, the fees taken, and the amount refunded, and link to the invoice and customer they were made for.
- Better layout on iPad — fixed layout problems in the portal at tablet screen sizes, including the application and FlexPay status drawers.
September 22, 2026
- Hide card payments on a checkout — a checkout configuration can now hide card payments, so customers are offered only FlexPay and ACH even when cards are set up for the organization. When no payment method is available, checkout now says so clearly.
- Fixed an ACH receipt and webhook naming different payments — for ACH payments, the payment id in the success response did not match the one in the
payment.status.changed.v1webhook, so the payment could not be reconciled. Both now name the same payment.
September 21, 2026
- Payment links for every organization — payment sessions for organizations under some reseller agencies were created with no payment link. They now always get one, on the ClientLoop checkout domain when the agency has no checkout domain of its own. Emailing a session with no link now reports an error instead of sending an empty email.
- Payment detail page — select a payment id in the payments list to see the full payment. The list also adds Net Amount and Refunded columns, and in agency and platform views an organization's name opens that organization's payments in a new tab.
September 17, 2026
- Refund a payment through the API — a payment can now be refunded in full or in part without knowing how it was taken: the new
paymentRefundmutation reads the provider off the payment and reverses it there. Card payments taken through CLP and through NMI are covered; Plaid payments are refused for now. Repeating a call with the same idempotency key returns the first refund rather than issuing a second, and organization and agency API keys carry the permission. The documentation site has a new Refunds guide. - Clean up CRM connections — a GoHighLevel location connected to the wrong organization can now be deleted, or moved to another organization, from that organization's CRM page. A move clears the connection's payment configurations, because they belong to the organization being left; the receiving organization picks its own, and the dialog says so before you confirm.
- Fixed a receipt and a webhook naming different payments for one charge — a card checkout reported one payment id to the browser and the settlement webhook that followed named a different one. Both now name the same payment.
- For integrators: the stored-payment-method charge is now called
paymentMethodCharge.chargePaymentMethodkeeps working and is marked deprecated, so an existing operation still validates.
September 16, 2026
- Fixed storing a card or bank account in the vault — tokenizing a payment instrument failed with an internal error in every environment and never produced a token. It now succeeds.
- For integrators:
VaultToken.fingerprintis removed. It was published a day earlier and could never have returned a value, since tokenizing had never succeeded.
September 15, 2026
- Decimal ownership percentages save — typing a decimal ownership percentage in the owner drawer failed with an error that named no field. Values now round to the nearest whole number and save, the field says so, and a validation failure is reported against the input that caused it.
- Clearer validation errors when editing business details — a failed save on the edit business details form now reports the specific problem instead of a generic message.
September 10, 2026
- Secretary of State filings are badged by their own status — on the application detail view, a registration that was active and in good standing rendered as a yellow warning, and most filing statuses got no color at all. Good standing now reads as success, dissolved or not in good standing as an error, and pending as a warning, with each status spelled out readably.
- For integrators:
callbackUrlon payment sessions and payment plan sessions is deprecated in favor of webhooks configured in the portal. The fields keep working, and the published schema now carries the deprecation notice.
September 9, 2026
- The payment processor is named CLP — the documentation site and the portal now say ClientLoop Payments (CLP) throughout, including the published API reference.
- Agency users can reach their agency's API keys and webhooks — the Agency tab offered API credentials and webhooks lists that failed with an authorization error for every agency role. Agency managers can now manage both, and agency users and agents can read them.
- Wildcard allowed origins are rejected instead of silently ignored — saving
https://*as an allowed origin succeeded and then matched no request at all, which read like blanket access while granting none. Any entry whose host contains*is now refused, with a message asking for each exact origin.
August 16, 2026
- A proper page when an organization does not exist — opening an organization that is not there used to render the organization menu and page as though it were real. The portal now shows a Not Found page instead, and unmatched addresses get the same treatment.
August 15, 2026
- Fixed CRM connections missing from an organization's page — an organization's GoHighLevel connections were looked up by the agency that installed the app, so a connection installed by ClientLoop on a reseller's behalf never appeared on the organization it belonged to. Connections are now found by organization; nine live connections that had been invisible are back on their pages. Payments were unaffected throughout.
- Identity verification always reaches an end state — a verification that fails now reports completion the same way a passing one does, so a page waiting on the result no longer waits forever. The completion call is also bounded at fifteen seconds, so a request that never comes back can no longer leave someone stuck reading "a secure verification window should open automatically" for a verification they already finished.
August 14, 2026
- Invite someone to verify before they exist as a contact — an Invite to verify action on the contact list produces a verification link for a brand-new person. The contact is created from what verification captures, so there is nothing to type in beforehand and nothing left behind if they never finish.
- The verification outcome is available to integrations — a contact verification session now reports where the verification as a whole stands (Active, Expired, Canceled, Success, Failed or Pending review). The individual checks could not answer that on their own, because a failed session still carries a full set of captured identity.
- Secretary of State registrations in application review — an application's business verification now shows the state registrations found for the business.
- For integrators: the
contact-identity-completeevent is now held for one second after verification closes, so your page reacts to a settled screen rather than one still tearing down. Both event tables in the documentation say so.
August 13, 2026
- Fixed contact verification for organizations without an agency — contact identity verification ran on per-agency credentials, so an ordinary organization that owns no agency failed every session. It now runs on ClientLoop's own verification account.
August 11, 2026
- Fixed the portal failing to load — the portal did not start on any deployed site, reporting an environment error. It now loads its configuration before the application starts.
- Re-run business verification after a correction — platform administrators and managers can re-run an application's checks, and the checks are genuinely re-ordered rather than skipped, so a corrected detail such as a TIN can finally resolve instead of sitting pending indefinitely. Each run is confirmed first, since each is billed.
- One Business information card — every business attribute now appears once, beside what verification found for it, with a Differs badge where the two disagree. An application whose industry is "Other" is flagged with the categories needed to remap it, and cannot be approved until it is. Litigations join liens and bankruptcies, and an approval now records who reviewed it.
August 10, 2026
- More card brands and debit networks requested at onboarding — JCB, UnionPay, Maestro and the US debit networks (Accel, Star, Pulse and NYCE) are now requested alongside Visa, Mastercard, Amex and Discover. Re-onboarding skips a method that is already configured rather than requesting it twice.
- Merchant accounts on the ClientLoop Payments page — a new Merchant accounts tab lists each merchant with its status, settlement currency and capture delay, and split configurations are now read from that list rather than from configured countries. Viewing this page now requires an administrator, manager or user role rather than any signed-in member.
August 8, 2026
- FlexPay underwriting works from the portal — applications awaiting review now appear in the list; the "In Review" filter previously came up empty and always showed a count of zero. A combined To Review queue covering both Pending and In review is now the default view.
- Breaking: holding the FlexPay underwriter role blocks access to the dashboard outright, even alongside a role that would otherwise admit you — including Administrator. Underwriters work from the portal, and anyone affected is sent there.
August 7, 2026
- Fixed ClientLoop app installs in GoHighLevel — installing the app at agency level failed with "An error occurred during installation". Installs now complete whether they are done for a single sub-account or across an agency.
- FlexPay applications show as In review — an application moves to In review automatically when a FlexPay underwriter opens it, so it is clear which files someone has already picked up. In review is also available as a status filter.
- Watchlist results for each owner — an application's owner list gains a Watch Lists button showing the screening results found for that person.
- Create an agency from the organization that owns it — an organization that does not yet have an agency can create one from its dashboard, already tied to that organization. Creating or changing an agency now requires agency write access rather than being open to any signed-in user.
- Editing where lists used to be read-only — checkout configurations and Plaid transfer configurations can now be edited, and industry mappings can be reordered by dragging. Lists also show a progress bar while they refresh instead of looking frozen.
- Tap to Pay groundwork — the mobile app can now activate a phone as a card reader with the payment processor, the first step toward taking payments in person.
August 6, 2026
- Smoother identity verification detail — opening an owner's verification detail now shows a placeholder in the shape of the finished view instead of a spinner, so the panel no longer jumps when the data arrives.
August 4, 2026
- Business verification results in application review — an application now shows what Middesk verified about the business: legal name, office address, TIN match, formation state and date, entity type and website, each with its own verified, warning or failed result, alongside watchlist screening for the business and the people behind it.
- Submit an application to FlexPay — a Submit to FlexPay button on the application puts it into the underwriting queue. It stays disabled until identity verification, business details, owners, and products and services are all complete, and names what is still outstanding.
- Read and edit NMI configurations — the security key on an NMI configuration can now be revealed and copied, and an existing configuration can be renamed, re-keyed or deleted rather than only created. The form now accepts exactly what the server accepts.
- The full menu on a phone — the mobile bar gains a Menu button that opens the complete sidebar, so Organizations, Developers, Settings and System stay reachable on a small screen.
August 3, 2026
- Consistent role badges, one role per scope — the same role name now takes the same color everywhere on the Users page, and agency and platform roles are chosen from a dropdown like organization roles. Note that a scope holds a single role: anyone who currently holds more than one in the same scope keeps only the one shown once their record is saved.
- New Member role for organizations — "no access" in an organization is now a real Member assignment rather than the absence of one, so someone can be listed on the organization without being granted anything.
- Fixed the CRM integration code — the code shown on an organization's GoHighLevel page was generated in the browser and never matched the organization's real code, so it could not link an install. It now reads and rotates the actual code.
August 2, 2026
- Breaking: listing payments without an organization, agency, or configuration filter now requires platform access. Integrations should pass the organization or agency they are asking about; scoped queries are unchanged.
- One home for everything in the portal — the separate Platform and Agency sections are gone. Every page now lives inside the organization you're working in, including the settings for the agency that organization owns, so you no longer switch contexts to find them.
- Agencies moved onto the Organizations page — an "Agencies only" toggle in the list switches between the organizations that applied and the agencies they applied through, and both share the same search, status filter and layout.
- Consistent organization lists — the two Organizations views now use the same search wording and control layout, and canceled applications no longer appear under "All".
- The browser tab shows the organization name — with several organizations open in different tabs, you can tell them apart at a glance.
- Removed notification toggles that did nothing — the Notifications settings on an organization's profile were never connected to anything, so they have been taken out rather than left looking functional.
July 31, 2026
- Fixed a false error when charging a card in GoHighLevel — opening the card-charge window no longer reports a failed request. The payments themselves were going through, so the error could prompt a retry on an invoice that was already paid.
- Identity verification now updates the contact — when someone finishes verifying their identity, the verified details are saved to their contact record automatically, creating the contact if it doesn't exist yet. The verification session also reports the contact's id, so an integration can match the result to a contact right away.
July 29, 2026
- Bankruptcies and liens in application review — an application now shows public bankruptcy and lien records for the business alongside its other verification results.
July 28, 2026
- Identity verification for every owner on an application — verification now runs for each owner listed on an application, not just the person filling it out. Reviewers see a status for every owner, a detail view with the document and selfie results, and can filter applications by verification status.
- One application list, filtered by status — the application lists replace their tabs with a status filter, add a Canceled filter and a FlexPay column, and show an approved applicant's organization status directly. Signing in now takes you to your organization rather than an agency.
- Phone numbers in everyday format — a contact's phone number can be entered as
(415) 555-0132instead of requiring the+1international form; it's normalized for you. Numbers that can't be read at all are still rejected, and the message now appears next to the field that caused it.
July 27, 2026
- Webhooks for contact changes — new
contact.created.v1andcontact.updated.v1events fire when a contact is created or changed, and are delivered to both the organization's and its agency's endpoints. As with all contact data, the payload carries identifiers only — fetch the contact through the API. A deletion arrives as an update. These two events are delivered only to endpoints subscribed to them. - Applications and FlexPay are easier to reach — both moved up to the top level of the menu.
July 26, 2026
- FlexPay application review — underwriters get a dedicated view of each FlexPay application, with status filtering on the list and an "Update status" panel for recording decisions (a reason is required when requesting more information or declining). Sensitive owner details like SSN and date of birth are masked and visible only to authorized reviewers — enforced by the platform, not just hidden on screen.
- Open an application in the signup flow — administrators can generate a secure link that opens an application directly in the signup experience, so it can be completed without emailing the applicant a verification code. Links are time-limited and should be shared carefully — anyone holding one can edit that application until it expires.
July 25, 2026
- Business type locks once agreements are signed — an application's business entity type can no longer be changed after the agreements have been submitted, preventing inconsistencies in downstream records. The field locks automatically in the apply flow.
- Fixed a stuck loading screen after session expiry — returning to the app with an expired session no longer leaves it loading forever; you're taken straight to the sign-in page.
July 24, 2026
- Cancel an application — an open application can now be canceled from the "Update status" panel. Canceled applications are final and won't be reused by a later signup.
July 23, 2026
- Identity verification for contacts — you can now run identity verification for a contact by sending them a secure link that works in their browser with no ClientLoop account required. The contact's latest verification result — including captured identity documents and selfie video — is available on the contact, with the summary also exposed through the public API.
- First and last name on contacts — contact forms now collect first and last name as separate fields, and existing single-name contacts are split sensibly when edited.
- Organization status at a glance — the organization dashboard now shows the organization's lifecycle status as a badge, and authorized users can change it from a slide-out editor.
- Applications are read-only after a decision — business information and owners can be edited only while an application is Open or Submitted; approved and declined applications no longer offer editing controls.
- New Underwriter role — approving and declining applications is now a separate permission from general application management, granted through a new Underwriter platform role.
July 22, 2026
- Clone a declined application — a declined application can be cloned into a fresh draft that carries over the business information, owners, and completed identity verification, so the applicant doesn't start from scratch or re-verify.
- Fixed sole-proprietorship applications failing to submit — sole proprietors no longer hit an error at the agreements step of onboarding.
- Agency applications from your organization — organizations that operate an agency now have an Applications menu showing that agency's applications with their onboarding statuses.
- Modern checkout for new organizations — newly created organizations get the v2 checkout experience by default.
- Tidier organization menu — the not-yet-available Invoices entry has been removed from the menu.
July 21, 2026
- Fixed missing API credentials and origins — API credentials and origins belonging to organizations and agencies created some time ago did not appear in their lists and could be denied access; these records have been repaired and now behave normally.
- Look up a payment's session through the public API — the
paymentSessionfield onPaymentcan now be selected with an API key, linking a payment back to the session that produced it. - Edit checkout configurations — the checkout settings screen now supports editing existing configurations (including provider selection), not just creating new ones.
July 16, 2026
- Look up a payment session through the public API — the
paymentSessionquery is now available on the public API, scoped to your own organization. Agency keys can read sessions for every organization under the agency. - Webhook delivery documented — the webhook events documentation now states that events are delivered as an HTTP
POSTwith aContent-Type: application/jsonheader.
July 15, 2026
- Card payments now appear alongside bank payments — completed card captures now create payment records, so card and bank activity show up together in one place. Duplicate notifications from the card processor collapse into a single payment.
- Organization members can see their API credentials, origins, and webhooks — these were previously hidden from everyone but agency staff. Managers can create, edit, delete, and rotate them; other members get read-only access.
- User management and developer tools moved — managing users, documentation, and webhooks now live in the new ClientLoop interface, and the duplicate screens have been removed from the dashboard.
- Require a password change at next sign-in — administrators can now flag an account so the user must set a new password the next time they log in, useful for issuing temporary passwords.
- Organization name in the sidebar — the sidebar header now shows the organization's name and initials instead of a generic "Organization" label, so it's clear which organization you're viewing.
- Fixed the contacts list failing to load — an error when listing an organization's contacts has been resolved.
July 14, 2026
- Breaking: the copyable Configuration ID for an apply configuration is now the bare identifier, without the
ApplyConfiguration#prefix. If you hard-coded the prefixed form in an embed, copy the ID again from the configuration screen. - Smoother sign-in when your session expires — an authentication error no longer briefly flashes on screen before you're redirected to the login page after a session expires.
- Fixed the bank-linking popup reopening after you close it — exiting the bank-linking window without connecting an account no longer immediately reopens it; it waits for you to choose "Link bank account" again.
- Clearer bank-link labels — when only one payout method is offered, the button now reads "Link bank account" instead of "Link bank account for ACH"; the "for ACH" / "for Cards" qualifier appears only when both are offered.
- ACH bank linking follows your configuration — the apply flow now offers ACH bank linking whenever it's turned on for the apply configuration, instead of only above a minimum average order amount.
July 13, 2026
- Owner details on applications — the application view now shows the business owner's information.
July 12, 2026
- Sole proprietors can now link a bank account — fixed an error that stopped sole-proprietorship businesses from completing the "Link bank account" step during onboarding.
July 10, 2026
- Bare object ids for payments — the public API now returns plain ids (KSUIDs) for payments and payment plans, matching contacts, and the same bare ids are used in the payment, organization, and application status webhook payloads.
- Breaking: payment and payment plan ids changed from the prefixed form (
Payment#…/PaymentPlan#…) to bare ids, and status webhooks now send bare ids as well — integrations that parsed or stored the prefixed form must update. - Fixed payment plans failing to load when a linked contact was deleted — a payment plan or its sessions linked to a since-removed contact no longer errors the whole list; the missing contact is now returned as empty.
July 8, 2026
- Refetch objects by ID on the public API — the public GraphQL API now exposes
node(id), so integrations can refetch a contact — or any object with a global id — directly by its id. Access is scoped to what your API key is allowed to read.
July 7, 2026
- Fixed payment plans and contacts failing to load — resolved an error that could prevent payment plans from loading, caused by contacts that went missing after a recent update. The affected contacts were restored, and payment plans now load even when a linked contact is missing.
- Cursor pagination for contacts, newest first — the public contacts list is now a paginated connection (
first/after/last/before) that returns your most recently created contacts first, and each contact now has a global id. - Breaking: the public contacts list changed from a plain array to a Relay connection — integrations that read
contactsas a list must switch to readingedges { node }, and contact ids are now global ids (Contact#…).
July 5, 2026
- Owner "decision maker" now defaults to Yes — the "Is this owner a decision maker for the business?" question in the owner form now starts on Yes, since most owners are, so there's one less thing to set for the common case.
- Accept and submit in one step — when accepting your agreements is the last thing left, the button now reads "Accept and submit" and finishes the application in a single action instead of sending you back to the checklist.
- Your first owner is pre-filled after identity verification — once identity verification is complete, your first business owner is now pre-filled from the verified identity details, so you land on the owners step ready to review rather than re-typing it. You still confirm your ownership percentage before submitting.
- Identity verification now comes first — the business details, business owners, and products & services steps unlock only after identity verification is complete, matching how the agreements and bank-linking steps already worked.
July 2, 2026
- Plaid bank linking now requires a transfer configuration — you can no longer turn on Plaid bank linking for an agency until a Plaid transfer configuration is assigned to it. The apply configuration screen explains what's needed and blocks the change until it's set.
- Copyable Configuration ID in the apply config editor — the agency Apply Configuration edit screen now shows a read-only, copyable Configuration ID — the
configuration-idvalue you use when embedding theapply-sessioncomponent on your own website. - Sign in with email and password — you can now set a password and sign in with your email and password, in addition to Google and Microsoft. Set or change your password anytime from Preferences.
- Fixed an error when loading payments — resolved an issue that could cause payments to fail to load, most often on larger pages.
July 1, 2026
- Switch between your contexts — if your account has access to more than one context, you can now choose one when you sign in and switch between them in the portal, based on your roles.
June 30, 2026
- Manage embedding origins and API credentials in the portal — the ClientLoop portal now has screens to manage your allowed embedding origins (CORS allowlist) and API credentials directly, instead of configuring them by hand.
- Edit apply configurations in the portal — apply configurations are now fully editable in the portal, with a per-row edit action. New configurations default ACH bank linking off.
- Bank-linking controls and signup polish — apply configurations now have separate toggles for Plaid and CLP bank linking, and the apply flow only shows a bank-linking step when one of them is enabled. The signup page also gets copy and layout refinements. Also fixes an error that could occur when saving the default apply configuration.
- Re-brand the embedded apply flow — the
<apply-session>component now accepts aniconoverride (inline SVG or image URL) so you can show your own mark, mirroring the existing theme override. - Docs follow your system theme — the documentation site now defaults to your light/dark system preference when you haven't chosen a theme yourself.
- ClientLoop icon in the portal tab — the portal browser tab now shows the ClientLoop icon instead of a leftover default icon.
June 29, 2026
- Payment plan sessions in the public API — create and update payment plan sessions through the public GraphQL API, including
brandLogoUrlandbrandNameoverrides for the logo and business name shown to payers (matching payment sessions). An authenticated API key is still required. - New
payment.status.changed.v1webhook event — get notified whenever a payment's status changes. It's delivered to both the agency's and the payment org's webhooks, and it's now documented in the webhook events catalog. - Consistent
orgIdin webhook payloads — webhook events now emitorgIdas a global id (Org#…), so it's consistent across the organization, application, and payment status-changed events. Update any integration that parsed the raw org id from these payloads. - Email payment links to a merchant contact —
sendPaymentSessionLinkcan now email a payment session created from a merchant-supplied contact, not just a platform contact, and honors an explicit recipient override.
June 28, 2026
- Website verification on applications — a website entered on an application must now resolve to a live page, catching mistyped or dead domains before they're saved. The field stays optional.
- Breaking: the
PaymentSessionLinkChannelvalueSmshas been renamed toPhonefor payment-session and payment-plan link delivery. Clients sendingSmswill now get a validation error. (Phone delivery itself is not yet available.) - Self-service signup — prospective merchants can now apply directly at
/signup, an embedded apply experience with light and dark themes. - Fixed loading older organizations — resolved an error that could occur when reading organizations created before the status field was introduced.
June 26, 2026
- New
org.status.changed.v1webhook event — fires whenever an organization's status changes, so you can react to onboarding progress in real time. The webhook events documentation now also includes a full event index.
June 25, 2026
- Manage webhooks through the API — create, update, and delete webhook subscriptions via the public GraphQL API instead of by hand.
- Versioned webhook payloads — webhook deliveries now carry a payload version and a
cl-request-idheader to make handling and support easier. - Branding on payment sessions — override the logo and business name shown to payers with
brandLogoUrlandbrandName. - Onboarding for publicly-listed businesses — applications can now capture stock-exchange details for public companies.
- Fixed a checkout error — resolved a 401 when starting a Plaid session during anonymous checkout.
- Clearer API reference — payment operations are now grouped by category and the reference navigation is alphabetized.
June 23, 2026
- Themed apply sessions — the embedded apply component now accepts a dynamic theme override so it can match your brand.
- Fractional line-item quantities — order line items now accept decimal quantities. If you use generated client types, regenerate them against the latest schema.
June 20, 2026
- GoHighLevel invoice tipping — the GoHighLevel integration now supports tips on invoices.
June 19, 2026
- Environment selection on Contact IDV — the
<contact-idv-session>component now takes anenvattribute, so you no longer wire up a raw endpoint URL.
June 18, 2026
- More API examples — the GraphQL API reference now includes PHP, Java, and .NET examples alongside the existing ones.
June 17, 2026
- Credit card surcharging guide — a new guide walks through enabling and configuring surcharging.
- Surcharge and tip handling at checkout — adding a surcharge or tip no longer blocks payment; unsupported pay-over-time options are simply disabled instead.
- Fixed a sign-out error — resolved a 500 that could occur when signing out.
June 16, 2026
- Interactive "Try it" in the docs — run GraphQL operations directly from the API reference.
- Simpler component setup — ClientLoop session components now take an
envattribute instead of a raw graph URL. - Quieter console — stopped a spurious 401 from the session probe used by embedded components.
June 15, 2026
- Client package import — the generated GraphQL schema is now exported from the
@clientloop/clientpackage root.
June 14, 2026
- Richer API reference — type pages now show a "Used by" section, and operation pages include ready-to-run curl and fetch examples.
June 13, 2026
- Developer docs site — the ClientLoop developer documentation now lives at docs.clientloop.com, including the embeddable component guides.
June 12, 2026
- Contact mutations in the public API — contact operations are now exposed in the public GraphQL graph under the Contact category.
- Better type docs — GraphQL operation pages now show the definitions of the types they reference.
June 10, 2026
- Redesigned API keys — create and manage API keys with roles and soft-delete, each scoped to its owner.
- Checkout component attributes — checkout web components now use kebab-case attribute names (for example
brand-name). Update any existing embeds that use the old casing. - Auth requirements in the docs — the API reference now shows which operations require authentication.
June 9, 2026
- Verified apply sessions — the new
applySessionCreatemutation issues a verified, embeddable apply session. - Stronger address validation — applications now reject PO box and PMB addresses.
- Automatic business verification — submitting an application now places a business-verification order automatically.