A Domain Renewing on a Card That Is Gone

The card is the shared dependency

Domain expiry gets written about as a domain problem, and the cause is almost always a payment method.

One card sits behind the domains, the hosting, the certificate, the email service, the backup, and four subscriptions.

When that card changes, every one of them fails, on the same day, silently.

So the useful unit is not the domain but the card, and almost nobody has a list of what is charged to theirs.

The four ways a card goes

• It expires on its printed date.
• It is replaced after a fraud alert.
• It is cancelled when somebody leaves.
• The bank reissues it after a breach.

The second is the one that catches people, because it happens without warning and the number changes immediately. An expiry date is known months ahead; a fraud replacement is known on the afternoon it happens.

Why the failures are silent

Which is the mechanism worth understanding.

A declined renewal produces an email, sent to whichever address was used when the account was created.

For a service set up six years ago, that is frequently a personal address, a former employee's address, or an address nobody monitors.

So the payment fails, a notice is sent nowhere useful, and the first sign is something stopping.

For a domain, that is a month or more later, which is the version that ends up costing a redemption fee.

For a certificate, it is the site showing a warning to every visitor.

A worked example

A business had a card replaced in March after a fraudulent charge.

They updated the two services they used daily and thought nothing more of it.

In June their backup service turned out to have been failing since March, in July a domain went into redemption, and in August a certificate lapsed on a Sunday.

All three had the same cause and arrived three months apart, each investigated separately.

They now keep a list of what is charged to each card and work through it the day a new one arrives.

The list took twenty minutes to build from a year of statements.

Build the list from statements

Which is the same exercise as the domain inventory and can be done together.

Go through twelve months of the card statement and note every recurring charge, what it is, and roughly when it falls.

Annual charges are the ones that matter here, since monthly ones fail visibly within weeks.

A domain renewing once a year on a card that changed in March fails in November, by which time nobody connects the two events.

That list is the thing to work through whenever the card changes, and it takes ten minutes once it exists.

Keep it with the domain list rather than separately.

Use one card for everything business-critical

Which reduces the surface considerably.

A single card for domains, hosting, certificates, and email means one thing to update rather than four accounts to trace.

Better still is a card that is not carried around, since a card that never leaves a drawer is not replaced after a fraudulent charge.

Some businesses use a separate low-limit card for recurring services for exactly this reason.

Where a card is tied to an individual, it is worth moving to one in the business's name, since that survives somebody leaving.

All three of those reduce the number of times this happens rather than the damage when it does.

Fix the notice addresses too

Since prevention and notification are separate problems.

Go through each account and set the contact address to something more than one person reads.

A shared address for renewals, monitored by whoever handles them, is the arrangement that works.

That single change means a failed payment produces a message somebody actually sees.

Do it at the same time as building the list, since you are logging into each account anyway.

Set a calendar entry for the card

Not only for the renewals.

A month before the card's printed expiry, an entry saying update the recurring services, with the list attached.

That handles the predictable case entirely.

The unpredictable case is handled by the habit of working through the list whenever a new card arrives for any reason.

Two minutes on the day the card arrives prevents the whole sequence of failures that would otherwise unfold over the following year.

Do it before the card goes in the wallet, since that is the moment it will actually happen.

Domains are the ones to check first

Since the consequences differ enormously across the list.

A failed subscription to a design tool is an inconvenience you notice next time you open it.

A failed domain renewal runs through a grace period, then a redemption period costing many times the renewal, and eventually the domain becomes available to anybody.

The email addresses on it stop working part way through that, usually before anybody notices the website is down.

So when a card changes, do the domains, the hosting, and the certificate in that order, and the rest afterwards at leisure.

The counter-case

Many services now handle this themselves.

Card networks operate an updater service that passes new numbers to merchants automatically, and a good share of renewals now survive a replacement without anybody doing anything.

It does not cover every merchant or every card, so it reduces the frequency rather than removing the problem.

And a business with one domain and one hosting account can reasonably handle all of this without keeping any list at all.

Build a list of recurring charges from a year of statements, work through it the day any card changes, and set the notice addresses to something shared.

The twenty minutes

1. List recurring charges from statements.
2. Note the annual ones especially.
3. Keep it with the domain list.
4. Use one card for critical services.
5. Set notice addresses to a shared one.
6. Diary the card expiry.
7. Work the list whenever a card arrives.

Step two is the one that matters, since a monthly charge fails visibly within weeks and an annual one fails eight months after the cause and gets investigated as an unrelated event.

The domain side of this is covered in auto-renew and the card that expires.

Frequently asked questions

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.