DEV Community: Memo

The “Split-Billed” Agency Asset: How to Track Assets Where the Client Pays the Vendor Directly But the Agency Manages

Memo — Thu, 15 Oct 2026 02:02:10 +0000

Picture this: it’s a quiet Friday afternoon, and an urgent ping lands in your agency’s Slack channel. A high-value client’s e-commerce store is down, showing a generic “domain expired” page or a connection error.

You scramble into the hosting dashboard or domain registrar, only to find that the renewal failed because the client’s corporate credit card expired days ago. Worse, the vendor’s warning emails went to a billing alias, or to a stakeholder who left the company months ago.

Your agency didn’t touch the payment. But the client is still going to ask why you didn’t catch it.

Welcome to the “split-billed” agency asset. This operational trap appears when a client insists on paying vendors such as GoDaddy, Kinsta, Shopify, or AWS directly on their own card, while still expecting your agency to monitor, manage, and guarantee uptime.

This guide covers how the liability gap works, how vendors actually behave when a payment fails, how to build early warnings that don’t depend on the vendor, and how to handle the client conversation when a card declines.

1. The Liability Gap of Client-Billed Vendors

In a clean arrangement, money and technical control sit on the same side. Either the agency bundles hosting, domains, and licenses into a retainer (agency-billed), or the client owns both the wallet and the keys (fully client-managed).

The split-billed model separates them:

[ Client's Credit Card ] ---> [ Vendor (GoDaddy / Kinsta / Shopify / AWS) ] <--- [ Agency Manages Technical Operations ]
          |                                                                              |
          +----------------------------- THE LIABILITY GAP ------------------------------+
                  (Who gets blamed when the card declines and the site goes down?)

Why clients ask for split billing

Procurement and expense rules. Many mid-market and enterprise finance teams don’t allow third parties to put recurring charges on corporate cards, or require a formal review first.
Ownership anxiety. Plenty of clients have had a bad experience with a former vendor holding their domain or hosting account. Keeping the billing profile in their own name is a way to keep legal and administrative control.
Tax and invoicing alignment. Some clients prefer SaaS and infrastructure invoices to be issued to their own legal entity, which keeps VAT and accounting records clean on their side.

The hidden trap for agencies

Split billing satisfies procurement, but it leaves the agency exposed. When a card expires or gets blocked, the vendor’s billing system retries for a while and then suspends or cancels the service. The agency can’t see or change the payment method, yet gets the phone call.

That limit on agency power is built into how vendors design access. GoDaddy’s delegate access, for example, lets account owners share access without sharing passwords, and delegates can’t view or change secure information like payment methods. The same is true of many agency-style permission tiers elsewhere: you can manage the asset, but you can’t fix the card. godaddy

When the site goes dark, stakeholders rarely blame their own accounts payable team. They ask: “Why didn’t you catch this? You manage our digital presence.”

Without a contractual boundary and a tracking process, your agency absorbs the reputational damage, the emergency troubleshooting hours, and the stress of an outage it had no financial authority to prevent.

2. What Actually Happens When a Client’s Payment Fails

“Vendors suspend quickly” and “vendors give you weeks” are both wrong, because timelines differ a lot by vendor and product. Knowing the real clock for each platform in your stack is the foundation of a good response plan. A few examples:

Domains (ICANN-accredited registrars). The Expired Registration Recovery Policy (ERRP) requires registrars to send at least two renewal notices before a domain expires and gives registrants a 30-day Redemption Grace Period before the name is dropped. The catch is that during the Redemption Grace Period, DNS resolution is disabled, so the site is down even though the domain is technically recoverable. Registrars also layer their own timelines on top: at GoDaddy, for example, expired domains are listed on GoDaddy Auctions 26 days after they expire, though not all domains follow the standard timeline. Expired Registration Recovery Policy +3
Managed WordPress hosting (Kinsta). Kinsta’s documented process retries a failed payment three days, eight days, and fifteen days after the first failure, and if the fourth attempt fails the plans and services are cancelled automatically. During suspension, all traffic and processes stop and visitors can’t load the site. Kinsta’s first failure notice goes to the email address used to log in to MyKinsta. That is the account owner’s login, not necessarily anyone at your agency. Failed Payments +2
E-commerce platform (Shopify). Shopify’s help center says a store doesn’t freeze until the bill’s due date, but once frozen, you can’t access the admin and customers can’t view the store. Recovery needs the store owner: to reactivate, you must pay outstanding charges, and if you reactivate more than 30 days after the last bill was issued, you must also pick a plan and pay for the upcoming subscription cycle. A staff or collaborator account can’t do this for the client. shopifyshopify
Cloud infrastructure (AWS). AWS warns that outdated contact information can lead to unpaid invoices and potential account suspension. Even after a past-due balance is paid, reactivation isn’t always instant: AWS re:Post guidance says it typically takes up to 24 hours for the account to reactivate after payment, and some users report longer waits that require a support case. icompaasrepost

The practical takeaway: the real window between “card declined” and “customer-visible outage” ranges from a couple of weeks to nearly immediate depending on the platform and product. Record the actual clock for each split-billed asset instead of assuming one number.

3. Setting Up “Agency Monitoring vs. Client Payment” Tags

To protect your agency from uncompensated liability, separate operational oversight from financial execution with a formal tagging system in your asset register.

Step 1: Audit your stack and tag every asset

Every domain, SSL certificate, hosting account, and plugin or software license should be recorded in whatever system you already use (Notion, Airtable, Hudu, IT Glue, or even a well-kept spreadsheet) with explicit responsibility tags:

[A-Bill / A-Manage]: Agency-managed and agency-billed. The cost is rolled into the retainer. You carry the most risk, but you also control the renewal.
[C-Bill / C-Manage]: Client-managed and client-billed. Low agency liability, but also hands-off.
[Split: C-Bill / A-Manage]: The danger zone. The client owns the billing profile and card, but the agency handles deployments, updates, DNS, and optimization.

For each split-billed asset, capture at least:

the vendor and plan,
the renewal or billing date,
who owns the account (and the login email on it),
where billing and payment-failure emails are sent,
the vendor’s failed-payment timeline (from the section above),
the client contact who can actually update the payment method.

That last field matters more than any other. When a card declines, the person you need is whoever can change it, and in a split-billed setup that is never you.

Step 2: Add a financial-responsibility clause to your contract

For assets tagged split-billed, your master services agreement (MSA) or statement of work (SOW) should say plainly who is responsible for what. A sample clause:

Client Financial Responsibility Clause: “While [Agency Name] provides technical monitoring and deployment services for [Asset Name], the client retains sole responsibility for maintaining an active, valid payment method with the underlying vendor ([Vendor Name]) and for responding to vendor payment-failure notices. [Agency Name] is not liable for service interruptions, domain lapses, or data loss resulting from failed client payments, expired billing profiles, or delayed client response to payment-failure notifications, provided [Agency Name] has notified the client of the failure in accordance with the escalation procedure in this agreement.”

Two notes. First, have a lawyer review any clause like this against your jurisdiction and your client’s contract terms. Second, a disclaimer protects you in a dispute but does nothing for the relationship in an outage, which is why the notification and escalation language matters as much as the disclaimer.

4. How to Trigger Alerts Before a Client Ignores a Renewal Notice

Relying on vendors to warn clients about failing payments is a weak plan. Notices go to whichever email is on file, and in split-billed accounts that is often an ex-employee, a shared inbox no one reads, or an address that bounces. You need an early-warning system that doesn’t depend on the vendor’s emails reaching the right person.

Put billing notices where two organizations can see them

Where the vendor allows it, add a second recipient for billing and payment-failure mail.

AWS: Datadog’s security guidance notes that all AWS accounts should have the billing, operations, and security alternate contacts configured so alerts reach the right teams. A shared billing alias with one client person and one agency person is a good fit for the billing contact. datadoghq
Other vendors: Check what the platform supports (additional billing contacts, notification recipients, or multiple account admins). Where none exist, ask the client to set up an email forward or a shared distribution list that includes your operations inbox.
Avoid individuals. Use role-based aliases (for example, billing-alerts@clientdomain.com) so a departure doesn’t silently break the notice path.

Add independent expiry monitoring

External monitors read public data (registry expiration dates, the certificate your server presents), so they work regardless of whose card is on file.

Domain expiry monitoring. Several uptime tools include this. UptimeRobot’s domain monitoring sends alerts 30, 14, 7, and 1 day before domain expiration, but it is included only in paid plans. Better Stack also offers domain expiration monitoring, with a setting to alert 14 days before expiry. Expect some noise: users report that some registrars, such as GoDaddy, auto-renew closer to expiry than the alert window, causing false positives. Treat an early alert as a prompt to verify the payment method, not as proof of failure. domain expiration monitoring +3
SSL/TLS certificate monitoring. Many monitors check this as part of regular uptime checks. According to one 2026 roundup, Better Stack builds SSL checks into its uptime monitors, Pingdom embeds SSL checks in HTTPS uptime checks, and Datadog Synthetics offers SSL tests for certificate validity and expiration. dotcom-monitor
Certificate lifetimes are getting shorter. Under CA/Browser Forum Ballot SC-081v3, the maximum validity of publicly trusted TLS certificates drops to 200 days from March 15, 2026, 100 days from March 15, 2027, and 47 days by March 15, 2029. That makes renewal failures more frequent for certificates that aren’t automated, especially paid certificates bought separately on a client’s card. Set shorter alert windows as validity shrinks. encryptionconsulting
Calendar alerts for the vendor’s billing date, not just the expiration date. For split-billed assets, put a reminder 14 days before the next charge to confirm the card on file is still valid. This catches the most common failure, an expired card, before the vendor ever tries to charge it.

+------------------------------------------------------------+
|             Multi-Layered Early Warning System             |
+------------------------------------------------------------+
| 1. Domain expiry monitoring (independent of the registrar) |
| 2. SSL/TLS certificate expiry monitoring                   |
| 3. Shared billing inbox (client + agency visibility)       |
| 4. Calendar check on the card before each billing date     |
+------------------------------------------------------------+

None of these tools can see whether a card on file is valid, and they can’t tell you a payment failed. They only tell you that an expiration date is approaching. The card check in step 4 and the shared billing inbox are what close that gap.

5. Managing Friction When a Client Card Declines

Even with good preparation, cards decline because of fraud flags, bank security blocks, or expiry. When a split-billed asset hits a payment wall, you want a scripted, professional response that fixes the problem without making the client defensive.

Step 1: Triage internally first

When you learn a payment has failed:

Check the status. Is the asset in a retry window, a grace period, or already suspended? Use the failed-payment timeline you recorded for that vendor.
Work out the urgency. A Kinsta account in its first retry cycle is a different situation from a domain already in its Redemption Grace Period, where DNS is off and fees go up.
Identify who can fix it. Find the client person with authority over the payment method, not just the day-to-day project contact.

Step 2: Send a calm, specific heads-up

Frame it as a routine operational notice that needs their billing team’s action, not an accusation. A template:

Subject: Action needed: payment update required for [Asset Name / Domain]

Hi [Client Name],

Our monitoring flagged that the most recent renewal payment for your [hosting / domain / platform] account with [Vendor Name] didn’t go through. This is usually caused by an expired card or a bank security check.

To avoid downtime for [Client Website], could you or your finance team update the payment method in your [Vendor Name] account by [date]? Here’s the direct link to the billing page: [Insert Vendor Billing URL].

Please reply once it’s done and we’ll confirm the renewal processed on our side.

Thanks,

[Your Name]

Step 3: Escalate on a schedule

If the payment method isn’t updated within about 48 hours, or sooner if the vendor’s clock is short:

Go to an executive sponsor. Contact the person who owns the budget, such as the CMO or the finance lead, not just the project manager who can’t touch corporate finance tools. Put the vendor’s deadline in the message.
Consider an “agency bridge” only if you’ve agreed to it in advance. If a critical asset is close to suspension or a domain is near auction, the agency may pay with its own card and bill the client afterward. Be aware of the constraints:
- Many billing portals only let the account owner change or add a payment method, and Shopify reactivation specifically requires the store owner. So a bridge may be impossible without the client’s involvement, or may require them to add a card you control.
- It exposes you to the client’s non-payment, so get the client’s written approval (email is fine) before you spend anything.
- If you charge an administrative fee on top of the vendor cost, state it in the contract up front. Any specific figure should reflect your own rates; there is no industry standard for this fee.
- A prepaid or spend-limited virtual card issued by the client is a cleaner alternative where their finance team allows it.

Step 4: Close the loop afterward

Once the payment goes through, confirm that the service is restored, note the incident in the asset record, and ask the client to put a recurring reminder on their side. Then ask whether the billing notice email needs to change so the next failure reaches the right people sooner.

Summary Checklist for Split-Billed Assets

Audit inventory: Identify every client asset where the client controls billing but the agency manages operations.
Record the vendor’s failed-payment timeline: Document how long each platform gives you (retries, grace periods, suspension, deletion) instead of assuming.
Name the person who can fix the card: Keep a client contact with payment authority in the asset record.
Update contracts: State that the client is responsible for keeping valid payment methods, and define your notification and escalation duties. Have a lawyer review it.
Add independent monitoring: Use third-party tools for domain and SSL expiry, and check the card on file ahead of each billing date.
Share billing notices: Route vendor billing and payment-failure emails to a role-based alias visible to both the client and your operations team.
Keep an escalation script ready: Use a calm heads-up email, a deadline, and an executive escalation path.
Agree on any emergency payment arrangement in advance: Don’t decide it mid-outage.

Originally published at https://instarenewal.com/blog/the-split-billed-agency-asset-how-to-track-assets-where-the-client-pays-the

The Open-Source Supply Chain Vulnerability: Tracking Custom Git Submodules & Private Package Registries for Client Apps

Memo — Wed, 14 Oct 2026 02:05:33 +0000

Modern web agencies rarely build client applications entirely from scratch. They assemble tailored web apps from a modular blend of open-source libraries, internal boilerplates, private GitHub or GitLab repositories, proprietary npm packages, and private PHP Composer registries.

This architecture speeds up delivery and cuts duplicated work. It also creates a blind spot: the agency’s private supply chain. Private dependencies, submodules, and registry tokens are often tied to the personal accounts of individual developers. When a developer leaves unexpectedly, a token expires, or a repository permission is set wrong, client update pipelines stop. Security patches don’t deploy, and automated builds fail. Clients stay exposed to known vulnerabilities while the agency works out why its own pipeline can no longer reach its own code.

This article covers how these failures happen, which recent platform changes make them more likely, and how to harden the setup.

1. The Anatomy of the Agency Supply Chain Blind Spot

Enterprise supply chain security usually focuses on public registries such as npm or PyPI and on threats like dependency confusion and typosquatting. Agencies face those risks too. They also face an operational one that gets less attention: who actually holds the keys to the private pieces?

A typical agency workflow looks like this:

Private Git submodules: Reusable UI components, authentication modules, or design systems are pulled into client repositories through Git submodules (.gitmodules), which pin each client repository to a specific commit of the shared code.
Private package registries: Custom business logic, helper libraries, and proprietary themes live in private npm organizations, GitHub Packages, Private Packagist, or self-hosted Satis servers.
Developer-bound credentials: CI/CD pipelines, local environments, and staging servers authenticate against these private assets using tokens or SSH keys that a specific employee created.

Why Personal Credentials Creep In

The personal-token habit is partly a platform quirk. In GitHub Actions, the built-in GITHUB_TOKEN is scoped to the repository running the workflow. The long-standing guidance in the actions/checkout documentation is that if a repository contains submodules from other private repositories, you must supply a separate credential, typically a personal access token (PAT) stored as a secret. The fastest fix on a deadline is to paste in whoever’s PAT works, and that token then ends up in dozens of client repositories.

The Point of Failure

A personal access token can only reach what its owner can reach. When the original developer leaves, is removed from the organization, or has their account suspended, the implicit trust chain breaks. If their registry account was registered to a company mailbox that gets deactivated, the agency may also lose the ability to receive password-reset and 2FA emails for that registry account.

The next npm install, composer install, or git submodule update --init then fails with a 401, a 403, or a misleading 404, since private resources often return “not found” to unauthenticated callers. When a critical CVE lands in a core library, the agency cannot ship the fix because its pipeline is locked out of its own private dependencies.

2. Technical Vectors: How Private Submodules and Registries Fail

To prevent supply chain paralysis, technical leads and agency operations staff need to understand the specific failure modes.

A. The Git Submodule Trap

A submodule is a pointer from a parent repository to an exact commit in another repository. That makes builds reproducible, but it adds fragility in agency environments:

Authentication friction: A submodule can point to a private repository over HTTPS or SSH. Cloning with git clone --recurse-submodules requires access to every one of them. Per GitHub’s own guidance, deploy keys are scoped to a single repository and are not linked to organization membership. Several private submodules therefore need several keys, or one shared machine identity.
Unpushed submodule commits: The parent repository records only a commit hash. If a developer commits inside a submodule folder but never pushes, the parent now references a commit that exists only on their laptop. Everyone else’s clone, and every CI run, fails to fetch it. Uncommitted edits inside a submodule never reach the parent at all.
Detached HEAD confusion: Submodules check out a specific commit rather than a branch, so developers who commit without switching to a branch can lose track of their work.
Hostile-repository risk: Git has had real submodule-related vulnerabilities. CVE-2024-32002 allowed remote code execution during recursive clones on case-insensitive, symlink-capable filesystems, and it was patched in Git 2.45.1 and the backported maintenance releases. CVE-2025-48384 abused how Git handles a carriage return at the end of a submodule path in .gitmodules. It allowed arbitrary file writes and code execution on Linux and macOS during git clone --recursive, and Git shipped fixes on July 8, 2025. CISA added it to its Known Exploited Vulnerabilities catalog in August 2025. Both attacks need a malicious repository to be cloned. They matter most for CI systems or developers that clone third-party code with --recursive while holding valuable credentials.

B. Expiring Tokens and Silent Pipeline Breakage

The ecosystem has been moving away from long-lived tokens, and several changes have already reached agency pipelines:

npm classic tokens are gone. npm permanently revoked all classic tokens on December 9, 2025. Any pipeline still using one stopped working that day.
Logging in now yields a session token. npm login issues a two-hour session token rather than a long-lived one.
Granular write tokens are capped. Write-enabled granular tokens default to seven days and cannot exceed 90 days. In practice, a CI secret holding a write token must be replaced at least every 90 days.
Read-only tokens have their own expiry. Installing private packages in CI needs only a read-only granular token, but its expiry date is still set at creation. Someone has to know when it runs out.
GitHub PAT lifetimes depend on org policy. Fine-grained PATs can be created without an expiry unless an organization or enterprise owner sets a maximum lifetime. The default organization maximum for fine-grained tokens is 366 days. Owners can also require approval for fine-grained tokens, but classic PATs are not subject to that approval step.
Fine-grained PATs cannot access GitHub Packages. GitHub lists this as a current limitation, so many agencies still depend on classic PATs, or on GITHUB_TOKEN inside Actions, for private package installs.
GitLab tokens expire too. Project and group access tokens default to a 365-day maximum lifetime, and non-expiring tokens were removed in GitLab 16.0. Each one creates a bot user, so it is not tied to a person, but it still expires.

The failure pattern is the same on every platform. Code validation and unit tests pass, then the build fails at the install, packaging, or deployment step because a token quietly lapsed.

Traditional Approach (Vulnerable)	Modern Secure Alternative
A literal `_authToken` value committed in `.npmrc`.	`.npmrc` referencing an environment variable (for example `${NPM_TOKEN}`), with the value injected from the CI secret store.
PATs tied to individual developer accounts.	GitHub App installation tokens, machine users, deploy keys, or GitLab project and group access tokens, each with a named owner.
Long-lived write token used to publish from CI.	npm trusted publishing (OIDC) for the publish step.
One shared read token, nobody knows when it expires.	Read-only, scoped tokens with a recorded expiry date and a named owner.
Manual updates after the build breaks.	A written rotation schedule with reminders set before expiry.

3. Real-World Evidence: Why Credential Hygiene Matters Beyond Continuity

Lost access is not the only risk. Credentials sitting in CI systems are an attack target, and recent incidents show it:

tj-actions/changed-files (March 2025). Attackers modified the popular GitHub Action so that it printed CI secrets into workflow logs. The advisory counts more than 23,000 repositories using the action, and CISA added CVE-2025-30066 to its Known Exploited Vulnerabilities catalog. Industry reporting traced the chain back to a stolen personal access token. Exposed secrets included GitHub PATs and npm tokens, which is why a broadly scoped, long-lived token in one repository can become everyone’s problem.
Shai-Hulud (2025). This self-propagating worm harvested developer and CI secrets and used them to compromise more packages. Its second wave in November 2025 hit more than 830 npm packages and spread into the Maven ecosystem.

These incidents show why replacing a leaver’s token with another long-lived, broadly scoped token is not enough. Credentials should be scoped to the minimum, short-lived where possible, and owned by a role rather than a person.

4. Illustrative Scenario

The following scenario is hypothetical but typical:

Agency X builds headless WordPress and Next.js sites for 40 small and midsize clients. It uses a private npm package, @agency/auth-toolkit, to handle single sign-on across them.

The senior developer who set up CI/CD three years ago leaves. Their personal npm token is saved as a secret in all 40 client repositories. It is either revoked during offboarding or silently reaches its expiry date.

Weeks later, a high-severity advisory lands against a dependency of @agency/auth-toolkit. The agency bumps the package and tries to roll the update out through GitHub Actions. Every client build fails at npm ci with an authentication error.

Engineers spend the day regenerating tokens, updating secrets across 40 repositories, and re-running pipelines, while client sites stay on the vulnerable version.

The fix would have taken minutes if the credentials had been owned by the organization, centrally managed, and tracked with an expiry date.

5. Best Practices for Hardening the Agency Supply Chain

1. Move from Personal Credentials to Organization-Owned Identities

Don’t let individual accounts authenticate CI/CD pipelines or hold private registry credentials. Choose from the options below, in the order GitHub itself suggests:

Prefer GitHub Apps where possible. GitHub’s documentation recommends GitHub Apps over deploy keys and machine users for fine-grained control. Their installation access tokens are decoupled from any individual user, which makes them comparable to service tokens.
Use deploy keys for single-repository read access. They are simple and not tied to a person. They are scoped to one repository, so each private submodule needs its own key.
Use a machine user when nothing else fits. A dedicated bot account (for example ci-bot@youragency.com, owned by a shared mailbox) can be added to the organization with read-only access to just the repositories the build needs. On a paid plan it typically occupies a seat like any other member.
On GitLab, use project or group access tokens. They are tied to a bot user rather than a person and are limited to the resources the token needs.
Apply least privilege. Read-only is enough for most CI jobs that install dependencies and run tests.
Own the mailbox. Register registry and bot accounts to a shared alias that more than one person controls, so recovery and 2FA emails never depend on one individual’s inbox.

2. Use OIDC Trusted Publishing, but Understand What It Covers

npm trusted publishing with OpenID Connect became generally available on July 31, 2025. It lets GitHub Actions or GitLab CI/CD workflows publish packages without storing a long-lived npm token. It requires npm CLI 11.5.1 or later and works for private and public packages.

It does not remove every token from the pipeline. npm’s own documentation says trusted publishing is not intended for npm install. A build that installs private dependencies still needs a read-only granular token, and OIDC covers only npm publish-style operations, not every command. If an agency’s pain point is builds failing to pull @agency/* packages, OIDC does not solve it.

The practical setup is OIDC for publishing from CI, plus one scoped, read-only token for installs. That token needs a recorded owner and a rotation reminder.

3. Handle Composer Credentials Deliberately

Composer reads credentials from auth.json (per project or global) or from the COMPOSER_AUTH environment variable. Keep them out of composer.json and out of version control. Pass them from the CI secret store instead.

Private Packagist’s documentation recommends read-only tokens for CI that runs composer install against an existing composer.lock. These tokens do not count as users in the organization, but they aren’t suitable for composer update. For GitHub-hosted private packages, Composer supports github-oauth tokens, which raises the same personal-token question covered above.

4. Protect Your Namespace

Register your organization scope on the public npm registry, even if every package under it is private. An unclaimed internal scope or package name lets an attacker publish a lookalike on the public registry. A misconfigured build can then resolve the public copy instead of your private one, which is the dependency confusion scenario.

5. Audit and Document Git Submodules

Keep an inventory. Record which client apps use which submodules, which repository each one points to, and which credential fetches it.
Consider migrating to packages. If submodules cause frequent friction, move reusable code into private npm or Composer packages, where version constraints (such as ^1.2.0) are resolved by the package manager rather than by raw commit hashes.
Pin and update Git. Keep Git current on CI runners and developer machines, since both submodule CVEs above were fixed in Git releases. Avoid --recursive clones of untrusted repositories.
Review access regularly. Confirm that deploy keys and SSH keys tied to submodules are still valid and owned by the organization.

6. Pin and Harden Your CI Pipeline

Pin third-party Actions to a full commit SHA. The tj-actions incident worked by moving existing version tags to a malicious commit. A tag is not a fixed reference.
Limit secrets. Pass each job only the secrets it needs, and avoid printing environment values in logs.
Store secrets in a managed system. Use GitHub Actions Secrets, GitLab CI/CD Variables, or a dedicated secrets manager rather than local developer machines.

7. Build an Offboarding and Expiry Routine

Technical controls still need an owner and a calendar. At a minimum:

Maintain a register of every private registry, submodule source, token, and deploy key, covering where it is used, who owns it, what scope it has, and when it expires.
Add credential rotation to offboarding. Before a developer’s last day, check which pipelines, secrets, and registry accounts depend on their personal identity.
Set reminders ahead of expiry. With npm write tokens capped at 90 days, a quarterly review is the minimum. Reminders that fire two to four weeks before expiry leave time to rotate calmly.
Test the pipeline from scratch. Periodically confirm that a clean clone with --recurse-submodules, a fresh npm ci, and a fresh composer install succeed using only organization-owned credentials.

8. Monitor Continuously

Just as websites need uptime and plugin-update checks, agency code needs supply chain health checks. At a minimum, confirm:

Whether CI/CD pipelines can still authenticate against private registries and private submodules.
When tokens and SSH deploy keys are scheduled to expire.
Whether dependency trees contain known vulnerabilities across both public and private packages. Tools such as Dependabot, Renovate, npm audit, and composer audit cover the dependency side.

Beyond Standard Maintenance

For agencies scaling their maintenance operations, keeping off-the-shelf plugins patched is only half the job. Operational maturity means treating private repositories, internal registries, and the credentials that unlock them with the same discipline applied to public open-source dependencies. That discipline has three parts:

Tie access to roles and organization-owned identities rather than individual staff.
Know the expiry date and the owner of every credential.
Rotate before the date arrives, not after a build fails.

With that in place, a departing developer or an expiring token becomes a routine calendar item rather than a client-facing incident, and urgent security patches can ship when they need to.

Originally published at https://instarenewal.com/blog/the-open-source-supply-chain-vulnerability-tracking-custom-git-submodules

The “Who Gets the Notice?” Audit: Mapping Provider Billing Contacts vs. Actual Account Owners

Memo — Tue, 13 Oct 2026 02:12:04 +0000

It is a quiet Friday afternoon when a client calls in a panic. Their website has stopped loading, business email has stopped routing, and the landing pages built for next week’s launch have vanished.

You try to log into the domain registrar account, only to hit a wall. The login belongs to a developer who left the agency two years ago. The renewal reminders, receipts and card-expiry alerts have been going to that person’s work inbox, which was deleted during offboarding. The domain expired overnight, the clock on recovery is running, and nobody at your agency ever saw the warnings.

For agencies, web shops and in-house IT teams, domains, SSL certificates, hosting servers and SaaS licenses are the foundation of client work. Yet ownership and billing details tend to go unreviewed until something breaks.

This guide walks through a “Who Gets the Notice?” audit. You map who actually receives each provider’s notices against who actually owns and pays for each asset. Then you fix the gaps with a shared notification address such as renewals@agency.com, without running afoul of registrar rules or ICANN policy.

1. Why Agencies Lose Control of Their Own Assets

Infrastructure sprawl happens gradually. A founder registers the first few client domains with a personal card and a work email. As the agency grows, team members buy hosting, spin up cloud instances and add client subscriptions using whatever payment method is closest. Three failure patterns follow.

The single-person inbox. When renewal alerts go to john.doe@agency.com instead of a role-based address, John’s departure breaks the feedback loop. Once his mailbox is decommissioned, notices bounce or vanish.
The orphaned payment method. Cards expire, get reissued with new numbers, or are cancelled when a cardholder leaves. If the failed-payment notice goes to an unmonitored inbox, nobody notices until the service is suspended.
The ownership mismatch. A freelancer or vendor registers a domain or hosting plan “on behalf of” the agency but lists themselves as the owner. When the relationship sours, recovering the asset can mean a dispute process or legal action.

2. What ICANN’s Domain Contact Model Looks Like Now

Many guides, including older versions of this one, say every domain registration requires four contacts: registrant, administrative, technical and billing. That is outdated for most generic top-level domains (.com, .net, .org and similar).

ICANN’s Registration Data Policy took effect on August 21, 2025. Under it, the registrant is the only contact that is always required. Administrative, technical and billing contacts are optional for most gTLDs, and some registrars have stopped collecting or storing admin and billing contacts entirely. Some registries may still require additional data, and country-code domains (.uk, .de, .in and others) follow their own national rules rather than ICANN’s.

Two related changes matter for the audit:

WHOIS has been replaced by RDAP. Since January 28, 2025, gTLD registries and registrars must provide RDAP and are no longer required to run the legacy WHOIS service, with exceptions including .com. You can look up public registration data through ICANN’s Lookup tool, but personal contact data is typically redacted, so the registrar dashboard is the real source of truth.
The Organization field decides who the owner is. Some registrars now treat a company named in the registrant “Organization” field as the registered name holder, with the named person recorded only as that organization’s contact. An agency that registers a client domain under a freelancer’s personal name, or under the agency’s own name, may not have recorded the owner it intended.

Contact or setting	Role	What to check
Registrant	The domain’s legal holder. Always required. ICANN requires the data to be accurate and reachable.	Is the legal entity (your client or your agency) named, not an individual? Is the email a monitored role address?
Administrative	Optional for most gTLDs. Historically handled non-technical decisions.	Does your registrar still show one? If so, make sure it isn’t a former employee.
Technical	Optional for most gTLDs. Historically covered DNS and name servers.	Same check. A generic address is acceptable.
Billing	Optional for most gTLDs. Historically the payment contact.	Where it exists, point it at the finance alias. If none is set, communications generally default to the registrant.
Registrar account login email	Not an ICANN contact, but often where invoices, receipts and payment failures land.	Does the account login belong to a person or a role? This is the one most agencies overlook.

Registrars differ in which of these fields they show and which address gets which message, so check each provider rather than assuming.

The Common Mistake: One Person in Every Field

Listing the same founder or IT admin everywhere is convenient, but it creates a single point of failure. If that person goes on leave, changes roles or leaves the company, every notice goes dark at once.

3. Why the Registrant Email Matters Most

The registrant email is the address that carries compliance consequences. Under the accuracy requirements in ICANN’s Registrar Accreditation Agreement (the Whois/RDDS Accuracy Program Specification), registrars must verify the registrant’s email or phone, typically by sending a link, when a domain is registered or transferred in, or when the registrant’s name or email changes.

If the registrant doesn’t respond within 15 calendar days, the registrar must verify manually or suspend the domain. Suspension usually means a clientHold status, which takes the website and email offline. Registrars must also act if they receive inquiries about inaccurate contact data and the registrant fails to respond within 15 days.

So the registrant address cannot be a dead mailbox. A verification email sent to a departed employee’s account can take a domain offline for reasons that have nothing to do with payment.

Expiry notices also go to the registrant. ICANN’s Expired Registration Recovery Policy requires registrars to send at least two pre-expiration reminders, roughly a month and a week before expiry. Registrars also have some flexibility on timing. For gTLDs, a 30-day Redemption Grace Period follows deletion. During it the name can be restored, but DNS resolution is disabled and transfers are blocked. Restoration usually costs more than a normal renewal. The registrant’s inbox is therefore the main place the warning lands.

4. Running the Audit

Step 1: Inventory every asset

List every domain, SSL certificate and hosting account your agency owns or manages for clients. Don’t rely on memory or a single spreadsheet. Check twelve months of corporate card and expense statements, your DNS provider’s zone list, and the accounts of departed staff to find forgotten registrations.

Step 2: Check each registrar and host profile

For each domain, log into the registrar dashboard (for example GoDaddy, Namecheap, Cloudflare Registrar, Porkbun, or Squarespace Domains, where former Google Domains registrations now live) and review the contacts. Google sold its domain business to Squarespace in 2023, and Squarespace announced in November 2024 that the migration was complete. Ask of each domain:

Is the registrant organization your agency’s or your client’s legal name?
Does any contact, or the account login itself, point to a former employee?
Does the registrant email reach a role address that several people can see?

Step 3: Audit payment methods

Check the card or payment method on each account. Flag cards tied to individuals or soon-to-leave employees. A company-level virtual card from a spend platform such as Ramp or BILL Spend & Expense (formerly Divvy) can be reassigned or locked without any individual’s name attached. If a card is replaced, each vendor’s billing profile still needs the new details.

Step 4: Record owner, payer and notice address separately

For every asset, write down three things: the legal owner, the payer, and the address that receives notices. A mismatch between any two is a finding. This distinction is the core of the audit, because many assets have an owner nobody has recorded and a payer nobody remembers.

5. Building the Central Notification Address

The fix for the departed-employee problem is a shared address such as renewals@agency.com or domains@agency.com, backed by a group instead of a single user.

[ Registrar / Host ]
        │
        ▼  (renewal notices, invoices, verification emails)
[ renewals@agency.com ]  (shared mailbox or group with archive)
        ├── Operations lead (primary reviewer)
        ├── Finance (billing and receipts)
        └── IT / DevOps (technical escalations)

Practical setup tips:

Use a group or shared mailbox, not a person’s seat. In Microsoft 365, a shared mailbox doesn’t need its own license up to 50 GB, though the people who access it need licenses. Google Workspace offers groups and collaborative inboxes. A shared mailbox or collaborative inbox keeps a searchable history, which a plain distribution list does not.
Make sure it accepts outside mail. Group settings in both platforms can restrict posting to internal senders, which would silently block registrar emails.
Allowlist registrar senders. Registrar mail sometimes lands in spam. Add the sending domains of your providers to your allowlist, and route messages from renewals@ to a priority folder or alert.
Name an owner. A shared inbox everyone owns is an inbox nobody checks. Assign a rotating weekly reviewer to clear the queue, file receipts into accounting software such as QuickBooks or Xero, and log upcoming renewal dates on a master calendar.

6. Does a Shared Address Break Registrar Rules?

Generally no, provided the data stays accurate and the address is monitored.

The registrant must be accurate and reachable. ICANN requires registrant data to be truthful and current. Don’t use a fake name or placeholder. Use the real legal entity and an address that can complete the email verification described above.
Role addresses are fine. Nothing in ICANN’s requirements bars a functional address like domains@ for the registrant or any optional contact, as long as someone reads it and can respond within the 15-day windows.
Privacy services need a forwarding check. WHOIS privacy and proxy services are useful for hiding personal details, and much public data is redacted anyway. Confirm that your registrar still delivers verification and renewal notices to your role address, and test it.
Check ccTLD rules separately. Country-code registries set their own contact, eligibility and verification requirements.

7. Keeping It From Drifting Back

After the audit, put some guardrails in place.

Use a team password manager. Store registrar and hosting logins in a business password manager such as 1Password or Bitwarden, with role-based access, so credentials survive staff turnover. Enable multi-factor authentication on every registrar account and register the MFA method to the team, not one phone.
Turn on auto-renewal, with a backup. Auto-renew for core assets, backed by a company payment method that someone monitors, and treat manual reminders as a safety net rather than the main plan.
Review quarterly. Check user access, confirm active cards, and send a test message to renewals@agency.com to confirm it reaches every stakeholder. Add offboarding steps to your HR checklist so no registrar or host account stays tied to a departed employee.

Treat domain and hosting administration with the same care as your financial accounting. A Friday-afternoon scramble is far more expensive than a quarterly review.

Originally published at https://instarenewal.com/blog/the-who-gets-the-notice-audit-mapping-provider-billing-contacts-vs-actual

The “Orphaned Registrar” Crisis: How to Recover Domain Control When the Original Developer Disappears

Memo — Mon, 12 Oct 2026 01:48:04 +0000

It is 2:00 AM on a Tuesday. Your client’s flagship e-commerce site goes down. Revenue has stalled and the team is panicking. You log in to the hosting provider and find the real problem. The DNS records need urgent changes, or an SSL certificate must be re-issued, and the domain sits in a personal GoDaddy, Namecheap, or Squarespace account (which took over the former Google Domains registrations) opened by a freelance developer who stopped answering emails three years ago.

Welcome to the Orphaned Registrar Crisis.

For digital agencies, marketing firms, and business owners, this is a ticking time bomb. A domain is the address everything else depends on: the website, email, ad landing pages, and the validation records that certificate authorities check. If you don’t control the registrar account, and your company isn’t the registrant of record, you are one uncooperative third party away from losing control of your site’s address.

This guide covers how orphaned registrations happen, how to work through recovery at major registrars, and how agencies can build audits and handoff protocols so it doesn’t happen to their clients.

1. Anatomy of an Orphan: How Domains Get Trapped

Orphaned domains rarely come from bad intent. They come from shortcuts, casual handshakes, and nobody asking who owns the account.

Two Questions, Not One

Most people treat “who owns the domain?” as a single question. It is two:

Who is the registrant of record? This is the person or organization listed as the registered name holder. Registrars and ICANN-based policies generally treat this party as the one with authority over the name. Registrars such as GoDaddy have recovery paths built around registrant status.
Who controls the registrar account? This is whoever can log in, change DNS, unlock the domain, and renew it.

An orphaned domain is usually a mismatch between the two. The best case is that your client is the registrant but a departed developer holds the login. The worse case is that the developer is the registrant too.

The Original Sin: Personal Accounts Over Business Infrastructure

When a site is first built, founders often delegate setup to a freelancer, agency, or tech-savvy early hire. To save time, the developer registers the domain with a personal email, personal credit card, and personal login.

The shared-account trap: The developer registers clientbrand.com inside an existing registrar account that holds dozens of other domains for unrelated clients. The domain can’t be handed over without either unpicking that account or moving the domain out of it.
The 2FA roadblock: Two-factor authentication is tied to the developer’s phone. When they change numbers, change careers, or stop cooperating, nobody else can complete the login challenge.
The reseller mismatch: The domain was bought through a web host, a white-label reseller, or a site-builder bundle. The company on the invoice isn’t the accredited registrar of record. Under ICANN’s revised Transfer Policy, the transfer authorization code (the old “EPP code”) is created by the registrar of record, so you need to find out which company that is.

The Three-Year Drift

The crisis usually surfaces years later. The domain auto-renews quietly on a card that hasn’t expired yet. The agency bills the client for “hosting and maintenance,” but nobody checks who can actually log in to the registrar. Then the card expires or the developer’s email address is abandoned. Renewal notices and security alerts go to an inbox nobody reads. A routine change, like pointing DNS at a new host, suddenly can’t be made.

Why It Hurts More Now: Certificates Need Fresh Proof of Control

Losing registrar or DNS access also blocks certificate renewals. Under the CA/Browser Forum’s Ballot SC-081v3, the maximum validity of publicly trusted TLS certificates fell to 200 days on March 15, 2026. It drops to 100 days on March 15, 2027 and to 47 days on March 15, 2029. The reuse period for domain control validation shrinks on the same schedule, down to 10 days by 2029. As certificates get shorter, proving control of the domain becomes a routine, repeated step in every renewal. A domain nobody can manage becomes an outage much sooner.

2. The High-Stakes Recovery Playbook: Getting the Domain Back

If you’re in an orphaned-domain emergency now, a generic support ticket will likely go nowhere. Registrars guard against domain hijacking, which also makes legitimate recovery slow when the account holder is missing or hostile. Here is a practical order of operations.

Step 1: Reconnaissance (RDAP, Registrar, and DNS History)

Before contacting anyone, gather facts.

Run an RDAP lookup. ICANN ended the requirement for gTLD registries and registrars to run a WHOIS service on January 28, 2025, and RDAP is now the standard. ICANN’s free lookup tool (lookup.icann.org) queries RDAP data.
Identify the registrar of record. Registrar details stay visible even when privacy protection is on. Registrant names, emails, and phone numbers are usually redacted. This has been the norm since GDPR in 2018, and ICANN’s Registration Data Policy, effective in August 2025, formalized limited publication.
Don’t confuse DNS host with registrar. Nameservers tell you where DNS is hosted, not where the domain is registered. A domain can use Cloudflare or Bluehost nameservers while being registered elsewhere.
Check historical records. Commercial historical-WHOIS services archive older records, and records from before 2018 sometimes show the original registrant. Treat anything you find as a lead to verify rather than proof.
Gather your own evidence. Collect old invoices, hosting receipts, renewal emails, contracts, and anything showing the company paid for or used the domain.

Step 2: Direct Outreach (The Gentle Approach)

If you can reach the developer through LinkedIn, a professional email, or a mutual contact, make the request easy to say yes to.

Give exact instructions. Registrars have built-in tools for this. At GoDaddy the owner uses Transfer to another GoDaddy account (formerly called Account Change), and the recipient must accept within 10 days. Domains moved this way keep their DNS settings, but connected products such as websites and email don’t move with them, and the domain can’t be transferred to another registrar for 10 days afterward. At Namecheap the equivalent is Change Ownership on the Sharing & Transfer tab. That change is final and can’t be reversed, and expired domains can’t be moved between accounts.
Create the destination account first. Set up a registrar account owned by the client, with a shared role-based email address, so the domain lands somewhere safe.
Consider a goodwill payment. A modest, documented payment for a few minutes of work is often cheaper than any escalation. Get a written confirmation of the handover in exchange.

Step 3: Registrar Account Recovery

If the developer is unreachable or hostile, use the registrar’s formal process. These processes verify identity and registrant status before acting.

GoDaddy

GoDaddy’s Account Recovery has a Domain Access path for people who are listed as the registrant on a domain but can’t get into the account that holds it.

Submit an Account Recovery request and choose the Domain Access option.
Upload a color copy of government-issued photo ID for the person making the request.
Provide business documentation if a company is listed on the account.

This path assumes the client’s company or authorized person is the registrant of record. If the developer is the registrant, it won’t help, and you are in a dispute rather than a recovery.

Namecheap

Namecheap’s built-in tools, Change Ownership and Share Access, can only be used by someone who can already log in to the owning account. Without access, you will be working through Namecheap Support. Open a ticket with your registrant-of-record evidence, invoices, and company identification. Don’t assume the registrar will override an account holder on request. Many registrars treat the registrant of record as authoritative and won’t move a domain without the registrant’s consent.

Other registrars

Many registrars publish their own account-recovery or domain-dispute procedures. Look for them early, and expect identity verification before anything is released.

Registrar recovery staff are also a social-engineering target, so keep your documents consistent and your story simple. Mismatched company names and informal evidence slow these requests down.

Step 4: Formal Escalation: ICANN, UDRP, and the Courts

If the developer is holding the domain for ransom, or the registrar won’t act, you are in legal territory. Set expectations realistically.

ICANN Contractual Compliance: ICANN accepts complaints about registrars and registries, including registration-data issues. It states plainly that it has no contractual authority or technical ability to return a lost domain name to you. It enforces contracts on registrars and registries, not on registrants. A complaint is a pressure point if a registrar is breaching its obligations. It is not a recovery mechanism.
UDRP (Uniform Domain-Name Dispute-Resolution Policy): The UDRP is built for cybersquatting. WIPO says a complainant must prove three things: rights in a trademark, no rights or legitimate interests for the registrant, and registration and use in bad faith. A single-panelist case covering one to five domains costs USD 1,500 in WIPO fees, and practitioner guides put standard timelines at roughly 45 to 60 days. The main problem is fit. Panels have repeatedly dismissed cases where a developer or former partner registered a name on a company’s behalf, because those are contractual disputes rather than cybersquatting. One National Arbitration Forum panel, in a case where a web developer had registered the domain, called it a contractual business dispute outside the scope of the UDRP. Don’t assume the UDRP is your fallback.
Court action: A contractual dispute over who must hand over a domain is generally a matter for the courts, and panels have said so in terms. Talk to an attorney about your options, such as a demand letter or a court order directed at the registrant or registrar.

3. Agency Operations: How to Institutionalize Prevention

Waiting for a client to hit an orphaned-registrar crisis is an operational failure. Professional agencies treat domains as client-owned corporate assets, not configuration settings.

The Golden Rule: Never Register a Client Domain in a Personal Account

Never let a developer or freelancer register a client’s core domain with their personal email and card.
Be deliberate about holding domains in your agency’s registrar account. If you do it as a managed service, put it in a written agreement covering ownership, billing, and handover. Even then, name the client as registrant and keep the handover path documented.

The “Client-Owned Core” Blueprint

Every client onboarding should include a Domain Provisioning Protocol:

Create a client-owned registrar account. Use a role-based address such as domains@clientbrand.com that more than one person can access, and set the client’s legal entity as registrant. Any reputable registrar can work. Check the trade-offs first. Cloudflare Registrar, for example, sells domains at cost, but domains registered there must use Cloudflare DNS, so you can’t point them at Route 53 or another external DNS provider.
Enforce strong multi-factor authentication. Prefer authenticator apps or hardware security keys over SMS, which is exposed to SIM-swapping and number reassignment. Check what your registrar supports. Namecheap, for instance, supports authenticator apps and FIDO/WebAuthn devices, but only one 2FA method can be active at a time. Make sure more than one person at the client can complete the challenge, and store recovery codes in a shared password manager.
Give the agency access through delegation, not shared passwords.
- GoDaddy: Delegate Access lets the owner invite your agency without sharing passwords, and delegates can’t see payment methods or passwords. Access levels include Products & Domains and Domains Only. Folder permissions can limit which domains a delegate sees.
- Namecheap: Share Access lets a domain owner delegate selected settings, such as DNS management, to another Namecheap user. Only the domain owner can grant it, and it doesn’t cover SSL services.
- Cloudflare: Invite agency staff as account members with scoped permissions rather than sharing the owner login.
- Other registrars: If delegation isn’t offered, say so in the contract and agree a documented process for DNS changes.
Keep billing with the client. The client’s card, not a freelancer’s, should pay renewals.

4. The Agency Audit Checklist

If you manage dozens or hundreds of client sites, do you know who controls each domain? Run this audit now.

Audit Step	Action Item	Priority	Status
1. Inventory	Cross-reference every active hosting client against a list of domains, registrars, and account owners.	Critical	[ ] Pending
2. Registrant check	Confirm the registrant of record is the client’s legal entity, not an employee or former vendor. Check RDAP, and ask the registrar where data is redacted.	Critical	[ ] Pending
3. Account ownership	Confirm the account is client-owned, with a role-based email that reaches a monitored shared mailbox.	Critical	[ ] Pending
4. MFA and recovery	Verify MFA is active, at least two named people can complete it, and recovery codes are stored in a shared vault.	High	[ ] Pending
5. Lock and notices	Confirm the registrar transfer lock is on and that renewal and security notices reach a monitored inbox.	High	[ ] Pending
6. Billing	Confirm the client’s card, not an expired freelancer card, pays for auto-renewals.	High	[ ] Pending

A note on transfer codes. It is tempting to archive transfer authorization codes “just in case,” but ICANN’s revised policy makes that pointless. A TAC is generated on request, works once, and expires (14 days is the standard maximum). Store the access you need to generate a fresh one instead.

5. Crafting the Offboarding Protocol

Orphans are also created when an agency or freelancer leaves. Offboarding needs the same discipline as onboarding.

The Domain Handover Checklist

Written confirmation of control. Confirm that the registrar account, the registrant record, and the billing method are in the client’s hands. Check what moves with a domain and what doesn’t. A GoDaddy account transfer keeps DNS settings but not connected products such as websites and email. At Namecheap, not all domain-related services move automatically, and an SSL certificate push requires contacting support.
DNS zone export. Give the client a current copy of the DNS zone records, along with details of the DNS host and any certificate issuance accounts.
Revocation of agency access. Once the client confirms control, remove your delegate access, collaborator accounts, and any API tokens.
Client sign-off. Get a signed receipt confirming the client has logged in independently and can reach the registrar dashboard.

Conclusion: Take Control Before the Crisis Takes You

The orphaned-registrar crisis is preventable. It grows out of informal agreements, personal accounts, and the assumption that nothing will go wrong. Audit the registrant and account owner for every client domain, move critical domains into client-owned accounts with strong MFA, use delegation instead of shared passwords, and document the handover when you leave.

Don’t wait for the 2:00 AM call. Audit your domains, lock down access, and make sure your clients own the address their business runs on.

FAQs

Q: Can ICANN force a registrar to hand over an orphaned domain?

A: No. ICANN says it has no contractual authority or technical ability to return a lost domain name. Its Contractual Compliance team enforces ICANN’s contracts against registrars and registries, not against registrants. UDRP cases are decided by independent providers such as WIPO, not by ICANN.

Q: Is the person listed as registrant the legal owner of the domain?

A: Registrars and ICANN-based policies generally treat the registrant of record as the holder. That is why checking and correcting the registrant record matters. Contracts and court rulings can still change the outcome, so the registration record is strong evidence but not the final word.

Q: What if the original developer’s email address no longer exists?

A: If the client is the registrant, use the registrar’s account-recovery process. At GoDaddy, that means the Domain Access option, ID for the authorized person, and business documentation if a company is listed. Timelines vary by registrar, so start early and keep a log of every submission.

Q: Should agencies hold client domains in the agency’s registrar account as a retention strategy?

A: No. Using a client’s domain as leverage damages trust and can expose your agency to legal claims. Developers who hold names as leverage in disputes often end up in court rather than winning. If you do hold domains as a managed service, make the client the registrant and document the handover terms in your contract.

Originally published at https://instarenewal.com/blog/the-orphaned-registrar-crisis-how-to-recover-domain-control-when-the-original

The Multi-Registrar Disconnect: Why Consolidating Client Domains Is a Core Agency Risk Strategy

Memo — Sun, 11 Oct 2026 01:58:27 +0000

As digital marketing, design, and development agencies grow, they inherit a messy digital footprint. A client’s primary domain sits in one registrar account, a legacy blog is parked in another, DNS is managed in a third, and campaign domains are registered under whichever login (or personal credit card) was handy that week.

At a glance, this feels harmless. The domain “points where it needs to point.” But across dozens or hundreds of client accounts, registrar sprawl creates visibility gaps, widens the security surface, and raises the odds of a missed renewal. Consolidating domains under a single, documented, access-controlled setup is one of the more practical risk reductions an agency can make. It also has its own risks, which this guide covers.

1. How Agency Domain Fragmentation Happens

Fragmentation is rarely a decision. It accumulates:

A developer registers a staging or campaign domain on a personal account because it is the fastest option.
A previous agency bought a client’s exact-match domain years ago, and nobody has the login.
The client’s internal IT team manages DNS in one provider while email records live somewhere else.
Acquisitions and client transfers bring in accounts nobody on the current team set up.

Two details are worth separating when you count your “registrars”:

Registrar, DNS host, and web host are different roles. Cloudflare is often just the DNS and CDN layer for a domain registered elsewhere. Hosting companies such as Bluehost also sell domain registrations, which can leave a domain registered inside a hosting account.
Brands are not always separate companies. Newfold Digital, formed in 2021 from Endurance International Group and Web.com, owns Bluehost, HostGator, Network Solutions, Register.com, and Domain.com. Your “five registrars” may be fewer corporate relationships, but each brand still has its own account, billing, and login.

The practical result of fragmentation:

Scattered billing: Auto-renewals hit a mix of corporate and personal cards, which makes expense tracking and client pass-through billing difficult.
Slow access: Account managers lose hours finding out who holds the login or 2FA device when an urgent DNS change is needed.
No single view: Nobody has one place to see expiry dates, lock status, and which contact email receives notices.

2. The Danger Zones

A. The Missed Renewal

The most immediate risk is a missed renewal. Under ICANN’s Expired Registration Recovery Policy (ERRP), registrars must send at least two expiry notices to the registrant, roughly one month and one week before expiration. They must also send another within five days after expiry if the domain isn’t renewed. Those notices go to the registrant contact email on file, which in a fragmented setup is often a former employee, a retired agency mailbox, or a client who assumes the agency is handling it.

What happens next depends on the registrar and TLD, but the typical gTLD lifecycle looks like this:

Expiry and possible auto-renew grace. Registrars that don’t delete a name right away may offer an auto-renew grace period of 1 to 45 days, set by the registrar. Under ERRP, the domain’s DNS must be interrupted for at least the last eight days before deletion, so websites and email can go down before the domain is gone.
Redemption Grace Period. gTLD registries must offer a 30-day Redemption Grace Period after deletion. The registrant can still restore the name, but redemption fees are typically well above a normal renewal, and DNS is disabled during this window.
Pending delete. After redemption, there is a final five-day pending-delete period, and then the name is released for anyone to register. Automated drop-catching services compete to grab valuable names the moment they drop.

Losing a client’s domain is a serious relationship failure. The search impact is real but more nuanced than “wiped out overnight.” Downtime and broken links hurt immediately. If a third party re-registers the name, Google has said expired domains don’t keep their old link equity, so the client doesn’t simply get their rankings back later. Treat any lapse as a recovery project, and treat prevention as the goal.

B. Credential Sprawl and Weak Access Control

Third-party risk is now a leading breach pathway. Verizon’s 2026 Data Breach Investigations Report found third-party involvement in 48% of breaches, up 60% from the prior year, after doubling to 30% in the 2025 edition. Agencies sit in exactly that position, holding access to many clients’ domains, DNS, and hosting. (The same report found that exploiting vulnerabilities overtook credential abuse as the top initial access vector, so stolen credentials are not the only path in.)

Where registrar sprawl makes this worse:

Shared logins and weak hygiene. Legacy accounts often rely on shared credentials in spreadsheets or chat threads.
Offboarding gaps. When a freelancer or employee leaves, auditing access across five or ten registrar dashboards is slow and easy to skip.
Uneven MFA. Registrars differ widely in MFA options, role-based access, and support for security keys or passkeys, so your weakest account sets your real security level.
Account takeover at the registrar. Attackers target registrar accounts and support channels because control of a domain means control of its website, email, and verification emails.

A recent case shows how this plays out, including during migrations. In July 2024, at least a dozen organizations, mostly in crypto, had domains hijacked at Squarespace. Squarespace had acquired Google Domains in 2023 and was migrating roughly 10 million domains. According to researchers at Metamask and Paradigm, attackers found they could take over migrated accounts that hadn’t yet been claimed by registering with an email address tied to the domain. The lesson for consolidation projects: claim and lock down every new account immediately, with MFA on from day one.

C. Registrars Change Hands

Registrars and registrar brands get bought, merged, and migrated, sometimes forcing your hand. Google Domains’ customers were moved to Squarespace. In December 2025, Newfold Digital closed the sale of Markmonitor, an enterprise corporate registrar, to Com Laude; the combined company now operates as Markmonitor Group. Domain Name Wire noted this was the fifth time Markmonitor had changed hands in a decade. Corporate changes can mean new account systems, new terms, and notices that go to old addresses. An agency with a single documented inventory can respond to those changes. One with domains scattered across a dozen logins often discovers them too late.

D. Visibility Gaps for Monitoring

Uptime, SSL, and security tools work best against a known list of domains. If a staging or campaign domain sits in an account nobody remembers, it won’t be on the list. An expired certificate or lapsed domain there can still produce browser warnings that reflect on the client. Note that public WHOIS data is now largely redacted, and ICANN ended the requirement to run legacy WHOIS services on January 28, 2025, making RDAP the standard. Ownership usually has to be confirmed inside registrar accounts rather than through public lookups.

3. The Business Case for Centralized Management

Consolidating client domains into one managed, documented structure converts a reactive liability into something your team can govern:

A single source of truth. Expiry dates, DNS ownership, registrant and notice contacts, and lock status live in one inventory instead of ten dashboards.
Role-based access. Platforms and registrars that support roles let developers, account managers, and copywriters work with only the permissions they need, without sharing a master login.
Cleaner diligence. For an acquisition, a security questionnaire, or an SOC 2 or ISO 27001 effort, documented asset ownership helps. Neither certification legally requires domain consolidation, but both reward evidence that you know what you manage and who can access it.
Pricing visibility. Verisign, the .com registry operator, is raising its wholesale .com fee from $10.26 to $10.97 on November 1, 2026. Registrars set their own retail prices, and teaser first-year rates commonly give way to higher renewals, so compare renewal pricing, not only the first-year price.

One honest caveat: consolidation concentrates risk. A single compromised registrar account is now a bigger problem, which is why the security controls in Phase 2 below matter as much as the migration itself.

4. A Step-by-Step Framework for Consolidating Client Domains

Phase 1: Discovery and Audit

Before moving anything, build an inventory.

Collect from every source. Pull domain lists from registrar accounts, DNS provider exports, hosting accounts, client contracts, and billing records. Because public WHOIS is largely redacted, confirm ownership by logging in rather than relying on lookups.
Record key attributes for every domain:
- Registrar and account owner
- Registrant name and organization
- Expiration date and auto-renew status
- DNS provider and nameservers
- Registrant and notice contact emails
- Payment method and who is billed
- Dependent services (website, email MX, subdomains, third-party verifications)
Decide ownership deliberately. Under ICANN policy, the registrant (registered name holder) is the party who controls the domain and receives renewal notices. Where possible, keep the client as registrant and give the agency delegated access, rather than registering client domains in the agency’s own name. That avoids ownership disputes if the relationship ends.

Phase 2: Choose a Destination and Set Security Standards

Evaluate candidates against a written checklist:

Pricing transparency. Look at renewal and transfer pricing, not just the first-year price. Cloudflare Registrar, for example, charges at-cost registry pricing without markup.
TLD coverage. Confirm that every TLD you manage is supported, including country-code domains, which follow their own registry rules. Cloudflare supports over 390 TLDs, so some of your domains may not qualify.
DNS requirements. Cloudflare Registrar requires domains to use Cloudflare’s nameservers, and you can’t use another DNS provider while registered there. If your clients’ DNS must live elsewhere, that is a dealbreaker for that registrar.
Access controls. Look for role-based access, MFA (ideally phishing-resistant security keys or passkeys), and clear audit trails. Ask the vendor directly, because support varies.
Registry lock. For high-value domains, ask about Registry Lock. For .com, .net, .cc, and .name, Verisign offers it through participating registrars. Changes require out-of-band verification between the registrar and registry, which helps even if the registrar account itself is compromised. Availability and pricing vary by registrar, and not every domain needs it.
Privacy and registrant data handling. Free redaction is common, but not every TLD allows privacy services.
Enterprise options. Corporate registrars such as Markmonitor and CSC are built for large brand portfolios, and may be more than a typical agency client needs.

Ask about the vendor’s ownership and stability too. Registrar M&A has caught customers off guard.

Phase 3: Migrate Safely

Never start a bulk transfer without a plan.

Back up DNS first. Export every zone record (A, AAAA, CNAME, MX, TXT, SRV, CAA) from the current DNS host. A registrar transfer does not move DNS by itself, but a DNS provider change can.
Check for transfer blockers. A registrar may deny a gTLD transfer within 60 days of initial registration or a previous inter-registrar transfer. A material change to registrant information can also trigger a 60-day lock, unless an opt-out was available at the time. Cloudflare’s documentation notes this directly. Don’t change the registrant (for example, moving ownership from agency to client) right before you plan to transfer. ccTLDs follow their own rules; Cloudflare notes, for example, that .uk transfers aren’t subject to the 60-day rule and don’t add a year.
Verify the contacts on file. ICANN’s registrant verification process requires registrars to verify contact email addresses after registration or certain changes, and domains can be suspended if verification isn’t completed. Make sure the registrant email is reachable before you start.
Unlock the domain and request the transfer code. Disable the registrar lock and request the authorization code (older guides call it an EPP or auth code; many registrars now call it a Transfer Authorization Code, or TAC). Codes are issued on request and expire, usually within a week or two depending on the registrar, so request it right before you start.
Initiate the transfer at the destination. Enter the code and approve any confirmation emails. Under ICANN’s policy, the losing registrar has a five-day window, and many transfers finish sooner once approved. A gTLD transfer typically adds one year to the registration.
Handle DNS correctly for the destination. For most registrars, keep existing nameservers in place during the transfer so nothing changes for live traffic. Cloudflare Registrar is the exception: the domain must first be active on Cloudflare DNS (a full setup with your records verified), and DNSSEC at the old registrar must be disabled before you change nameservers.
Verify, then lock. After the transfer, test the website, email delivery, and any third-party verification records. Turn on the transfer lock, confirm MFA is enabled, and review who has access.

For consolidation at scale, migrate low-risk domains first, then critical ones during a quiet window. Claim and secure each new account before the first transfer, per the Squarespace lesson above.

Phase 4: Ongoing Governance

Consolidation holds only if the rules do:

A no-personal-accounts policy. No new client domain is registered on a personal account or an unapproved registrar. All purchases follow one procurement path.
Notice routing. Point registrant and billing contacts at monitored role-based mailboxes (not individuals), and confirm clients forward or acknowledge them.
Alerts earlier than the minimums. Registrars are only required to send reminders about a month and a week before expiry. Set your own reminders at 90, 60, and 30 days, and assign an owner to each renewal.
Quarterly access reviews. Review who can log in to the registrar, DNS, and hosting accounts, and remove departed staff and finished contractors.
Offboarding checklist. Include registrar and DNS access, MFA devices, and shared credentials in every employee and contractor exit.
Pre-agreed contract terms. State in client agreements who owns the domain, who pays for renewal, and what happens at termination.

Conclusion: Take Control Before a Lapse Takes It for You

Managing client domains across a dozen accounts is a quiet risk that most agencies ignore until something expires or someone’s access is abused. Consolidation won’t remove risk, but it replaces guesswork with a single inventory, tighter access, and predictable renewals. Done carefully, with locks, MFA, and clear ownership, it protects both your clients’ digital assets and your own reputation.

Ready to audit your agency’s domain footprint? Start by building a master inventory of every domain, its registrar, its registrant, and its renewal date, and use it to decide what to consolidate first.

Originally published at https://instarenewal.com/blog/the-multi-registrar-disconnect-why-consolidating-client-domains-is-a-core

The “Who Pays?” Bottleneck: How to Design a Clear Client Payment Approval Workflow Before Renewals Break

Memo — Sat, 10 Oct 2026 04:28:28 +0000

Most agencies, web development firms, and managed service providers (MSPs) that look after client infrastructure eventually face a version of this emergency.

It is 8:30 AM on a Tuesday. A high-value client’s e-commerce site is unreachable. Checkout fails, support lines light up, and the client’s CMO calls your Account Director. After a frantic investigation, your team finds the root cause: the primary domain or hosting plan lapsed because the renewal payment never went through.

The card on file in your agency portal was declined after the bank reissued it. Or a Purchase Order (PO) hit its spending cap, and the client’s Procurement team had not approved a new one.

As agencies scale, the technical estate (domains, DNS, hosting, SSL/TLS certificates, third-party API keys, SaaS subscriptions, and plugin licenses) outgrows the administrative systems that pay for it. What is a minor annoyance in a boutique studio becomes a serious point of failure at 50 or 100 client accounts.

This guide covers why the “Who Pays?” bottleneck happens, how to audit your renewal exposure, and how to build a payment approval workflow that protects your clients’ uptime and your cash flow.

First, Know What Actually Breaks When a Renewal Lapses

Not every lapsed renewal has the same blast radius, and your escalation rules should reflect that.

Domain names: ICANN’s Expired Registration Recovery Policy (ERRP) requires registrars to send two reminders before expiry, one roughly a month out and one roughly a week out. Registrars must also send a notice after expiry. After deletion, gTLD registrations get a 30-day Redemption Grace Period, during which DNS resolution is disabled. Those reminders go to the registrant contact on file, which is often not the person who controls the budget. Many agencies only learn a domain lapsed when the site goes dark. (Policy details: ICANN ERRP.)
Hosting and cloud accounts: Behavior varies by provider, but non-payment can lead to suspension. Read each vendor’s terms and grace periods in advance, and do not assume a lapse is recoverable.
Premium plugin licenses: These usually degrade more gently. Gravity Forms, for example, states that after a license expires the plugin stays installed and keeps operating, but you lose updates (including security fixes), support, and access to downloads. The vendor also warns that an outdated install may eventually break as WordPress and integrations change. (Gravity Forms documentation.) Other vendors differ, so check each one.
SSL/TLS certificates: Expiry causes browser warnings and can block traffic. Validity periods are also shrinking. Under CA/Browser Forum Ballot SC-081v3, the maximum lifetime of publicly trusted certificates dropped to 200 days on March 15, 2026. It falls to 100 days on March 15, 2027, and 47 days on March 15, 2029. Paid certificates will therefore generate more renewal events each year, so automated issuance and renewal (for example ACME) matters more.

The Root Causes of the “Who Pays?” Bottleneck

Renewal breakdowns rarely stem from a client refusing to pay. They usually come from operational friction, ambiguous roles, and mismatched billing models.

       ┌────────────────────────────────────────────────────────┐
       │               RENEWAL APPROVAL BOTTLENECK              │
       └───────────────────────────┬────────────────────────────┘
                                   │
         ┌─────────────────────────┼─────────────────────────┐
         ▼                         ▼                         ▼
┌─────────────────┐       ┌─────────────────┐       ┌─────────────────┐
│ Administrative  │       │ Financial &     │       │ Technical &     │
│ Friction        │       │ Contractual     │       │ Structural      │
└────────┬────────┘       └────────┬────────┘       └────────┬────────┘
         │                         │                         │
 ├─ Wrong stakeholder       ├─ Card failures          ├─ Shared agency cards
 ├─ "Silent approvers"      ├─ PO cap exceeded        ├─ Rogue direct billing
 └─ Unread reminders        └─ Unclear SOW markup     └─ Fragmented vendors

1. Administrative and Stakeholder Ambiguity

The single point of contact (SPOC) trap: Agencies default to their day-to-day contact, often a Marketing Manager, Product Owner, or Creative Director. That person usually lacks purchasing authority for infrastructure overhead. A renewal notice lands in their inbox and gets buried under project deliverables.
The “silent approver” problem: In mid-market and enterprise accounts, payments typically route through Accounts Payable (AP), Procurement, or a CFO. Without a defined payment pathway, invoices sit in limbo while project managers assume no news is good news.
Slow payment is the norm, not the exception: Atradius’s 2025 survey of US companies reported average B2B payment terms of 45 days, with 43% of invoice value overdue. (summary of the Atradius data.) Intrum’s 2026 European Payment Report found B2B suppliers typically grant 43 days to pay but wait about 63 days, a 20-day gap. (coverage of the Intrum report.) If your renewal request goes out 30 days before expiry, you are planning to fail.

2. Financial and Contractual Friction

Card expirations and silent failures: Cards expire, hit limits, or get reissued after fraud blocks. Stripe cites a 2023 study attributing about half of subscriber churn to failed payments, with expired cards a contributing cause. Card-network updater services (Visa Account Updater and Mastercard Automatic Billing Updater) can refresh stored card details automatically. They are available through processors such as Stripe, but they don’t cover every card. Prepaid cards, for example, are excluded. (Stripe on expired cards.)
PO caps and fiscal-year mismatches: Enterprise clients often require POs. If an annual fee rises, or consumption-based cloud usage (AWS, GCP, Vercel) overshoots the budget, the invoice may be rejected or held until a new or amended PO is issued.

3. Technical and Structural Misalignment

The agency credit card proxy risk: Many agencies float third-party costs on their own corporate cards and rebill the client later. If the client disputes a charge or pays late, the agency either absorbs the cost or risks cutting off a live environment.
Disjointed multi-vendor assets: A modern site depends on many separate renewals: domains, DNS, certificates, managed hosting, headless CMS plans, web application firewalls (WAF), and premium plugins. Each has its own billing owner, notice email, and grace behavior. A lapse in one, especially a domain or hosting plan, can take a site or email offline.

Auditing Your Agency’s Renewal Exposure

Before building a workflow, map your current exposure. For every client asset, record who uses it, who approves its spend, and how it is paid. The table below is an illustrative example. The lead times are suggested internal targets, not vendor requirements.

Asset Category	Example Vendors	Day-to-Day Contact	Financial Approver	Payment Method	Suggested Internal Lead Time	Failure Impact
Domain name	Namecheap / Route 53	Brand Manager	Procurement Lead	Client credit card	60 days	Critical (site and email down)
Hosting / cloud	WP Engine / AWS	Dev Lead	Accounts Payable	Agency direct bill	45 days	Critical (site down; suspension risk)
Premium plugins	Gravity Forms and similar	Tech Director	Marketing Director	Agency card (rebilled)	30 days	Moderate (updates and support lost; security patch exposure)
Security / WAF	Cloudflare Enterprise	IT Director	VP of Finance	Annual PO	90 days	High (protection lapses; contract-dependent)

Key Questions for Your Operational Audit

Financial ownership: Does your agency own the infrastructure account and rebill the client, or does the client own it with your team holding admin access?
Notice routing: Whose email address receives the vendor’s expiry and failed-payment notices? Is it a monitored shared mailbox or a former employee’s inbox?
Approval triggers: At what dollar amount does a renewal require formal client authorization instead of auto-approval?
Escalation windows: How many days before expiry does your team escalate unapproved renewals to executive leadership?
Grace behavior: For each vendor, what happens on day 1, day 7, and day 30 after a missed payment?

The 4-Stage Client Payment Approval Workflow

To prevent interruptions, replace informal email threads with a standardized, rule-based pipeline. The timings below are a recommended framework. Adjust them to your clients’ payment terms and each vendor’s rules.

 T-90            T-60              T-30              T-7             T-0
  │               │                 │                 │               │
  ▼               ▼                 ▼                 ▼               ▼
Stage 1        Stage 2           Stage 3           Stage 4         Renewal
Discovery  ──> Routing &     ──> Settlement &  ──>  Vendor pay,  ──> date
& review       approval          escalation         verify, log
               (approve by       (payment due
                T-45)             T-30)

Stage 1: Discovery and Review (T-90 to T-60)

Never launch a renewal request in the month it is due. Typical B2B terms run 30 to 60 days, and invoices are frequently paid later than their terms.

Maintain a central asset inventory. Use a spreadsheet, a professional services automation (PSA) or project tool, a CRM, or a dedicated renewal tracker. It should list every domain, host, certificate, plugin, and license tied to each client, with the renewal date, the cost, who pays, and where vendor notices go.
Run a pre-renewal margin check. Compare vendor price changes against what you charge. If a vendor raised prices, update your markup or retainer terms before the client sees the invoice.
Set an early-warning alert at T-90. Account Managers should review upcoming renewals before any client communication goes out.

Stage 2: Dual-Stakeholder Routing and Authorization (T-60 to T-30)

Renewals most often stall because the billing request reaches the wrong person. A dual-stakeholder model sends two different messages to two different people at the same time.

                  ┌───────────────────────────────┐
                  │     STAGE 1: REVIEW COMPLETE  │
                  └───────────────┬───────────────┘
                                  │
                                  ▼
                  ┌───────────────────────────────┐
                  │  RENEWAL REQUEST (at T-60)    │
                  └───────────────┬───────────────┘
                                  │
             ┌────────────────────┴────────────────────┐
             ▼                                         ▼
┌─────────────────────────┐               ┌─────────────────────────┐
│  Day-to-Day Contact     │               │  Financial Approver     │
│  (Marketing / Product)  │               │  (AP / Procurement /CFO)│
├─────────────────────────┤               ├─────────────────────────┤
│ • Scope and necessity   │               │ • Invoice and/or PO     │
│ • Usage review          │               │ • Payment link / method │
│ • Plan / upgrade check  │               │ • Terms and due date    │
└────────────┬────────────┘               └────────────┬────────────┘
             │                                         │
             └────────────────────┬────────────────────┘
                                  ▼
                  ┌───────────────────────────────┐
                  │   CLIENT APPROVAL GRANTED     │
                  └───────────────────────────────┘

Communication protocols

To the day-to-day contact: Send a scope summary. For example: “We are renewing your hosting and security services for the upcoming term. Below is the confirmation of what is included, current plan usage, and any recommended changes.”
To the financial approver: Send an actionable billing request with the invoice number, amount, due date, PO reference if applicable, and secure payment options.

Key rules for this stage

Require dual sign-off. The day-to-day contact approves scope and necessity. The financial approver approves budget and payment.
State deadlines and consequences. For example: “To guarantee uninterrupted availability, authorization must be received by [T-45 date] and payment must be received by [T-30 date].”

Stage 3: Pre-Pay Settlement and Escalation (T-30 to T-7)

To protect cash flow, follow a pre-pay principle: do not pay a third-party vendor on a client’s behalf until the client’s payment has settled.

Encourage a reliable payment method on file. Options include ACH debit, a card via Stripe or another processor, or a pre-approved recurring PO.
Know the payment-method timing. Stripe says ACH Direct Debit can take up to four business days to confirm success or failure. Under Stripe’s ACH terms, unauthorized-debit returns can be requested within 60 days on consumer accounts and 2 days on business accounts. (Stripe ACH docs, Stripe ACH terms.) Define “settled” in your policy and build that buffer into your deadlines.
Handle PO requirements explicitly. If a client pays by PO, pay the vendor only after AP issues a confirmed, funded PO.
Retry failures on a schedule that fits your calendar. Stripe’s recommended Smart Retries default is up to 8 attempts within 2 weeks, configurable from one week to two months. (Stripe docs.) A two-week retry cycle can consume most of a short buffer, so start billing at T-30, not T-7.
Escalate on a fixed ladder when payment has not arrived:
- T-21: Send a reminder to both the day-to-day contact and the financial approver.
- T-14: Send an urgent notice to both, copying the client sponsor.
- T-7: The Account Director phones the client sponsor. The technical team prepares contingency steps based on each vendor’s grace and reinstatement rules.
- T-3: Send a formal notice of service-suspension risk to client executive leadership.

Consider a break-glass rule for critical assets. Pre-pay discipline can collide with a hard expiry date. Decide in advance, in writing and in your contract, whether the agency may front the cost of a critical renewal (such as a domain or primary hosting plan) up to a set dollar cap and rebill it. The decision then happens in your contract instead of at 11 PM the night before expiry.

Stage 4: Vendor Execution, Verification, and Archival (T-7 to T-0)

Once funds clear and authorization is complete, execute the renewal with the vendor.

Execute the vendor payment in the vendor’s admin dashboard, or confirm the auto-renewal charge succeeded.
Verify the result. Check the domain expiry date, certificate validity, and hosting plan status to confirm the renewal registered.
Update your records. Log the transaction, attach the vendor receipt to the client’s billing history, and reset the renewal reminder for the next cycle.

Technical Architecture for Automation

Connect your asset tracker, billing system, and payment processor so renewals trigger the workflow automatically.

[ Asset tracker / CRM ] ──(trigger at T-60)──> [ Invoice / automation engine ]
                                                        │
                                   ┌────────────────────┴────────────────────┐
                                   ▼                                         ▼
                       [ Send scope summary ]                    [ Send payment request ]
                       To: day-to-day contact                    To: financial approver
                                   │                                         │
                                   └────────────────────┬────────────────────┘
                                                        ▼
                                            [ Payment gateway / portal ]
                                                        │
                                       ┌────────────────┴────────────────┐
                                       ▼                                 ▼
                                [ Payment success ]              [ Payment failure ]
                                       │                                 │
                                       ▼                                 ▼
                             • Pay vendor                       • Alert Account Manager
                             • Sync accounting                  • Retry and re-notify
                             • Log audit trail                  • Start escalation ladder

Automation best practices

Use triggers and webhooks. Tools such as Zapier, Make, or custom API endpoints can watch renewal dates in your tracker and draft invoices in QuickBooks, Xero, or Stripe Billing. Stripe also emits an invoice.payment_failed event you can use to start escalation automatically.
Offer a client billing portal. Let clients update payment methods, view upcoming charges, and download invoices without emailing your finance team.
Turn on card updater and retries. Enable your processor’s card account updater where available. Align retry windows with your timeline instead of using defaults blindly.
Keep notice routing under your control. Where a vendor account is agency-managed, send expiry and failed-payment emails to a monitored shared mailbox, not an individual’s inbox.

Contractual Frameworks to Protect Your Agency

A workflow is only as strong as the contracts behind it. Update your Master Services Agreement (MSA) and Statements of Work (SOW) with explicit language on third-party renewals and financial responsibility.

The sample language below is a starting point, not legal advice. Enforceability of liability limits, late fees, and reinstatement charges varies by jurisdiction. Have a qualified attorney review any clause before use.

Essential MSA Clauses

1. Third-Party Infrastructure Liability

“Agency acts as an administrative facilitator for third-party hosting, software licenses, domains, and security services. To the maximum extent permitted by law, Agency shall not be liable for website downtime, loss of revenue, or service disruptions resulting from delayed Client payment approvals, failed payment methods, or unpaid vendor renewal invoices.”

2. Advance Funding and Pre-Payment

“All third-party infrastructure fees, including annual hosting, software subscriptions, and domain renewals, must be paid in full by Client at least thirty (30) days before the vendor renewal date. Agency may withhold vendor payment until funds have cleared Client’s account, except as provided in the Critical Asset Bridge Payment clause.”

3. Critical Asset Bridge Payment (Optional)

“For assets designated Critical in the applicable SOW, Agency may, at its discretion, advance payment up to $[cap] per renewal to prevent service interruption. Client shall reimburse Agency within [X] days of invoice.”

4. Billing and Notice Contacts

“Client shall maintain current billing and notice contacts, including a designated financial approver, and shall notify Agency of changes within [X] business days.”

5. Late Fees and Reinstatement Charges

“Invoices overdue by more than fifteen (15) calendar days shall accrue a late fee of 1.5% per month, or the maximum rate permitted by applicable law, whichever is less. If a service is suspended for non-payment, Client shall pay a reinstatement fee of $[amount] before reactivation.”

Two notes on this clause. First, no federal cap applies to late fees on ordinary business invoices. Limits come from state usury and contract law and vary widely, which is why the “whichever is less” wording matters. Second, a rate of 1.5% per month (about 18% a year) is a common market rate, but confirm it against your state’s rules. Set any flat reinstatement fee to reflect your real administrative cost rather than an arbitrary figure.

Strategic Alternatives: Direct Billing vs. Agency Reselling

Choose the financial model that fits your operational capacity and risk tolerance.

┌──────────────────────────────────────────────────────────────────────────────────┐
│                          DIRECT BILLING vs. RESELLING                            │
└──────────────────────────────────────────────────────────────────────────────────┘

        DIRECT CLIENT BILLING                      AGENCY RESELLING / REBILLING
┌──────────────────────────────────────┐        ┌──────────────────────────────────────┐
│ • Client owns the vendor account     │        │ • Agency pays vendor, rebills client │
│ • Little agency credit risk          │        │ • Can add recurring margin / MRR     │
│ • Client handles invoice approval    │        │ • Needs strict pre-payment rules     │
│ • Agency manages as admin only       │        │ • Exposed if payment fails or is     │
│                                      │        │   disputed                           │
└──────────────────────────────────────┘        └──────────────────────────────────────┘

Option A: The Direct-Billing Model (Lowest Risk)

How it works: The client creates the account (or owns the existing one) and enters their own payment method. Your agency keeps admin or developer access.
Pros: Minimal financial exposure for the agency. Card and PO problems sit with the client’s own teams. Ownership of the asset is also clear.
Cons: You give up markup on pass-through costs. You also still depend on the client to act, so downtime remains a risk to the relationship even if it is not your financial liability.

Option B: The Managed Reseller Model (Higher Margin)

How it works: The agency holds the vendor accounts (sometimes at partner or reseller pricing where the vendor offers it), bundles infrastructure with management services, and bills the client monthly or annually.
Pros: Predictable recurring revenue, one invoice for the client, and tighter control over renewal timing.
Cons: The agency carries the credit risk if the client pays late or disputes a charge. Ownership and transfer terms also need to be spelled out in the contract so the client’s assets are not held hostage in a dispute.

Operational Action Plan: Next Steps for Your Agency

Follow this rollout to eliminate the “Who Pays?” bottleneck.

Run an asset audit (Week 1). Map every domain, host, certificate, plugin, and license across active clients. Record expiration dates, costs, who pays, and where vendor notices go.
Identify approvers and payment methods (Week 2). Store two contacts per account, the day-to-day contact and the financial approver. Confirm the payment method on file and its expiry date.
Automate alert sequences (Week 3). Set reminders at T-90, T-60, and T-30 in your billing or workflow tool. Turn on card account updater and failed-payment webhooks where your processor offers them.
Update contracts (Week 4). Revise your MSA and SOW to cover pre-payment, bridge-payment rules for critical assets, notice contacts, late fees, and reinstatement charges. Have counsel review them.
Train account managers (Week 5). Make sure the team knows the escalation ladder, how to handle card declines and PO delays, and when the break-glass rule applies.

By defining roles, routing approvals to the right people early, and backing the process with clear contracts, you turn renewals from a recurring fire drill into a predictable part of your operations.

Sources and Further Reading

ICANN, Expired Registration Recovery Policy
Gravity Forms, License Expiry documentation
Stripe, Automate payment retries (Smart Retries)
Stripe, ACH Direct Debit payments and ACH Payment Terms
Stripe, Expired cards for recurring payments
CA/Browser Forum Ballot SC-081v3 timeline, as summarized by SSL Insights
Intrum 2026 European Payment Report, as covered by trans.info
Atradius US payment practices data, as summarized by Lonely Entrepreneur

Originally published at https://instarenewal.com/blog/the-who-pays-bottleneck-how-to-design-a-clear-client-payment-approval-workflow

Agency Renewal Operations: Preventing Drop-Offs, Automating Calendars, and Enforcing Zero-Trust Auto-Renewals

Memo — Fri, 09 Oct 2026 04:36:44 +0000

Digital agencies, managed service providers (MSPs), and IT consultants routinely manage dozens, sometimes hundreds, of client web assets. Among the daily pressure of client requests and feature deployments, renewal housekeeping can turn into a silent liability.

Domain names lapse, SSL/TLS certificates expire mid-campaign, and premium plugin licenses quietly deactivate. These failures rarely come from technical incompetence. They are almost always operational failures: renewal notices sent to the wrong inbox, reactive scheduling, and a habit of trusting an “Auto-Renew: ON” toggle without checking that it works.

This guide is an operational playbook for agencies. It covers three problems: renewal notices that never reach anyone, renewals handled as one-off emergencies, and auto-renew settings that are assumed to work but never verified.

1. The “Notice to Nowhere” Problem

Mapping Renewal Email Routing Across 50+ Client Accounts

The scenario is familiar. On a Tuesday morning, a client’s website stops resolving. The team investigates and finds that the domain expired and the registrar has taken it out of service. The client checks their inbox and finds nothing. The registrar did send reminders, but to an address belonging to an operations manager who left the company eighteen months ago.

This is the “Notice to Nowhere” problem. The notices existed, but nobody who could act on them ever read them.

What the Registrar Is Actually Required to Send

For generic top-level domains (gTLDs such as .com, .net and .org), ICANN’s Expired Registration Recovery Policy (ERRP) sets a floor for what registrars must do:

Two pre-expiration notices. One goes out approximately one month before expiration and one approximately one week before. ICANN treats the notices as compliant if they are sent 26 to 35 days and 4 to 10 days before expiration, respectively.
A post-expiration notice. At least one additional notice must go out within five days after expiration.
A Redemption Grace Period. gTLD registries (sponsored gTLDs excepted) must offer a 30-day Redemption Grace Period after a registration is deleted. During it the registrar can restore the domain, but DNS resolution is disabled and transfers are prohibited.

Two points matter for agencies. First, the policy governs gTLDs. Country-code TLDs set their own rules, and some have no redemption period at all. Second, the policy sets a minimum of notices, not a guarantee that anyone reads them. Every one of those notices goes to whatever email address is on file for the registrant.

The Domain Lifecycle After Expiration

The typical gTLD lifecycle runs as follows. Exact timing varies by registry and registrar, and many registrars use shorter windows than the maximums.

Stage	Typical duration	What it means
Auto-Renew Grace Period	Up to 45 days after expiry	The domain can usually be renewed at the standard price. The registrar may already have disabled or parked the site.
Redemption Grace Period	30 days	The registrar can restore the domain, usually for an extra fee. DNS is disabled and transfers are blocked.
Pending Delete	About 5 days	The domain can no longer be restored.
Released	After Pending Delete	The domain becomes available for anyone to register, and drop-catching services compete for valuable names.

The practical lesson is that the cheap, painless window is the one in which nobody has yet noticed the problem.

The Anatomy of Routing Failures

Agencies typically inherit client infrastructure spread across many registrars and hosts. The same four failure patterns recur:

Generic inbox black holes. Accounts registered to admin@, info@ or webmaster@ aliases often have no individual owner. When someone leaves or forwarding breaks, alerts pile up unread.
Ex-employee mailboxes. If a billing contact leaves and their mailbox is deactivated or archived, reminders vanish silently.
Spam filtering and quarantine. Automated billing notices contain links and transactional language that can trip enterprise spam filters.
Personal-account ownership. Clients often bought domains or hosting with a personal Gmail or Yahoo address before hiring the agency, which separates the account from any business workflow.

Why Looking Up Contacts Is Harder Than It Used to Be

Mapping routing starts with finding out where notices go. That has become harder:

WHOIS has been replaced by RDAP for gTLDs. ICANN announced that as of 28 January 2025, the Registration Data Access Protocol (RDAP) is the definitive source for gTLD registration data in place of the sunsetted WHOIS services.
Registrant contact data is mostly redacted. A public lookup typically returns the registrar, dates, nameservers and status codes, but not the registrant’s name or email. ICANN’s Registration Data Policy, which took effect on 21 August 2025, replaced the earlier GDPR-era Temporary Specification and sets the baseline for what gTLDs publish.
The reliable source is the account itself. To see what a registrar actually has on file, log into the registrar account or ask the registrar. For non-public gTLD data you do not control, ICANN points requesters to the Registration Data Request Service (RDRS) or the sponsoring registrar’s own disclosure process.

An RDAP lookup is still useful for a quick independent check of expiry date, registrar and status codes. It is not a way to discover who receives the reminders.

A Step-by-Step Mapping Protocol

Inventory every account. For each client, list the registrar, host and license vendor, which login owns it, and which email address receives its notices. Pull this from the account panels rather than from public lookups.
Create dedicated, monitored agency aliases. Use a distribution address such as renewals@youragency.com that reaches several people, so no single departure silences it.
Separate ownership from operational notices. Keep the client as the legal registrant, but add the agency alias as a notification or billing contact wherever the provider allows it. Where a provider offers only one email field, decide deliberately who receives it and record that decision.
Test delivery. Trigger a test notice where the provider allows it, or confirm with the provider that the contact on file is correct. Then check that messages are not landing in quarantine on either side.
Put the contact details in your asset register. Record the notice-contact email, account owner and billing owner next to each renewal date, so an inbox change at the client does not go unnoticed. A record-keeping tool such as InstaRenewal can hold these fields alongside renewal dates and ownership notes. It is a manual renewal-date and ownership record, not a mailbox monitor, so someone still has to update it when contacts change.
Route reminders to a place people actually work. Forward notices or reminder alerts into a shared inbox or ticket queue where tasks are assigned and have deadlines.

A Note on Certificate Notices

Do not assume the certificate authority will remind you. Let’s Encrypt, for example, ended its expiration notification emails on 4 June 2025, citing the spread of reliable renewal automation. It recommends third-party monitoring for anyone who still wants expiry warnings. For any certificate your agency relies on, either confirm that automated renewal is working or track the expiry date yourself.

2. Building a 30-60-90 Renewal Calendar: Batching Care Plan Audits Quarterly

Handling each renewal as it appears produces unpredictable fire drills, inconsistent client communication and extra administrative work. A 30-60-90 renewal calendar replaces that with a repeating quarterly review.

The idea is simple. Once per quarter, pull every asset that will expire in the next 90 days and work through them in three stages.

Window	Focus	Action items
90 days out	Discovery and health audit	List every domain, certificate, hosting plan and license expiring in the target period. Check expiry dates against the provider dashboard and an independent lookup. Flag unused add-ons, abandoned plugins and duplicate services.
60 days out	Client alignment and approval	Send the client a consolidated summary of what is renewing and what it costs. Confirm who pays and secure approval. Decide on upgrades, downgrades or cancellations.
30 days out	Execution and verification	Renew manually where the plan calls for it, and confirm that auto-renew is set for the rest. Check the payment method on file. Record confirmations, invoices and new expiry dates in the asset register.

Why 30 Days Is a Sensible Last Checkpoint

ICANN’s required notice schedule is itself built around the 30-day mark, since the first reminder is due roughly one month before expiration. Your own final checkpoint should come no later than the registrar’s first reminder. That leaves time to fix a payment problem, change an ownership issue or reach a client who is on holiday.

Implementing Quarterly Batching

Schedule fixed audit sprints. Reserve the same week each quarter, for example the first week of January, April, July and October.
Standardize client reporting. Send one consolidated renewal summary per client per quarter instead of scattered individual invoices. This is a workflow choice. Tidier billing is a reasonable expectation, but it depends on your contracts and how clients prefer to be billed.
Keep one asset register. Normalize renewal dates from every provider into a single list, with the owner, payer and notice contact for each asset.
Pull renewals into the quarter that precedes them. Anything expiring in the first weeks of the next quarter should be reviewed now, not three months later.

The Quarterly Cadence Has a Blind Spot: Short-Lived Certificates

A quarterly review works well for assets that renew annually, such as domains, hosting plans and licenses. It does not work for TLS certificates, because certificate lifetimes are shrinking. Under CA/Browser Forum Ballot SC-081v3, approved on 11 April 2025, the maximum validity of publicly trusted TLS certificates is being cut in stages:

Effective date	Maximum validity
Until 14 March 2026	398 days
15 March 2026	200 days
15 March 2027	100 days
15 March 2029	47 days

The 200-day limit is already in force. Certificates issued from March 2027 will last at most about three months, so a certificate could easily expire between two quarterly audits. Use the quarterly review to confirm that automated certificate renewal is in place and working, for example via ACME-based issuance or your host’s managed certificates, rather than to track certificate dates by hand. Treat manual date-tracking for certificates as a fallback, not the primary control. The same ballot also shortens how long domain-validation data can be reused, down to 10 days by 2029, which makes automated validation more important still.

3. The “Zero-Trust” Renewal Playbook: Verifying Auto-Renew Across Legacy Hosting Accounts

“Zero trust” in this context is borrowed shorthand for a simple rule: verify, don’t assume. A dashboard toggle that reads “Auto-Renew: ON” tells you that the provider intends to charge a card. It does not tell you the charge will succeed.

Common Auto-Renew Failure Modes

Expired or replaced payment methods. Cards expire, are reissued after fraud alerts, or hit their limits before the renewal date. Failed and expired payments are among the most common causes of involuntary subscription churn.
Payments tied to the wrong person. A card belonging to a founder, an ex-employee or the previous agency may be the only thing keeping a renewal alive.
Card-issuer authentication challenges. In the European Economic Area, Strong Customer Authentication (SCA) under PSD2 applies to the first payment, but later recurring charges that are properly flagged as merchant-initiated are generally exempt. The risk is narrower than it is often described. Issuers can still challenge a recurring charge for any reason, and an account that was set up in a way that does not meet the merchant-initiated requirements, or that was paused and restarted, may need the customer to re-authenticate. A failed charge of this kind needs a person to act, and nobody will notice if the notice goes to nowhere.
Account migrations. When a host moves legacy accounts to new billing infrastructure, a stored payment profile may not carry over cleanly. Check this after any provider migration or acquisition.
Different renewal timing per provider. Providers attempt renewal at different points before or after expiry, and some retry for days. Read each vendor’s documentation rather than assuming a standard schedule.

The Zero-Trust Verification Checklist

For every legacy or inherited account, work through these checks:

Payment method audit. Confirm which card or account pays, who owns it, and that it will still be valid at the renewal date. A common internal rule is to flag any card expiring within the next 90 days.
Fallback payment method. Where the provider supports a backup payment method, add one that the agency or client controls and monitors.
Notice contacts. Confirm that billing and expiry alerts go to an address someone reads (see Section 1).
Early manual renewal for critical assets. For domains, renewing 30 to 45 days early is low-risk because the renewal extends the existing term and does not shorten it. This tests the whole payment path while there is still time to fix a failure.
Independent expiry check. Compare the provider dashboard against an independent source such as an RDAP lookup for domains, or a certificate expiry check for public sites. A mismatch is a red flag worth investigating.
Record the result. Log the date you verified, what you checked and who confirmed it, so the next audit starts from a known state.

Where Tools Fit

A renewal-tracking platform can support this process by holding the renewal date, the account owner, the payer and the notice contact in one place, and by sending reminders ahead of expiry. InstaRenewal is built for this kind of manual renewal-date and ownership record-keeping across domains, SSL/TLS certificates, hosting accounts and plugin or software licenses. It is not a credential vault, an identity and access management system, or a security-auditing tool. It does not log into provider accounts or confirm that a payment will go through, so the verification steps above still need a person to carry them out.

Technical Appendix: Standardized Renewal Audit Checklist

Use this checklist during quarterly care plan audits.

Phase 1: Contact and Routing Verification

Confirm the registrant, billing and notice-contact emails in each provider account, not just in public lookups.
Confirm that notices route to an active agency alias or a monitored client address.
Check delivery of a test notice where the provider supports one, and check spam and quarantine folders.
Record the account owner, payer and notice contact in the asset register.

Phase 2: Expiration and Health Assessment

Compare dashboard expiry dates with an independent RDAP lookup for each domain.
Check certificate expiry dates and confirm that automated renewal is working.
Identify unused plugins, add-ons and redundant hosting resources.

Phase 3: Payment and Auto-Renew Validation

Confirm that the primary payment method will still be valid at the renewal date.
Confirm that a fallback payment method exists, where the provider supports one.
Renew critical domains manually 30 or more days early.
Save receipts and record the updated expiry dates in the asset register.

Accidental expirations are usually process failures, not technical ones. Fix where notices go, review assets on a fixed quarterly rhythm, and confirm that renewals actually succeed instead of trusting the toggle. Do those three things and your agency can protect client assets and keep care plan work predictable.

Originally published at https://instarenewal.com/blog/agency-renewal-operations-preventing-drop-offs-automating-calendars-and

The “Ghost Payment Method” Dilemma: How Expired Client Cards Silence Critical Renewal Notices

Memo — Thu, 08 Oct 2026 01:45:49 +0000

Digital agencies and web development firms face a recurring operational hazard that rarely gets attention until something breaks: the Ghost Payment Method.

Picture this scenario. A web agency designs, builds, and maintains an e-commerce store for an enterprise client. The agency registers domain names and sets up hosting, SaaS plug-ins, and SSL/TLS certificates on auto-renewal. To avoid carrying third-party hosting charges on its own books, the agency puts the client’s corporate credit card on file with vendor accounts (AWS, Cloudflare, Namecheap, WP Engine, or custom SaaS integrations).

Months later, the client’s corporate card expires, is compromised, or is replaced after a routine bank update. The client’s finance team updates its internal records and perhaps its main operational software, but forgets to tell the web agency.

To the agency, everything looks normal. The original card still shows as the “card on file” inside vendor accounts. That payment method has become a ghost: it looks valid in the vendor’s database but can no longer be charged.

When the annual domain or hosting renewal arrives, the charge fails. If the vendor account is tied to a former employee’s mailbox, an unmonitored info@ address, or a noisy shared inbox, the failure notices go unread. Depending on the vendor and the TLD, the site can then go dark, email can stop, or the domain can slide into a paid recovery window and eventually be released for anyone to register.

When mission-critical infrastructure goes offline, clients rarely blame the registrar or their own accounting team. They blame the web agency.

This guide explains why silent auto-renew failures happen, what the domain expiration lifecycle looks like in practice, and which protocols agencies can adopt to close the gap, from account updater services to quarterly card-health checks.

The Root Cause: A Billing Disconnect Between Banks, Clients, and Agencies

Payment failures like this don’t trigger alarms because the information has to pass through four parties, and each one assumes another is watching.

1. BANK
   Client's card is reissued (expiry, fraud replacement, product change).
        ↓
2. CLIENT
   Accounting updates its own records; external vendor portals
   managed by the agency are forgotten.
        ↓
3. VENDOR
   The vendor still holds the old card details. The renewal charge
   is declined, and a notice goes to the account's contact email.
        ↓
4. AGENCY
   The notice sits in an unmonitored or noisy inbox. The renewal
   window closes and the service lapses.

1. Stored Card Details Go Stale

When a card is saved with a merchant or registrar, the payment processor typically stores it as a token or payment-method reference instead of keeping the raw card number (the Primary Account Number, or PAN, which can run from 13 to 19 digits). The vendor’s portal shows a friendly label such as “Visa ending in 4092.”

That label only reflects what was saved. The vendor’s database does not know the bank has since replaced the physical card. Nothing errors out until the vendor actually attempts a charge.

Card networks do offer services that refresh stored details after a reissue (covered below). Whether any of them apply to a given vendor account depends on how that vendor’s payment processor is set up, and the agency usually can’t control that.

2. Failed Charges and Misrouted Notices

When a renewal charge is attempted against a dead card, the processor returns a decline. Depending on the processor, the reason might be an expired card, a generic decline, or a lost or stolen card code.

The second point of failure is who receives the notice:

Mismanaged account contacts. Registrars and hosting providers send billing-failure and expiry notices to the account’s primary email. If the account was registered with a former employee’s address, or a generic mailbox nobody checks, the warnings pile up unseen.
Email fatigue. Agencies managing hundreds of properties often route vendor email through filters or chat channels, where a single failed-payment notice is easy to miss among routine alerts.

3. Card Replacement Is Routine

Cards get replaced constantly: expiry dates roll over, banks reissue after fraud events, and companies change card programs. Public data on how often corporate cards specifically are reissued each year is thin, so treat any precise annual percentage you see quoted with caution. What is well documented is the downstream effect in subscription billing generally. Industry estimates, including figures attributed to Paddle, put involuntary churn (customers lost to failed payments, not a decision to cancel) at roughly 20 to 40 percent of all subscription churn, and expired or reissued cards are among the leading causes. Agencies face the same mechanics with a worse failure mode: the “customer” is a domain or server that stops working.

What Actually Happens When a Domain Renewal Fails

The domain is usually the most consequential asset in the ghost-payment scenario, so it’s worth knowing the lifecycle. The details below apply to generic TLDs such as .com, .net, and .org. Country-code TLDs (.de, .eu, .nl, .cx, and others) follow their own rules; Namecheap, for example, documents different renewal deadlines and redemption fees for several of them.

Before expiry. ICANN’s Expired Registration Recovery Policy (ERRP) requires registrars to send at least two renewal notices to the registrant, one about a month before expiration and one about a week before. If the domain hasn’t been renewed or deleted within five days after expiration, the registrar must send at least one more notice with renewal instructions.

After expiry. Registrar practice varies. Some delete expired names within days, while others hold them for weeks. If a registrar waits eight or more days after expiration to delete a name, the policy requires it to interrupt the domain’s existing DNS resolution for at least the final eight days of that renewable window. In practice, that is when the website and email stop working.

Redemption Grace Period (RGP). Once a registration is deleted, gTLD registries must offer a 30-day Redemption Grace Period during which the registrar can restore it at the registrant’s request. During this period the registry must disable DNS resolution and block transfers.

Pending delete. After the redemption period, the name typically sits in a roughly five-day pending-delete status, during which it can no longer be recovered. It then becomes available for anyone to register.

What recovery costs. Redemption fees are set by each registrar and vary widely. Examples of published figures: Network Solutions lists a $99.00 redemption fee plus a $35.99 reinstatement fee, while Fozzy lists about $40 for .com (with other TLDs ranging from $20 to $250). Namecheap notes that its redemption fee is set by its upstream registrar and registry and can’t be waived. The fee on top of the normal renewal price is a minor cost compared with the downtime and the risk that the name is lost entirely.

One structural point matters for agencies: the ERRP notices go to the registrant contact on record. If the agency registered the domain on the client’s behalf but the notice address is stale, the legally required reminders still arrive somewhere nobody is looking.

The Operational Risk Matrix for Web Agencies

When a ghost payment method causes infrastructure to lapse, the consequences extend well beyond a brief outage. Timelines for non-domain assets are set by each vendor’s own terms, so verify them per provider instead of assuming a standard grace period.

Asset Type	What Typically Happens on a Failed Renewal	Business Impact	Recovery Effort
Domain registrations (gTLD)	Notices go to the registrant email; after expiry, DNS may be interrupted, then the name enters a redemption window with extra fees; if unrecovered it is released for public registration.	Website and email (MX-dependent) stop working; brand risk if the name is re-registered by someone else.	Low to severe: a quick renewal in the grace window is cheap; redemption adds fees; a lost name can mean negotiating with a new owner or a dispute process.
Paid SSL/TLS certificates	The certificate expires if the renewal charge fails; browsers show security warnings on the site.	Checkout and form traffic drops; trust damage.	Moderate: reissue and reinstall, usually within hours once payment is fixed. Free ACME-based certificates don’t depend on a card, but they still depend on the renewal automation continuing to run.
Hosting and cloud accounts	Providers retry the charge, send notices, and eventually suspend services. Timelines and data-retention rules differ by vendor.	Site or application downtime; potential data loss if suspension turns into deletion.	Moderate to severe: depends on the vendor’s suspension and retention policy.
Premium plugin and SaaS licenses	A lapsed subscription usually ends updates, support, and license-gated features. Whether the product keeps working varies by vendor.	Security patches stop arriving; some features may switch off.	Low to moderate: reactivation is usually quick, but gaps in patching can create exposure.

Whatever the asset, the failure sequence is the same: a payment fails, a notice goes to the wrong place, and the first person to notice is the client.

Why Account Updater Services Help, and Where They Stop

Account updater services (Visa Account Updater and Mastercard’s Automatic Billing Updater) let issuing banks pass new card numbers and expiry dates to enrolled merchants’ payment processors, so stored cards can be refreshed after a reissue. Processors such as Stripe, Adyen, and Braintree support them.

There are two limits agencies need to understand.

They work for the merchant, not the cardholder. Stripe’s documentation describes automatic card updates as something it does for saved cards held in a Stripe account, and says it is widely supported for American Express, Visa, Mastercard, and Discover cards issued in the United States. It also says there is no way to know in advance which cards support updates. That helps if your agency bills clients through Stripe. It does not automatically refresh a card the client entered into AWS, a registrar, or a plugin vendor’s checkout. Whether those vendors use an updater is their decision, and you can’t turn it on for them.
Coverage isn’t total. Not every issuer participates, and updates can lag. Stripe notes that Visa real-time updates and Mastercard coverage differ by region. Cards that the issuer closes for fraud or non-payment may not carry through to a replacement.

The practical conclusion is that an updater service reduces failures on payment methods you control. It is not a substitute for knowing which card pays for which asset and checking it on a schedule.

Building a Protocol That Eliminates Ghost Payment Methods

1. Decide Who Pays, Then Make It Explicit

Every vendor account falls into one of three models:

Client-owned account, client-paid. The client is the account holder and owns the card. The agency is added as a delegated user. This is the cleanest ownership model but depends on the client noticing billing emails.
Agency-owned account, agency-paid, rebilled. The agency holds the payment method (ideally an agency-controlled card or virtual card), then invoices the client. The agency owns the expiry risk but also controls it.
Client-owned account, agency-held card details. This is the ghost-payment trap. The client’s card sits in an account the agency manages, and nobody is clearly responsible for keeping it current.

Move assets out of the third model wherever possible. Where a client insists on their own card, document in writing who must update it and by when.

2. Fix the Notice Path

For every asset, record the account’s billing and registrant contact email. Then confirm that:

The address is a monitored role mailbox (for example billing@youragency.com) rather than an individual’s inbox.
The client’s finance contact is also on the notice list wherever the vendor allows multiple contacts.
Registrant details on domains are current, since ICANN-required expiration notices are sent there.

3. Track Card Expiry as Data

For each client payment method on file, keep a record of the last four digits and the expiry month and year, and the list of vendors it pays. Never store the full card number or security code in a spreadsheet, ticket, or document. Set reminders 60 and 30 days before card expiry, so the client is asked for a replacement before any renewal date falls inside the gap.

4. Extend Terms Where the Vendor Allows

Domain registrations can be renewed for terms of up to 10 years under the standard registry lifecycle. Multi-year renewals for critical domains reduce the number of annual moments when a stale card can cause damage, at the cost of paying more upfront. Confirm the option with your registrar, since not every vendor supports it and TLD rules vary.

5. Use Account Updater Where You Control the Processor

If the agency bills clients for care plans, hosting, or license pass-throughs via Stripe or a similar processor, make sure automatic card updates are enabled and watch for update events. This protects your own recurring revenue, even though it doesn’t fix third-party vendor accounts.

6. Run a Quarterly Card-Health Check

A quarterly sweep takes little time and catches most ghosts:

List every client-paid vendor account and the card (last four, expiry) attached.
Flag any card expiring in the next 90 days.
Confirm each account’s notice email is still deliverable and monitored.
Check the next renewal date of each asset against the card expiry date.
Contact the client for updates on anything flagged, and log the date of the request and the reply.

7. Put Responsibilities in the Contract

Add clauses to service agreements and statements of work that state: the client must notify the agency within a set number of days of any card replacement used for third-party services; the agency’s responsibility for lapses is limited where a client-supplied payment method fails; and the client will not hold the agency responsible for renewal fees or recovery charges caused by a payment method the agency was not told had changed. Have a lawyer review the language for your jurisdiction.

8. Prepare an Incident Playbook

When a lapse does happen, speed matters more than diagnosis:

Look up the domain’s registration status (the expired, redemption, and pending-delete states appear in registration data lookups).
If the domain is still in the registrar’s grace window, renew it immediately at the standard price.
If it is in redemption, contact the registrar to restore it and ask for the exact fee before paying.
Tell the client early, in writing, with the cause and the timeline.
After recovery, fix the card, the notice path, and the contract gap that allowed it.

Key Takeaways

A payment method that shows as “on file” is not proof it will work at renewal time.
ICANN’s Expired Registration Recovery Policy gives domain registrants multiple notices and a 30-day redemption window, but those protections only work if the notices reach someone who acts on them.
Account updater services reduce failures on cards you process yourself. They don’t update cards sitting in third-party vendor accounts.
The strongest defenses are organizational: clear ownership of who pays, monitored notice addresses, card-expiry tracking, a quarterly check, and contract terms that put the duty to report card changes on the client.

Ghost payment methods stay dangerous because they fail silently and only become visible on the worst possible day. Treat every stored card as a dated record with an owner, and the surprise goes away.

Originally published at https://instarenewal.com/blog/the-ghost-payment-method-dilemma-how-expired-client-cards-silence-critical

The "Whose Card Is It Anyway?" Audit: Untangling Mixed Billing Responsibilities in Agency Client Accounts

Memo — Tue, 06 Oct 2026 02:48:44 +0000

Picture a familiar scene inside a growing digital agency. A critical Google Ads campaign stops mid-launch because the payment method was declined. The operations manager opens the billing settings and finds no corporate client profile and no enterprise billing agreement. The primary payment method is the agency founder's credit card, added during onboarding three years ago. The backup card belongs to a marketing director who left the client's company six months ago. The domain behind the campaign's landing page is set to auto-renew on a card that has since expired.

This article calls that tangle mixed billing liability: the payment method, the account owner and the person who gets the failure notices are all different people, and nobody has mapped who is who. It is easy to create and hard to see until something breaks.

Here is what mixed billing looks like in practice, why it hurts, and how to run a "Whose Card Is It Anyway?" Audit to fix it. The audit covers mapping payment responsibilities, moving cards to the right owners, using virtual cards where the agency must pay, and writing a fallback protocol into your contracts.

What Actually Happens When a Payment Fails

Platforms differ in how they handle a failed payment, and the differences matter for how much risk you carry.

Google Ads. Google's billing and payment suspension policy lists three triggers: an unpaid balance, suspicious payment activity, and a chargeback. For unpaid balances, Google says it may suspend an account if it has concerns about future payments because of payment method issues or declined payments. The same page says that accounts related to a suspended account, for example those sharing an email, a payment method, or a manager account, will also be suspended. A single bad card can therefore take down more than one client.

Meta. Payment problems are commonly cited among the reasons Meta restricts or disables ad accounts. Third-party recovery guides also warn that repeatedly retrying a failed payment can look like fraud. Treat that second point as practitioner advice, not Meta policy. Either way, you want a valid backup payment method in place before anything fails.

Domains. An expired card on a domain auto-renewal does not make the domain disappear immediately, but the safety net is thinner than most people assume. Under ICANN's Expired Registration Recovery Policy, registrars may offer an Auto-Renew Grace Period of 1 to 45 days, but they are not required to. After a registrar deletes an expired generic TLD name, the registry must offer a 30-day Redemption Grace Period. During that period the name stops resolving and cannot be transferred, and restoring it usually costs more than a normal renewal. Country-code TLDs follow their own rules.

The Hidden Costs and Risks of Mixed Billing

1. The financial float and uncollected spend

When an agency puts ad spend, hosting or software subscriptions on its own card and plans to invoice the client later (pass-through billing), the agency becomes an unsecured lender. If the client disputes an invoice, pays late or becomes insolvent, the agency still owes the card issuer. The larger the client's monthly spend, the larger that exposure.

Management fees are separate from this float. Agency pricing guides commonly cite 10% to 20% of monthly ad spend for percentage-based management, while other agencies charge flat retainers. Either way, the fee covers the work. It does not cover the agency taking on the client's credit risk.

2. Personal card exposure and cascading failures

Founders and account managers often put a personal card on a client account "just to get it running" during an urgent launch. Over time, that card gets attached to ad networks, domain registrars, hosting platforms and software subscriptions.

This creates two problems:

Departures. When someone leaves, their card often stays on file. If the card is cancelled, expires or is disputed, every service attached to it can fail at once.
Chargebacks. Google's policy says a chargeback on a legitimate Google Ads balance can lead to account suspension, and related accounts can follow. A cardholder disputing a charge on a card that funds ads can therefore freeze the account, and possibly its neighbors.

3. Payment method and account owner are different things

On most platforms, the party who pays and the party who owns the account are two separate attributes. Audits go wrong when people treat them as one. Some examples:

Google Ads: A client account has a paying manager, which can be the client or an agency's manager account. You can see it under Billing, then Settings. Google also supports a "Change who pays" process for moving billing between payers or agencies.
Shopify: A client store can be built in a partner account and transferred to the client. Shopify says that when a development store's ownership is transferred, the partner's credit card or PayPal account is automatically removed from the billing settings. The client must supply their own billing information. The partner can then keep collaborator access.
Domains: The registrant of record and the card paying for renewal are often different people. Fixing only one leaves a gap.

Step-by-Step Guide: Running the "Whose Card Is It Anyway?" Audit

Step 1: Discover and catalog every client asset

Build a central Payment & Asset Inventory Matrix. Ask account leads, media buyers and developers to list every active client asset in five categories:

Ad networks: Google Ads, Meta Ads Manager, LinkedIn Campaign Manager, TikTok Ads, Microsoft Advertising.
Infrastructure and hosting: AWS, Google Cloud, Vercel, WP Engine, Cloudflare, Liquid Web, Webflow.
Domains and DNS: GoDaddy, Namecheap, Squarespace Domains (formerly Google Domains), Network Solutions.
MarTech and SaaS subscriptions: HubSpot, Klaviyo, Zapier, Typeform, Semrush, ActiveCampaign.
Creative and plugin licenses: premium WordPress plugins, Canva, stock media accounts.

Payment asset inventory template

Client	Asset / platform	Card (last 4)	Cardholder and entity	Auto-renew	Billing admin email	Account owner	Risk
Acme Corp	Meta ad account	x-4102	Agency founder (personal card)	On	billing@agency.example	Client	Critical
Acme Corp	Domain registrar	x-8819	Former CMO (client)	On	former.cmo@acme.example	Client	High
Acme Corp	Klaviyo	x-1120	Acme corporate card	On	ops@acme.example	Client	Compliant

Add a column for the renewal date and billing cycle so the same sheet doubles as your renewal calendar.

Step 2: Audit auto-renewals and expiration schedules

The most common failure is the "silent renewal." For each domain, software license and annual agreement, record:

The exact renewal date.
The billing cycle (monthly, quarterly or annual).
The payment method linked to that specific line item.
Who receives the billing and renewal emails.

Also check for accounts where the primary card is the client's but the backup card quietly reverts to an agency card. That is mixed billing in its sneakiest form.

Step 3: Flag high-risk billing patterns

Classify every asset into one of three levels:

Critical (red): A personal card of an agency founder or employee is live on a client-owned account, or an unknown or former employee's card is active.
Moderate (yellow): The client's card is active but billing notices go to an agency staff member, or the card expires within 90 days.
Compliant (green): The client's corporate card is primary, billing contacts are client-owned, and the agency has access through partner or manager tools (for example Google Ads manager access or Shopify collaborator access).

Note a special case: an agency that is deliberately the paying manager on Google Ads, for example under monthly invoicing, is a legitimate arrangement but a different risk profile. The agency is then the payer. Google's "Sequential Liability" setting names the advertiser as a secondary payer if the agency does not pay the invoice. Decide that on purpose, and put it in the contract. Do not drift into it.

Standardizing Payment Architecture: Best Practices for Agencies

There are two defensible models. Pick one per asset and write down which.

Model	When it fits	Who carries payment risk
Direct client billing	Ad spend, hosting, domains, most SaaS	Client
Invoiced pass-through	Small tools, bundled retainers, reseller arrangements	Agency, so it needs controls

1. Make direct client billing the default

Ad accounts: Have clients enter their own payment details in Google Ads, Meta and TikTok. Agencies work through manager accounts, partner access or business-portfolio sharing. After setup, check the paying manager or payment owner shown in each platform's billing settings.
Domains: Register domains under the client's legal business name with the client's contact email and payment method.
Hosting and cloud: Be careful with AWS Organizations. Every organization has a management account that pays the charges of all member accounts, so a client's workload in your agency's organization is billed to you. If the client should pay, have them create their own AWS account and give your team cross-account access. AWS also offers billing transfer, which lets one management account manage and pay another's consolidated bill, but that is for deliberate reseller-style setups.
Shopify: Build stores in a partner account, then transfer ownership to the client. The client supplies billing and you retain collaborator access.

2. Use client-specific virtual cards when the agency must pay

If you must pay for tools, media or hosting on a client's behalf, avoid a shared physical card. Spend-management platforms such as Ramp, Brex and Mercury offer virtual cards with configurable controls, though the feature sets differ. Ramp, for instance, documents vendor-specific virtual cards with spending limits, expiration dates and merchant restrictions. Check whichever provider you choose for the following:

One card per client, so an incident or offboarding affects one client only.
Spending caps with headroom. A cap set exactly at the budget can decline a legitimate charge and cause the very failure you are trying to avoid.
Expiration dates tied to the end of the contract term.
Merchant restrictions where supported, so a card meant for one vendor cannot be charged elsewhere.

3. Use partner programs where they fit

Shopify: As described above, transfer the store and keep collaborator access.
HubSpot: Clients pay HubSpot directly. HubSpot says solutions partners earn a 20% commission on deals they source, and its commission FAQ says commissions are paid based on what the customer pays HubSpot. Unpaid client invoices therefore affect your commission, but not your card.

Designing Fallback Payment Protocols

Even with direct billing, payments fail. Cards expire, fraud filters trip and billing emails go unread. Define what happens next before it happens.

Primary payment fails
        |
        v
Billing alert reaches agency and client contacts
        |
        v
Stage 1: Client updates card or uses secondary card on file
        |   (if unresolved)
        v
Stage 2: Defined resolution window (for example 24 hours)
        |   (if unresolved)
        v
Stage 3: Agency pauses affected campaigns or services per contract

Protocol checklist

Require a primary and a backup payment method on every client-owned billing portal.
Route billing notices to a shared alias such as client-billing@youragency.example, plus a named client contact. Forward that alias into a team channel, and set it up before any card fails.
Define a resolution window in the contract (for example 24 hours) after which you may pause campaigns on the failing account. Do not quietly cover the gap with agency funds.
Check card validity quarterly. Confirm that every card has at least 90 days of life before peak periods such as Black Friday and Cyber Monday campaigns.
Do not retry failed payments repeatedly. Fix the underlying cause first. Repeated declines can look like suspicious activity to ad platforms.

Contractual Protections and Legal Safeguards

Update your Master Services Agreement (MSA) and Statements of Work (SOW) so that payment ownership is explicit. The sample language below is a starting point only. Have a qualified attorney adapt it to your jurisdiction and your agency's actual practices.

1. Direct third-party expense clause

"Client agrees to maintain valid payment credentials directly on all third-party platforms used to deliver the Services, including advertising networks, domain registrars, hosting providers and software services. Agency is not obligated to advance funds or use Agency payment methods for Client expenses. If Agency agrees in writing to pay a third-party expense on Client's behalf, Client will reimburse Agency [within X days of invoice / by prepaying the estimated monthly amount before launch], plus any agreed handling fee."

2. Right to pause for payment failure

"If a payment method on any Client-owned account is declined and not corrected within [24] hours of notice, Agency may pause affected campaigns or services until the issue is resolved. Agency is not responsible for lost revenue, campaign performance effects or domain expiration resulting from payment failures on Client-controlled payment methods."

3. Offboarding and credential migration

"On termination, Agency and Client will complete a billing and credential handoff. Client will replace any Agency-held credentials or payment methods on Client accounts within [ten (10)] business days of notice, after which Agency may remove its payment methods without liability for resulting service interruption."

Action Plan: Executing Your Audit This Week

Day	Task
Day 1: Inventory	Compile the Payment Asset Inventory Matrix from billing portals, accounting records and your password and access records.
Day 2: Flag risks	Mark every founder, employee or former-contact card on a client platform.
Day 3: Client outreach	Send clients a short request with steps to add their own corporate cards and backup cards.
Day 4: Migration	Remove agency and personal cards. Issue capped virtual cards for any pass-through expense you will keep.
Day 5: Governance	Update MSA templates, adopt the fallback protocol, and set a quarterly review.

Summary checklist for agency leadership

Catalog every ad account, domain, hosting plan and SaaS tool across all clients.
Record the paying party, the account owner and the billing contact for each asset.
Remove personal cards belonging to current or former staff.
Confirm each client-owned account has a primary and a backup card.
Move cloud workloads into client-owned accounts, or accept the payer role deliberately.
Issue dedicated virtual cards with limits and expiry dates for any pass-through expense.
Route billing alerts to a shared inbox and a client contact.
Update your MSA with payment-ownership, pause and offboarding clauses, reviewed by counsel.

Auditing "whose card is it" is dull work, but it prevents a bad week. When every asset has a named owner, a named payer and a named person who receives the failure notice, a declined card becomes a routine task and not a client-facing outage.

Originally published at https://instarenewal.com/blog/the-whose-card-is-it-anyway-audit-untangling-mixed-billing-responsibilities-in

Master Guide: Agency Renewal Operations & Workflow Automation

Memo — Mon, 05 Oct 2026 04:55:12 +0000

Digital agencies often manage the technology stacks of dozens or hundreds of clients. Domains, hosting, SaaS subscriptions, premium plugin licenses and API accounts all have to stay current to keep client services online.

Many agencies treat renewals as an afterthought. The result is lapsed domains, surprise out-of-pocket costs and angry clients when a site goes down.

This guide covers four operational frameworks for handling renewals at scale: catching payment failures early, getting client authorization before you pay, routing expiry notices to people who will see them, and smoothing the cash-flow spikes that clustered renewals create. Where the rules are set by ICANN, card networks or the CA/Browser Forum, the guide states them as of October 2026 and flags where they differ from common assumptions.

1. The "Silent Disconnect": Tracking Auto-Renewal Payment Failures Across Client Stacks

The Invisible Operational Vulnerability

When a client's store goes offline or a certificate lapses, the agency usually takes the blame first. The root cause is often not a technical fault. A silent auto-renewal failure is a common culprit.

A silent disconnect happens when an upstream provider (a registrar, host, cloud platform or SaaS vendor) fails to collect an automated recurring payment. The failure notice then goes to a mailbox nobody watches, or a team member reads it as routine.

Common Causes of Failed Auto-Charges

              ┌─────────────────────────────────────┐
              │     Auto-Renewal Charge Initiated   │
              └──────────────────┬──────────────────┘
                                 │
      ┌──────────────────────────┼──────────────────────────┐
      ▼                          ▼                          ▼
┌────────────────┐    ┌─────────────────────┐    ┌─────────────────────┐
│ Card replaced  │    │ Issuer decline or   │    │ Limit reached, card │
│ or expired     │    │ authentication      │    │ closed or billing   │
│                │    │ challenge           │    │ details changed     │
└───────┬────────┘    └──────────┬──────────┘    └──────────┬──────────┘
        └──────────────────────────┼──────────────────────────┘
                                 ▼
              ┌─────────────────────────────────────┐
              │ Failed charge → unseen notice →     │
              │ service suspension or expiry        │
              └─────────────────────────────────────┘

Replaced or expired cards. When a card is reissued, the vendor's stored card can go stale. Card networks run updater services (Visa Account Updater and Mastercard's Automatic Billing Updater) that pass new card details to participating processors. These services are enrolled by the merchant side, so an agency cannot switch them on for a vendor it pays. Treat card expiry as your own tracking responsibility.
Issuer risk declines. Banks can decline or hold unusual charges, such as a large annual bill, a first-time foreign merchant or a charge in a different currency. Whether a given charge trips a filter depends on the issuer, so don't assume a card that worked last year will work this year.
Limits and virtual cards. Single-use or time-limited virtual cards set up for one vendor can lapse or run short before the annual renewal. Credit limits consumed by other spend cause the same failure.
Authentication rules (PSD2 and SCA). In the EEA and UK, Strong Customer Authentication applies to the customer-initiated payment that sets up a subscription. Subsequent merchant-initiated charges on a saved card, such as subscription renewals, are generally out of SCA scope. This is a different rule from the common claim that renewals over a threshold require verification. Failures still happen in practice. Issuers can challenge any transaction, and a vendor that raises the price or changes the plan may need a fresh authentication from the cardholder. Chargebee notes that a changed subscription amount can require 3D Secure again on the first charge at the new amount. A vendor that mis-flags a renewal charge can also trigger a decline.

Payment method is only one failure point. Also check who actually receives the vendor's failure emails. AWS, for example, lets you set separate billing, operations and security alternate contacts on each account. AWS recommends using an email distribution list so that no single person is a dependency.

Building a Pre-Billing Verification Workflow

Run a repeatable check ahead of every renewal window. Most vendor dashboards do not expose payment-method status through an API, so plan for a mix of manual checks and your own card data.

T-minus 30 days: inventory and card-health audit. Maintain a master list of which payment card funds which vendor, and pull the expiry dates from your card issuer or finance system. Flag any card expiring within 60 days of an upcoming renewal, and confirm the vendor's billing page shows an unexpired card on file.
T-minus 14 days: payment-method validation. For cards you collect yourself, such as client cards held in your billing gateway, use a zero-value account verification rather than a small test charge. Card networks discourage $1 authorizations for card verification, and Visa's rules call for zero-value verification messages for stored credentials. Not every issuer supports them. You cannot run this check against a card stored in a vendor's system, so for those, confirm status on the vendor's billing page.
T-minus 7 days: provider notification parsing. Set up email rules in your tooling (Zapier, Make or custom webhooks) to watch billing mailboxes for phrases like Payment Failed, Declined, Action Required or Past Due. Route matches into your project-management system as urgent tasks.
T-minus 48 hours: escalation. If a charge has failed, open a high-priority ticket for the account manager. Define in advance which assets qualify for an emergency payment from an agency fallback card. Domains and other low-cost, high-impact items are the usual candidates, and the cost should be re-billed immediately. Anything outside that list follows the authorization rules in Section 2.

What Actually Happens When a Domain Lapses

Domain expiry is rarely instant, but the grace mechanics depend on the registrar and the extension. Under ICANN's Expired Registration Recovery Policy, registrars must send the registrant two notices before expiry, approximately one month and one week out. If the domain is not renewed or is deleted, the registrar must send at least one more notice within five days after expiry. Most gTLD registries also provide a 30-day Redemption Grace Period after deletion. During that period the domain can be restored, but DNS resolution is disabled and transfers are blocked. Redemption fees apply, and registrars set their own additional grace practices, so the site can be down well before the domain is truly lost.

A related deadline: since March 15, 2026, publicly trusted TLS certificates can be issued for at most 200 days. CA/Browser Forum Ballot SC-081v3 cuts that to 100 days from March 15, 2027 and 47 days from March 15, 2029. Any certificate that is still renewed by hand will need more frequent attention each year.

2. Building a Client "Pre-Renewal Authorization" Workflow That Eliminates Out-of-Pocket Expenses

The "Fronted Cost" Trap

When a client ignores an invoice, agencies often pay the vendor themselves to keep the site online and hope to recover the money later. This creates bad debt, strains the relationship and puts pressure on cash flow.

The fix is a Pre-Renewal Authorization Framework with three parts: a fixed milestone timeline, contract language that backs it up, and a rule that you don't pay upstream until you hold the client's money.

   T-60 days           T-30 days            T-15 days            T-0
 Audit & price      Authorization         Payment due       Renewal paid
     check             notice             (funds cleared)    with client funds

The 60-30-15 Day Milestone Standard

60 Days Out: Internal Audit and Cost Calculation

Action: Review upcoming renewals, confirm current vendor pricing and draft the renewal estimate.
Why now: Prices move. For example, Verisign will raise the .com wholesale fee by about 7%, from $10.26 to $10.97 per year, effective November 1, 2026. Registrars set their own retail prices, so the cost to your client will vary. Domain Name Wire reports that if Verisign takes the maximum increase every year its contract allows, the wholesale price would reach about $13.42 by the end of the current cycle. Quote renewals with the new price in mind.
Automation: Your CRM or project tool generates a renewal task for the account manager.

30 Days Out: Authorization Notice and Invoice

Action: Send the formal Pre-Renewal Authorization email and invoice.
Requirement: State the deadline for payment or written authorization, and state what happens if it is missed.

15 Days Out: Payment Collection Deadline

Action: Collect payment through your gateway (for example Stripe or QuickBooks Payments).
Safety rule: Do not pay an upstream vendor until the client's payment has cleared. "Cleared" means different things for different methods:
- Stripe says ACH Direct Debit can take up to four business days to confirm success or failure.
- Consumer-account ACH debits can be returned as unauthorized for up to 60 days. The window is two days for business accounts.
- Card payments can be disputed through chargebacks.Build that settlement time into your deadline, and treat an ACH payment from a business account as lower-risk than one from a consumer account.

0 Days Out: Vendor Payment

Action: Pay the vendor from collected funds, or confirm that the client's own card processed the renewal.

Contractual Protection Clauses

Add explicit language to your Master Services Agreement. The clause below is a starting template, and a lawyer should adapt it. Enforceability, and how far you can limit liability, depend on your jurisdiction and client type.

Third-Party Renewal & Non-Advancement Policy:

"Agency is not required to advance funds for third-party software licenses, domain registrations, hosting, or API services on Client's behalf. Agency must receive written authorization and full payment at least fifteen (15) calendar days before the vendor's renewal deadline. If authorization or payment is not received by that deadline, Agency may allow the underlying service to expire after written notice to Client. Agency is not liable for service disruption, loss of domain registration or data removal resulting from Client's failure to authorize or pay."

A few notes on the clause:

Broad language like "assumes no liability for... data removal" may not hold up everywhere. Courts and clients tend to scrutinize it, so keep the carve-out narrow and tie it to documented notices.
Consider treating the domain separately. Losing a domain can mean losing a brand's web address and email, so many agencies add a written final warning, or a pre-agreed emergency-renewal exception billed at cost plus a handling fee.

3. The "Notice Recipient" Matrix: Mapping Who Receives Registrar and License Expiry Alerts

The Root Cause of Missed Expiry Warnings

Critical assets often lapse even when the client has the money. The usual reason is that the warnings went to an unmonitored inbox: a departed employee's address, a generic info@ mailbox, or a spam folder.

An agency can prevent this with a Notice Recipient Matrix that assigns a role for every asset in a client's stack.

The Three Roles Every Asset Needs

                 ┌─────────────────────────────┐
                 │   CLIENT ASSET / SUBSCRIPTION│
                 └──────────────┬──────────────┘
          ┌─────────────────────┼─────────────────────┐
          ▼                     ▼                     ▼
    ┌───────────┐         ┌───────────┐         ┌──────────────┐
    │ WHO OWNS  │         │ WHO PAYS  │         │ WHO RECEIVES │
    └───────────┘         └───────────┘         └──────────────┘

Who owns: The legal entity holding rights to the asset. This should normally be the client.
Who pays: The party funding the account, either the client directly or the agency on a re-billed basis.
Who receives notices: The monitored address, webhook or distribution list that gets operational alerts.

Know Which Contacts Actually Exist

Domain contact records have changed. ICANN's Registration Data Policy took effect on August 21, 2025, and under it the administrative, technical and billing contact sets are no longer required for most gTLDs. Registrars are generally deleting that data, and only the registrant contact remains mandatory. Registrars send expiry notices to the registrant. Advice to "register our alias as the administrative contact" is therefore outdated for many domains.

In practice:

Make sure the registrant record names the client as the legal holder.
Use a role-based, monitored alias as the registrant email. A shared mailbox at the client's domain that forwards to both client and agency keeps ownership clear. If you instead use an agency-controlled address, document that arrangement in your contract.
Don't use an address on the same domain that is being renewed. If that domain lapses, its own mailboxes stop receiving the warnings.

For cloud accounts, use the vendor's contact features. AWS offers separate billing, operations and security alternate contacts, and organization administrators can manage them across member accounts.

Implementing the Notice Matrix Across Stack Tiers

Asset Tier	Example Vendors	Account Owner	Payer	Primary Notice Recipient	Secondary Notice Recipient
Core Infrastructure	AWS, Cloudflare, Google Cloud	Client	Client card	`ops@youragency.com` (alternate contacts)	`tech@client.com`
Domain Registrars	GoDaddy, Namecheap, Route 53	Client (registrant)	Agency re-billed or client	Registrant alias that reaches agency and client	`billing@client.com`
CMS / Hosting	Webflow, Shopify, WP Engine	Client	Client card	`webmasters@youragency.com`	`marketing@client.com`
Premium Plugins	WP Rocket, Elementor, Gravity Forms	Agency or client (check the license terms)	Agency bulk or client	`licensing@youragency.com`	Internal ops dashboard
Third-Party APIs	Twilio, SendGrid, Algolia	Client	Client card	`devs@youragency.com`	`it@client.com`

Plugin license terms vary on whether a license can be used on client sites you don't own, transferred, or reassigned after the engagement ends. Check each vendor's terms before assuming agency-held licenses are portable.

Setting Up Centralized Alert Routing

Avoid individual employee addresses as the main contact on client accounts. When people change roles or leave, alerts go with them.

Instead, create group-monitored aliases on your agency domain:

domains@youragency.com: domain registrar and DNS notices.
billing-alerts@youragency.com: hosting, cloud and SaaS billing notices.
licensing@youragency.com: plugin licenses and developer tools.

Route these aliases into your project-management or ticketing tool (Jira, Asana, ClickUp, Zendesk or similar) so every notice becomes a trackable ticket.

4. Staggered Renewal Schedules: Preventing Multi-Client Quarterly Billing Spikes for Agencies

The Danger of Cash Flow Volatility

Renewal dates tend to cluster when an agency onboards several clients at once or migrates a batch of infrastructure in one quarter. Two problems follow:

Cash flow dips. Paying a large volume of vendor renewals in one month strains reserves, especially while you wait for client reimbursement.
Account team overload. Managers handle dozens of authorizations, payment issues and client questions at the same time.

The numbers below are illustrative only. They show the same $109,500 of annual renewals under two distributions.

Quarter	Clustered renewals	Staggered renewals
Q1	$45,000	$27,375
Q2	$2,000	$27,375
Q3	$4,500	$27,375
Q4	$58,000	$27,375
Total	$109,500	$109,500

The Renewal Normalization Framework

Audit and group renewal dates into predictable monthly or quarterly cycles.

Phase 1: comprehensive stack audit. Build a master database of every domain, hosting plan, software license and API account across clients. Record the vendor, annual cost, expiry date, billing frequency, owner, payer and notice recipient.
Phase 2: cohorts and multi-year syncing. Group accounts into balanced monthly cohorts. Domains give you limited control. You can extend a registration at renewal, but the remaining term generally can't exceed ten years. You can lengthen a term, not shorten it, so adjustments push dates later rather than earlier.
Phase 3: align renewals where vendors allow it. Ask vendors whether they support co-terming, prorating or changing a renewal date. Enterprise and multi-seat plans are more likely to support it than small self-serve plans, so don't assume it is available.
Phase 4: bundle into the retainer, with a funding rule. Instead of sending large annual invoices, total the client's annual infrastructure cost, add a management or handling margin that reflects your admin time and risk, and bill it as part of the monthly retainer. Set the margin from your own costs, and disclose it in the contract. One caution: if a vendor bills annually and you collect monthly, you are fronting cash for up to eleven months. To avoid that, hold the monthly collections in a dedicated renewal reserve and pay the vendor from it, or collect the annual amount up front for annually billed assets.

Financial Comparison: Annual Lump-Sum vs. Monthly Bundled Retainer

Metric	Annual Lump-Sum Billing	Monthly Bundled Retainer
Agency cash flow	Uneven spikes, higher risk of fronting costs	Steadier monthly revenue, provided collections are held in a reserve
Client friction	Sticker shock when a large invoice lands	Smaller, predictable recurring charge
Administrative load	Multiple invoices, reminders and follow-ups	A single recurring line item
Bad-debt exposure	Concentrated in one large invoice	Spread across smaller payments, with the contract setting what happens on missed payment
Margin protection	Exposed to vendor price jumps between quote and renewal	Easier to adjust at each contract review

Agency Action Plan: Building Your Automated Renewal Operations

Use this checklist to put the four frameworks into practice:

AGENCY RENEWAL OPERATIONS CHECKLIST

[ ] Step 1: Create centralized agency aliases
    - Set up domains@, billing-alerts@ and licensing@ on your agency domain.

[ ] Step 2: Fix contact records
    - Confirm each domain's registrant is the client with a monitored alias.
    - Set billing, operations and security alternate contacts on cloud accounts.

[ ] Step 3: Add card and payment checks
    - Track card expiries against renewal dates 30 days out.
    - Use zero-value verification for cards you hold in your own gateway.

[ ] Step 4: Adopt the 60-30-15 authorization rule
    - Don't pay an upstream vendor until client funds have cleared.

[ ] Step 5: Update client contracts
    - Add a non-advancement clause, reviewed by your lawyer.

[ ] Step 6: Normalize renewal schedules
    - Audit the stack, group renewals into cohorts and ask vendors about co-terming.
    - If bundling into retainers, fund a renewal reserve.

[ ] Step 7: Re-check price and policy changes each quarter
    - Review upcoming registry price changes and certificate-lifetime rules.

Handled consistently, renewals become a set of scheduled, authorized and funded tasks instead of an emergency. Done well, that means fewer surprise outages and a cleaner bottom line.

Sources and Further Reading

Originally published at https://instarenewal.com/blog/master-guide-agency-renewal-operations-workflow-automation

The Client M&A Renewal Trap: What Happens When Your Client Gets Acquired

Memo — Sun, 04 Oct 2026 15:47:19 +0000

Imagine your routine monthly retainer charge fails because the client's credit card was declined. You email the VP of Marketing who championed your web agency for three years and get an automated bounce-back: "This inbox is no longer monitored."

Your client has been acquired.

Acquisitions are frequent. LSEG data shows global announced M&A reached roughly $4.6 trillion in 2025, up 49% from 2024 and the highest total since 2021. That means more of your clients, especially mid-sized brands that are natural acquisition targets, will eventually be bought. Buyers focus on finance, legal-entity structure, and leadership alignment. Domain registrations, DNS, hosting accounts, plugin licenses, and agency retainers are easy to overlook in that work.

This is the Client M&A Renewal Trap. After a deal closes, billing entities can be merged or retired, your primary contacts may leave, and payment methods may be cancelled. Meanwhile the client's web infrastructure keeps running on expiration clocks that nobody at the new parent company knows about.

If your agency relies on reactive account management, an acquisition can mean churn, unpaid invoices, or an emergency outage. If you have a plan in place, it can become a chance to deepen the relationship with a larger parent company.

The Anatomy of the M&A Renewal Trap

Most of the damage after a client acquisition is operational rather than legal. Where the deal is structured as a share purchase, the client's legal entity usually survives and your contract technically stays in force. Even so, payment methods, approvers, and email addresses can still change.

┌─────────────────────────────────────────────────────────┐
│                    Client Acquired                      │
└──────────────────────────┬──────────────────────────────┘
                           │
             ┌─────────────┴─────────────┐
             ▼                           ▼
   Operational Disruption      Infrastructure Vulnerability
   • Payment methods closed    • Registrant/contact emails go dark
   • Primary contacts leave    • Renewal reminders go unread
   • Vendor records reset      • Agency-billed services lapse
             │                           │
             └─────────────┬─────────────┘
                           ▼
┌─────────────────────────────────────────────────────────┐
│              Agency Action: Transition Playbook         │
└─────────────────────────────────────────────────────────┘

1. The Disappearing Billing Entity

After an acquisition, the target's finance function is often folded into the parent's. Corporate cards tied to the old entity may be cancelled. Invoices may have to go through the parent's procurement and accounts payable process. That usually means formal vendor onboarding, such as tax forms and banking details, and payment cycles that differ from what a small agency is used to.

2. The Contact Void

The people who understood your agency's value may be reassigned, laid off, or may leave. Their mailboxes can be shut down quickly. Your agency may lose its internal advocate before the new owner has reviewed your service agreement.

3. The Silent Infrastructure Expiration

Web agencies often hold or re-bill infrastructure on a client's behalf:

Domain registrations and SSL/TLS certificates: These sit in registrar or certificate accounts that may be tied to an individual employee's email address.
Agency-billed plugins and SaaS: Premium licenses (for example Gravity Forms, WP Rocket, or ACF PRO) may sit under an agency master account.
Managed hosting and cloud accounts: Platforms such as AWS, WP Engine, Kinsta, or Pantheon may be billed to the agency.

Domain renewal reminders go to the registrant's email address, so a dead inbox means the reminders go unread. ICANN's Expired Registration Recovery Policy requires registrars of generic TLDs to send expiration notices about one month and one week before expiry, plus another within five days after expiry. Those notices still depend on a monitored address. If nobody acts, the domain can be deleted. ICANN's policy gives gTLD registrants a 30-day Redemption Grace Period after deletion, during which the registry must disable DNS resolution. A site can therefore be offline well before the domain is gone for good.

Certificate cycles are getting shorter too. Under CA/Browser Forum Ballot SC-081v3, the maximum validity of public TLS certificates dropped to 200 days on March 15, 2026, falls to 100 days in March 2027, and to 47 days in March 2029. An account that nobody monitors will hit expirations more often over time.

When these services lapse, the result can be site outages, lost email, and a client who blames the agency.

Stage 1: Auditing Your Technical Assets

When an acquisition is announced, or when a payment fails unexpectedly, audit every digital asset tied to the client account.

Illustrative Risk Matrix (agency judgment, not an industry standard)
┌───────────────────────┬────────────┬──────────────────────────────┐
│ Asset Category        │ Risk Level │ Typical Failure Mode         │
├───────────────────────┼────────────┼──────────────────────────────┤
│ Domain & DNS          │ Critical   │ Missed renewal, stalled      │
│                       │            │ contact change, transfer lock│
│ Hosting & Cloud       │ High       │ Suspension after failed      │
│                       │            │ payment                      │
│ Premium Plugins/SaaS  │ High       │ Lapsed licenses, no updates  │
│ Retainer Agreement    │ Medium     │ Unpaid invoices, unclear     │
│                       │            │ scope                        │
└───────────────────────┴────────────┴──────────────────────────────┘

For each asset, record:

Who owns it (client or agency)
Which account and email address it is tied to
Who pays for it
When it renews

Navigating Registrant Changes and Transfer Locks

Domain management is often the trickiest part of a corporate transition. Under ICANN's Transfer Policy, which applies to gTLDs such as .com, .net, and .org, a "Change of Registrant" is a material change to the registrant's name, organization, or email address. The registrar must obtain consent from both the prior and new registrant (or their designated agents). The registrar must also impose a 60-day inter-registrar transfer lock afterward, unless the registrant opted out before the change was requested.

Three practical points follow:

The lock only blocks transfers to another registrar. It does not stop renewals or DNS edits.
Registrars decide whether to offer the opt-out. If you plan to change registrant details and move registrars, transfer first and change the registrant afterward, or opt out of the lock before the change is requested.
The rules are changing. In March 2025 the GNSO Council adopted Transfer Policy recommendations that would drop the Change of Registrant lock and shorten the lock after new registrations and transfers from 60 to 30 days. Rollout varies by registrar, so confirm the current rule with the registrar before relying on either number. Country-code domains (.uk, .de, .ca and others) follow their own registries' rules.

When the acquired company's legal name or contact details change during rebranding, work through this checklist:

Check lock status. Look up the domain via RDAP and ask the registrar directly. Since January 28, 2025, ICANN no longer requires gTLD registries and registrars to run port-43 WHOIS, so RDAP is the authoritative source for gTLD registration data. Registrars are not required to use a specific EPP status code for the Change of Registrant lock. A clientTransferProhibited status is also the ordinary registrar lock that owners can toggle, so the status code alone doesn't tell you why a domain is locked.
Verify access to the registrant email. If the registrant email sits on a mailbox that is being shut down, consent and notification emails will bounce. A pending Change of Registrant request that isn't confirmed within the registrar's window (capped at 60 days) simply doesn't proceed, and the old contact data stays on file.
Confirm who can request a transfer code. Under ICANN's updated rules, the Transfer Authorization Code (TAC) is generated only when the registrant requests it and expires after 14 days by default. Generating a code early and filing it away will not work. Instead, make sure someone with a working login at the client can request a fresh code when you need one.

Stage 2: The Operational Playbook for Agency Transitions

When an acquisition is confirmed, follow a structured plan covering billing, infrastructure, and legal continuity. The day ranges below are a suggested sequence, not an industry standard. Compress or stretch them to fit the deal.

Triage and adjust billing (suggested: days 1–3)
- Stop retrying cards you know are closed. Repeated failed charges create noise and fees. Send a manual invoice instead.
- Flag the account internally. Mark the client "In Transition – Pending Re-assignment."
- Document active work. List open tickets, pending deployments, and deliverables in progress.
Identify and engage the new decision-makers (suggested: days 4–10)
- Trace stakeholders. Search LinkedIn and company news for integration leads and digital or marketing heads at the parent company.
- Contact accounts payable. Ask the parent's AP team for its vendor onboarding requirements. A U.S. agency will typically provide an IRS Form W-9. A non-U.S. agency will provide a W-8 form, which is W-8BEN for individuals and W-8BEN-E for entities.
- Send a concise executive summary. Cover the site's architecture, active integrations, hosting setup, and current retainer scope.
Move infrastructure into the client's name (suggested: days 11–20)
- Shift subscriptions. Move client-specific SaaS, plugin, and hosting fees off agency cards and onto client-owned accounts wherever the vendor's terms allow it.
- Secure DNS access. Make sure at least two trusted people can reach DNS management (Cloudflare, Route 53, or wherever it lives) so IT migrations don't cause accidental outages.
- Update registrant contacts carefully. Move registrant details to a monitored, role-based address (such as domains@parentcompany.com) instead of an individual's inbox. Plan around the Change of Registrant process and lock described in Stage 1.
Confirm or re-paper the contract (suggested: days 21–30)
- Find out the deal structure. Whether anything must be re-signed depends on it (see Stage 4).
- Align commercial terms. Update invoicing cycles, payment terms, and approval hierarchies to the parent's vendor requirements.

Stage 3: Securing Infrastructure Continuity

Agency-Billed Plugins and SaaS

Agencies often buy multi-site or developer licenses for premium plugins and fold the cost into monthly retainers.

The risk: If the client relationship ends or enters limbo, you may stop paying for licenses the client's site depends on. Most commercial plugins keep running the installed version after a license lapses, but they stop receiving updates and support. Some features that rely on the vendor's servers may also stop working. Behavior differs by vendor, so check each one's terms. Also check whether your license is even transferable to the client, since many agency licenses are not.
The resolution: Offer an Infrastructure Transition Package. List every active license on the site, give the client direct purchase links, and offer a fixed-fee service to help them buy and configure their own licenses and API keys.

Managed Hosting and Cloud Infrastructure

If hosting runs under your agency's master account (AWS, Pantheon, WP Engine, Kinsta, or similar):

Don't shut hosting off abruptly. Pulling a site offline mid-integration damages trust and may breach your agreement. Have counsel review your termination and notice rights first.
Give clear written notice of separation. State that hosting must move to a client-owned account by a specific date. Thirty days is a common starting point, but follow whatever your contract requires.
Provide full exports. Supply a database dump, media library, and environment configuration through secure storage. This supports a clean handoff and protects your own hosting account.

Stage 4: Re-Signing and Contract Novation

Whether your contract needs any paperwork depends on how the deal was structured:

Stock (share) purchase: The client's legal entity stays the same, so contracts usually remain in place, unless they contain change-of-control provisions.
Asset purchase: Contracts generally have to be assigned to the buyer, and anti-assignment clauses typically require the counterparty's consent. That counterparty is you.
Change-of-control clauses: A change-of-control clause operates separately from an anti-assignment clause and can grant consent or termination rights even in a stock deal.

Read your own MSA's assignment and change-of-control language first. It tells you which of the options below you need.

Feature	Assignment	Novation	New MSA
What it does	Transfers the client's rights to another entity	Replaces the original party with a new one and releases the original from obligations	Replaces the old contract with new terms
Consent needed	Depends on the contract's assignment clause	Agreement of all parties	Agreement of both parties
Best used for	Simple transfers where the contract permits it	Keeping identical terms while changing the contracting entity	Expanding scope or adapting to the parent's procurement rules
Main risk	Original party may remain liable	Opens a negotiation if the new party pushes for changes	Invites a full procurement and legal review

Novation differs from assignment in that it moves obligations as well as rights, and it generally requires everyone's consent. Treat any timeline you give a client as an estimate, because enterprise procurement can take weeks or longer.

Crafting an Effective Change-of-Control Clause

To protect your agency in future engagements, consider adding a clause like the one below to your standard MSA. It is a sample for discussion, not legal advice. Have a qualified attorney adapt it to your jurisdiction. Enforceability varies, and confidentiality rules around deals can make advance notice impractical.

Corporate Successors and Change of Control: If Client undergoes a merger, acquisition, corporate reorganization, or sale of all or substantially all of its assets or equity (a "Change of Control"), Client shall give Agency written notice at least thirty (30) days before the effective date or, where advance notice is prohibited by law or confidentiality obligations, within five (5) business days after closing. Continued provision of services after a Change of Control is conditioned on either (a) the surviving or acquiring entity's written assumption of this Agreement, or (b) execution of a new services agreement. Fees accrued through the effective date of the Change of Control are due and payable upon closing or on the original due date, whichever is earlier.

Stage 5: Turning M&A Risk into Agency Growth

Acquisitions are also a chance to expand your presence. Parent companies often buy smaller brands without the internal capacity to manage their web platforms.

Positioning Your Agency for Post-Acquisition Growth
┌─────────────────────────────────────────────────────────┐
│                   Acquiring Parent Company              │
└──────────────────────────┬──────────────────────────────┘
                           │
             ┌─────────────┴─────────────┐
             ▼                           ▼
     Technical Audit Package     Enterprise Onboarding
     • Site security review      • Platform standardization
     • Code quality review       • SLA and reporting upgrades
     • Integration mapping       • Multi-site management
             │                           │
             └─────────────┬─────────────┘
                           ▼
┌─────────────────────────────────────────────────────────┐
│                 Expanded Agency Mandate                 │
└─────────────────────────────────────────────────────────┘

Deliver a "Day-1" digital asset summary. Give the parent's leadership a clear overview of the site's codebase, hosting and domain inventory, third-party integrations, and analytics setup.
Highlight your institutional knowledge. Your team already knows the brand's custom code, integrations, and performance history, which lowers transition risk for the incoming marketing team.
Propose upgrades where they are warranted. Use the integration window to raise technical improvements the new owner may not know about, such as consolidating hosting or fixing accessibility gaps. The European Accessibility Act, for example, has applied to covered e-commerce services since June 28, 2025. It exempts microenterprises providing services, defined as fewer than 10 staff and no more than €2 million in turnover or balance sheet total. A parent company that sells to EU consumers may face requirements the acquired brand did not.

Proactive Client Acquisition Checklist

Keep this checklist handy so a client acquisition doesn't catch you off guard:

Verify registrant contacts: Confirm every domain's registrant email points to a monitored, role-based address, not one person's inbox.
Know who can request transfer codes: Make sure someone with a working registrar login can generate a Transfer Authorization Code on demand.
Separate software licensing: Move client-specific tools to direct billing where vendor terms permit.
Maintain an infrastructure inventory: Record each domain, certificate, hosting plan, license, and API connection, along with its owner, payer, account email, and renewal date.
Include change-of-control terms: Make sure every client MSA covers assignment, notice, and successor obligations. Have an attorney review them.
Standardize vendor onboarding: Keep an up-to-date vendor packet ready (W-9 or the appropriate W-8 form, banking details, insurance certificates) for corporate procurement teams.

By tracking assets, contacts, and contract terms before an acquisition happens, your agency can keep services running, protect revenue, and build a strong relationship with the new owner.

Originally published at https://instarenewal.com/blog/the-client-m-a-renewal-trap-what-happens-when-your-client-gets-acquired

SAML SSO Certificate Expirations: How Expired IdP Metadata Locks Out Enterprise Clients

Memo — Wed, 30 Sep 2026 05:39:38 +0000

Article image
SAML SSO Certificate Expirations: How Expired IdP Metadata Locks Out Enterprise Clients
It is 8:30 AM on a Monday. Your agency's support inbox fills with urgent tickets. Every employee at your highest-paying enterprise client, from the warehouse floor to the C-suite, hits the same error after clicking "Sign in with SSO." Something like "SAML Response Verification Failed" or "Invalid Signature." Nobody can log in. The project portal, the internal CRM and the custom SaaS tool your team built are all unreachable.

The cause is rarely an attack, a hardware failure or a bad deploy. More often it is an administrative blind spot: the identity provider's SAML signing certificate reached the end of its life (or was rotated), and the portal your agency maintains was still trusting the old one.

SAML signing certificates live for years, so they sit out of sight. Microsoft Entra ID generates them with a three-year lifetime by default, and Okta auto-generates them with a ten-year default. Because they are touched so rarely, the person who set up the integration has often left, or moved on to other work, by the time the date arrives.

This guide covers how SAML certificate trust works, why expiry warnings often never reach the agency, what to do during an outage, how to build rollover-safe integrations, and how to keep the dates in front of your team using a renewal register such as InstaRenewal.

How SAML Certificates Work In a federated SSO setup there are two parties:

Identity Provider (IdP): the enterprise's login system, for example Okta, Microsoft Entra ID, Ping Identity or OneLogin. It holds a private signing key.
Service Provider (SP): the application being logged into, such as the client portal or web app your agency built. It holds the IdP's public certificate, usually taken from the IdP's metadata.
+-------------------+ 1. User attempts login +----------------------+
| | <-------------------------------- | |
| Identity | 2. Redirect with AuthN Request | Service Provider |
| Provider (IdP) | <-------------------------------- | (SP) |
| (Okta / Entra ID) | | (Agency App/Portal) |
| | 3. Signed SAML Assertion (XML) | |
| | --------------------------------> | |
+-------------------+ (SP verifies with public cert) +----------------------+
The flow works like this:

A user tries to open the SP. The SP redirects them to their company's IdP.
The user authenticates at the IdP (password, MFA, biometrics).
The IdP builds a SAML assertion containing the user's identity claims (email, roles, group memberships) and signs it with its private key.
The browser posts the signed response to the SP's Assertion Consumer Service (ACS) URL.
The SP checks the signature against the IdP certificate it has on file. If the signature does not verify, the login is rejected.
The point of failure
Every X.509 certificate carries a validity window with two timestamps, notBefore and notAfter. These are defined in RFC 5280 and baked into the certificate when it is issued:

Validity
Not Before: Oct 1 00:00:00 2023 GMT
Not After : Sep 30 23:59:59 2026 GMT
A common mix-up: SAML assertions themselves also carry NotBefore and NotOnOrAfter attributes inside a saml:Conditions element. Those control how long a single login assertion is valid (minutes, not years), and are unrelated to the certificate's lifetime.
Why the error rarely says "expired"
You might expect the SP to log "certificate expired." Usually it does not. Most IdP signing certificates are self-signed, so there is no certificate authority or chain to validate. Trust comes from the metadata exchange: the customer's admin handed you the metadata, and you pinned the certificate inside it. Many SP libraries never check the notAfter date at all.

What actually breaks is the key change. When the IdP starts signing with a new certificate, the SP receives assertions signed by a key it has never seen, and the log shows something closer to "signature verification failed" or "no matching key." The result is the same as an expiry: everyone in that tenant fails at once, from the same minute.

Some IdPs and SPs behave differently at the moment of expiry. For example, WorkOS's Entra ID troubleshooting guide notes that Entra keeps signing assertions with an expired certificate, and it is the application that rejects them. Either way, the practical lesson is the same: the date on the certificate is the deadline for coordinating the change with the client.

Two Expiry Dates, Not One Teams often track the wrong date, because a SAML metadata file contains two independent expiries:

Certificate notAfter Metadata validUntil
What it expires The key itself The metadata document describing the key
Defined by RFC 5280 (X.509) SAML 2.0 Metadata specification
Typical span Years Hours to weeks
How it changes A new certificate must be issued The metadata is republished
The SAML 2.0 metadata specification requires the root metadata element to carry either a validUntil or a cacheDuration attribute. A metadata file can be fresh and still contain a certificate that expired last night, or the reverse. Monitoring one tells you nothing about the other. What a given SP does when validUntil passes depends entirely on the library: some reject stale metadata outright, some log a warning and carry on, and some never re-fetch at all.

How Long Do SAML Certificates Last? There is no universal standard. The IdP chooses the lifetime.

Identity provider Typical SAML signing certificate lifetime Notes
Microsoft Entra ID 3 years by default Entra generates a self-signed certificate valid for three years when SAML SSO is configured; the expiration date can be customized when you create a certificate
Okta 10 years by default for auto-generated SAML app certificates A long lifetime pushes the expiry far beyond anyone's planning horizon
On-premises IdPs (AD FS, PingFederate) Often rotated annually Varies by configuration
Does the 47-day certificate rule apply?
You may have seen the CA/Browser Forum ballot (SC-081v3) that phases public TLS certificate validity down to 47 days by March 2029. That mandate covers publicly trusted TLS/SSL certificates. It does not apply to private SAML signing certificates issued by Entra or Okta, which keep their own multi-year defaults. Do not assume your SAML dates will suddenly shrink, but do keep your public SSL tracking separate from your identity-layer tracking.

Why Automated IdP Warnings Fail Agencies It is tempting to assume the client's IT team has this covered. Several structural gaps say otherwise.

Gap 1: The alerts go to the enterprise, not the agency
Microsoft Entra ID sends an email notification 60, 30 and 7 days before a SAML certificate expires. By default these go to the admins on the tenant, and you can add up to five notification addresses per application. Unless the agency's shared mailbox is on that list, the people who maintain the SP never see the warning. Microsoft also notes that if notification addresses are configured programmatically (via Microsoft Graph or PowerShell), an admin should open the application's single sign-on page in the Entra admin center once, or the expiry emails may not be sent.

WorkOS makes the same practical point in its own guidance: if nobody watches those emails, the first sign of trouble is users being locked out. Its recommendation is to add multiple addresses, including an on-call alias, rather than only the admin who created the integration.

Gap 2: Static metadata uploads vs. metadata URLs
In a well-built integration, the SP periodically re-reads the IdP's metadata URL and picks up new keys on its own. Persona's help center describes this model for Okta: because it re-reads the metadata URL, a newly activated certificate is picked up automatically, whereas a static XML upload has to be re-uploaded every time the certificate rotates.

Many custom portals never got that far. They were onboarded with a one-time XML file. Even when the client's admin does everything right in Okta or Entra, the SP keeps trusting the old key until somebody re-uploads metadata.

Other vendors document the same manual step. Spendesk's help center, for example, says that once a new Okta certificate is activated, users cannot log in until the new certificate is uploaded on the Spendesk side. Citrix likewise notes that Entra ID does not automatically pull in its certificate and must be updated manually.

Gap 3: No overlap window
If a client admin activates a new certificate in the IdP before the SP has been updated, every login breaks instantly. Okta's own documentation warns that after a signing key credential is updated, users cannot access the SAML app until the new certificate is uploaded to the service provider.

The safe order, as documented by Teleport and AWS IAM Identity Center among others, is:

Generate the new certificate in the IdP (leave it inactive).
Import or trust the new certificate in the SP.
Activate it in the IdP.
Confirm logins work, then delete the old certificate.
Skipping step 2, or doing step 3 before it, is what turns a routine rotation into an outage.

Emergency Recovery SOP: When a SAML Certificate Has Already Broken Logins Step 1: Confirm the shape of the problem The signature of a certificate problem is that every user in one tenant fails from the same moment. If only some users are affected, look elsewhere: clock skew on an app node, a group or attribute change, or a second IdP connection that was not rotated.

Check the SP logs, or decode the base64 SAMLResponse with a SAML tracer browser extension, and look for signature validation errors such as "signature verification failed" or "no matching key." Do not expect the word "expired."

Step 2: Get the current IdP metadata or certificate
Ask the client's IdP administrator for the latest metadata (or fetch it from their metadata URL if one exists).

Okta: Applications, select the SP app, Sign On tab, SAML Signing Certificates section. Download the certificate or use Actions > View IdP metadata. The metadata URL is shown under the SAML 2.0 sign-on method section.
Microsoft Entra ID: Enterprise applications, select the app, Single sign-on, SAML Certificates. Download the certificate (Base64) or the Federation Metadata XML.
Step 3: Compare fingerprints
Compare the fingerprint of the certificate in the new metadata against what your SP holds. A mismatch confirms the diagnosis in seconds.

Step 4: Add the new certificate; do not just replace the old one
Load the new certificate into the SP's SAML configuration. If your platform allows it, keep the old certificate alongside the new one until you are sure the IdP has fully switched. Replacing outright can trade one outage for another if some assertions are still signed by the outgoing key.

If your SP still stores a single certificate in a database column, updating it looks like this:

UPDATE tenant_sso_configs
SET idp_x509_cert = ''
WHERE tenant_id = 'enterprise_client_123';
Treat that as a stopgap. A single-value column cannot hold two certificates, which is why it cannot support overlapping rotation (see Rule 1 below).

Step 5: Clear caches and test
Clear any cached metadata (Redis, Memcached, in-process memory) so the SP uses the new key immediately. Then test an end-to-end login in a private browser window.

Step 6: Fix the class of problem, not just the instance
Afterwards, ask what allowed this to reach production: a single-certificate schema, a metadata refresh job that failed silently, or nobody tracking the date. The specific certificate is now good for another few years, which is exactly how long you have to forget about it again.

Proactive Agency SOP: Managing Enterprise SAML Lifecycles Rule 1: Store a set of trusted certificates, not one The SAML metadata specification allows an IdP to publish more than one signing KeyDescriptor, so the outgoing and incoming certificates can be listed at the same time. Your SP has to accept an assertion signed by any certificate in that set. If your schema keeps a single certificate per tenant, an overlapping rollover cannot help you, because the second key is discarded when metadata is ingested. Test this before you need it: load a metadata file with two signing keys and confirm both survive.

Rule 2: Prefer a metadata URL to a static XML file
Where the client publishes a reachable metadata URL, have the SP fetch it on a schedule (honoring cacheDuration as a polling hint) rather than relying on a one-time upload. Some caveats:

Not every client can expose a metadata URL. Some IdPs are internal or IP-restricted.
Auto-refresh is a trust decision. Fetch over HTTPS with certificate validation, and prefer signed metadata where available.
Your polling interval must be shorter than the overlap window the IdP provides, otherwise auto-refresh is decorative.
Alert if the refresh job stops succeeding. A job that has quietly failed for a month means your key set is a month stale.
Rule 3: Get on the IdP's notification list
For Entra ID, ask the client to add an agency-monitored mailbox (not a single person) to the application's certificate notification addresses. Up to five addresses are allowed. Confirm in writing who owns rotation on the client side.

Rule 4: Track days-remaining for every connection
Treat certificate notAfter, metadata validUntil, last successful metadata fetch and per-tenant login success rate as monitored signals. A tenant's login rate dropping to zero within one minute is a strong sign of a key or certificate problem, and it fires even when the root cause is something you did not anticipate.

For teams on Microsoft 365 / Entra, community write-ups show PowerShell and Microsoft Graph scripts that list enterprise applications, read each certificate's end date and send email alerts before expiry, which can be a useful supplement if you have delegated access to the tenant.

Rule 5: Give the human process a longer lead time
The slowest step in an outage is usually not technical. It is reaching the client's IdP admin and getting them to export metadata. Set reminders early enough that a real ticket can be raised with the client weeks ahead, not the night before.

Keeping SAML Dates Visible with InstaRenewal Once an agency has a dozen enterprise clients across different IdPs, keeping the expiry dates in people's heads or in scattered spreadsheets stops working. This is the kind of gap a renewal register is built for.

InstaRenewal is a renewal-operations tool for agencies and freelancers. It tracks domains, SSL certificates, hosting, plugin licenses, ownership, payment responsibility and access status, and supports custom asset types and renewal reminders. It is intentionally narrow, and it is important to be precise about what that means for SAML.

What it can do for SAML certificates
You can log each client's IdP signing certificate as a custom asset and record the fields that matter when the date approaches:

Client / Tenant Asset IdP Certificate expiry Metadata source Who receives IdP expiry notices Agency has SP admin access?
Acme Corp SAML IdP signing certificate Entra ID (entered manually) Static XML upload Client IAM team Yes
GlobalLogistics SAML IdP signing certificate Okta (entered manually) Metadata URL Client IAM team + agency mailbox Yes
(The rows above are an illustrative layout for your own records, not live data.)

With records like these, the platform's renewal reminders put the date in front of the team ahead of time, and the ownership, notice-contact and access fields answer the questions that slow down an incident: who owns the IdP, who gets its warnings, and can we even make the change ourselves?

What it does not do
Being accurate here protects your credibility with technical readers:

InstaRenewal's automatic expiry detection applies to SSL certificates on supported public domains. It does not fetch or parse private IdP metadata, extract SAML certificate fingerprints, or detect a certificate rotation. For SAML certificates, the expiry date is something you enter and maintain.
It is not an identity system, a login monitor or a security-audit tool, and it does not replace the technical controls in Section 6 (multi-certificate storage, metadata refresh, login-rate alerting).
It is designed to track renewal operations, not to hold secrets. Its privacy policy asks users not to enter passwords, API secrets or private keys into asset fields or notes. Log the date and ownership details, never the key material.
Used this way, the register is the layer that makes sure a human is reminded weeks before the date, while the SP-side engineering makes sure the date does not cause an outage in the first place.

Quick Checklist for Every Enterprise SSO Integration [ ] Recorded the IdP (Okta, Entra ID, Ping, other) and the certificate expiry date [ ] Recorded whether the SP uses a metadata URL or a static XML upload [ ] SP can hold more than one trusted signing certificate per tenant [ ] Agency-monitored mailbox added to the IdP's certificate expiry notifications (Entra: up to five addresses) [ ] Named contact at the client who owns IdP certificate rotation [ ] Reminder set well ahead of the expiry date, with enough lead time to reach the client [ ] Metadata refresh job (if any) is monitored for failures [ ] Rotation runbook documented: generate, trust in SP, activate, verify, then delete the old certificate [ ] Post-rotation, expiry date updated in your renewal register ---

Frequently Asked Questions
How long are SAML signing certificates valid? There is no standard; the IdP decides. Entra ID defaults to three years and Okta auto-generates certificates with a ten-year default. On-premises IdPs such as AD FS are often rotated annually.

Will my SP fail if it does not check certificate expiry? Not necessarily on the date itself, since many SPs pin the certificate and skip the check. But the outage happens when the IdP rolls to a new key, and that happens on the IdP's schedule regardless of what your SP validates.

What is the difference between validUntil and the certificate's expiry? validUntil expires the metadata document; the certificate's notAfter expires the key. They are independent, and either can cause trouble first.

Do the new 47-day TLS certificate rules apply to SAML? No. That schedule applies to publicly trusted TLS certificates. SAML signing certificates issued by an IdP such as Entra or Okta are private and keep their own lifetimes.

Only some of our client's users are locked out. Is it the certificate? Probably not. A certificate or key problem normally affects everyone in the tenant from the same moment. Partial failures point to clock skew, attribute or group changes, or multiple IdP connections where only one was updated.

Should we auto-refresh IdP metadata? Where the client publishes a reachable metadata URL, yes, with HTTPS, ideally signed metadata, and a polling interval shorter than the expected overlap window. Where there is only a static file, rely on early reminders and a documented manual runbook.

Conclusion
An expired or rotated SAML certificate is one of the most predictable ways to lock an entire enterprise client out of a portal, and one of the easiest to prevent. The dates are known years in advance. What goes wrong is ownership: the warnings go to someone else, the SP can only hold one certificate, and nobody on your side has the date written down.

Store more than one trusted certificate, prefer metadata URLs where you can, get your own mailbox onto the IdP's notification list, monitor login failures per tenant, and keep every client's certificate date in a register your whole team can see, with reminders that leave time to reach the client.

Sources
Microsoft Learn, Tutorial: Manage certificates for federated single sign-on (Entra ID certificate lifetime, notification schedule, notification addresses): https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/tutorial-manage-certificates-for-federated-single-sign-on
Okta Help Center, Manage signing certificates: https://help.okta.com/en-us/Content/Topics/Apps/manage-signing-certificates.htm
Okta Developer, Sign the Okta certificate with your own CA (behavior after updating a key credential): https://developer.okta.com/docs/guides/byo-saml/sign-the-csr/
Teleport Docs, Rotating SAML Signing Certificates (default lifetimes, rotation order, Okta and Entra steps): https://goteleport.com/docs/zero-trust-access/sso/saml-cert-rotation/
AWS Docs, Rotate a SAML 2.0 certificate, IAM Identity Center: https://docs.aws.amazon.com/singlesignon/latest/userguide/rotatesamlcert.html
SSOJet, IdP Signing Certificate Expiry: Preventing a Total SSO Outage (validUntil vs. notAfter, multi-key metadata, instrumentation), September 17, 2026: https://ssojet.com/blog/idp-signing-certificate-expiry-saml-sso-outage
SSOJet, The SAML Certificate Expiry Playbook (typical lifetimes by IdP): https://ssojet.com/white-papers/saml-certificate-expiry-rotation-playbook/
WorkOS, Common Entra ID SAML errors and how to fix them: https://workos.com/blog/entra-id-saml-errors
Persona Help Center, SAML SSO with Okta (metadata URL vs. static XML): https://help.withpersona.com/articles/3A0ZoW5ozu1k17n7bOrVuE/
Spendesk Help Center, SAML SSO: update an expired security certificate: https://helpcenter.spendesk.com/en/articles/9937661-saml-sso-update-an-expired-security-certificate
Clerk, Microsoft Entra ID SAML integration for SaaS apps (47-day TLS mandate does not apply to SAML signing certificates): https://clerk.com/articles/microsoft-entra-id-saml-integration-for-saas-apps
OASIS, Metadata for SAML V2.0 and IETF RFC 5280: https://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf, https://www.rfc-editor.org/rfc/rfc5280.html
InstaRenewal (product scope and privacy policy): https://www.instarenewal.com/ and https://instarenewal.com/privacy