The Link That Expired Before They Clicked

You send somebody a link to pay. They see the message on their phone on the way home, think "I'll do that tomorrow," and do exactly that.

By then the link is dead.

⚠️ They do not see a helpful explanation. They see an error page, or a blank one. Some of them try again. Most of them put the phone down and you never hear about it, and the payment sits unpaid with a note in your system saying you sent the link.

The short version

• Most payment and booking links expire on a timer you did not set
• The person who clicks a dead link is given no way to ask for a new one
• You get no notification either — the link just stops working
• The fix is to send the link when they are ready to use it, not in advance
• For anything that must survive, ask for a link type that does not expire

Why this is not obvious

What it looks like	What is happening
"I sent them the link"	You sent a link with a hidden deadline
"They never paid"	They opened it after the deadline
"The system is broken"	The system is doing exactly what it was built to do

⚠️ Expiry is a security feature, not a fault. A payment link that lives forever is a payment link that can be forwarded, screenshotted, and used by the wrong person months later. The timer is deliberate.

⇒ That does not make it convenient. It makes it something you have to plan around.

One: the timers you are probably subject to

These vary by provider, but the shapes are consistent.

Payment session   often 24 hours
Password reset    15 minutes to 1 hour
Booking hold      10 to 30 minutes
Magic sign-in     5 to 15 minutes
Document share    whatever somebody set, often never

⚠️ The short ones catch staff, the long ones catch guests. A fifteen-minute password reset is fine if somebody is sitting at a computer and hopeless if they are on the floor.

How to find out yours

"How long is this link valid for?"

⇒ One question to whoever provides the system. Ask it before you need the answer, because the moment you need it you will be standing in front of somebody whose link just failed.

Two: the one that costs you money

Payment links are the expensive case, because the failure is silent on both sides.

You     see "link sent" and assume it is in progress
They    see an error and assume the charge failed
Neither of you sees "this link expired at 4pm yesterday"

⚠️ Nobody is notified when a payment link expires unused. It simply stops working. The record on your side still says you sent it.

What that produces

An unpaid invoice that looks like it is being handled
A guest who thinks they tried and it did not work
A gap of days before anybody realises

⇒ Related shape: the automatic message that never sent — a task that is configured, appears active, and has never actually fired.

Three: send it at the moment of readiness

The practical fix is not technical.

Bad   send the link, then wait for them to be ready
Good  wait until they are ready, then send the link

⚠️ Most expiry problems are timing problems, not link problems. A 24-hour window is plenty if the person is looking at their phone when it arrives.

What "ready" means here

They have agreed the amount
They are not driving, working or asleep
They have said they will do it now

⇒ If any of those is missing, the link is going to sit unopened, and the clock is already running.

Four: the link that does not expire

For some jobs there is a second kind of link that has no timer at all.

Session-type  created for one person, one purchase, expires
Standing-type created once, reusable, does not expire

⚠️ They look identical in a message. Both are a web address; nothing about them tells the recipient which kind they have.

When each one fits

Session-type   a specific amount, a specific person, soon
Standing-type  a fixed price anybody can pay at any time

⇒ If you find yourself sending the same amount to different people repeatedly, the standing type will save you the entire problem.

⚠️ Ask for it by describing the behaviour, not the name. "A link I can send that will still work next week" gets you the right thing; the product names differ between providers.

Five: the message that goes with the link

Whatever the timer is, the message can carry it.

Bad   "Here's the payment link."
Good  "Here's the payment link — it works until tomorrow evening.
       If it's expired, just reply and I'll send a new one."

⚠️ The second sentence is the one that matters. It converts a dead end into a reply, and a reply is something you can act on.

Why people do not ask for a new link

They assume it is their fault
They assume asking is a hassle
They have already moved on to something else

⇒ Telling them in advance that a replacement is one message away removes all three.

Six: the internal version of the same problem

It is not only guests. Staff hit expiry constantly and rarely report it.

A password reset that timed out while they were on the floor
An invitation to a system that expired before their first shift
A shared document link that stopped working after a month

⚠️ Staff usually respond to an expired link by giving up quietly, especially if they are new and unsure whether they did something wrong.

The onboarding case specifically

Day 1  invitation sent
Day 4  first shift
Day 4  invitation expired on day 3

⇒ Send access on the day it will be used. An invitation sent early is worse than one sent late, because it creates a false record that access was given.

⇒ On the related problem of a setup that looks complete but nobody has used: the screen that looks used.

Seven: what to do when somebody reports one

The response should be boring and fast.

One   Do not investigate. Send a new link.
Two   Ask them to open it now, while you are still talking.
Three Confirm out loud that it worked.

⚠️ Step two is the whole thing. Sending a second link into the same silence produces the same result.

If it fails twice

Then it is not expiry. It is something else -
wrong address, blocked message, or a real fault.

⇒ Two failures is the point at which the problem changes shape, and the response should change with it. Checking whether the message even arrived is covered in the messages that never arrived.

Eight: the record that says you sent it

Every system that sends links records the sending. Almost none record the outcome.

Recorded    the link was created and sent, with a timestamp
Not recorded whether anybody opened it
Not recorded whether it expired unused

⚠️ A list of sent links is not a list of things in progress. Treating it as one is how an unpaid balance sits untouched for three weeks with everybody believing it is handled.

The check that costs nothing

Once a week: which links did we send that were never used?

⇒ If your provider can answer that, it is the highest-value report you are not currently reading. If it cannot, the answer is your own list of amounts still outstanding.

Numbers worth keeping

One   How long each type of link you send stays valid
Two   Payment links sent last month
Three How many of those were used
Four  The gap between sending and using, for the ones that worked

⚠️ Four tells you what your real window needs to be. If people typically pay eleven hours after receiving, a twelve-hour link will fail constantly and a 24-hour one will mostly work.

The card for the office

────────────────────────
  Sending a link

  1. Are they ready to use it right now?
  2. Say how long it lasts, in the message.
  3. Say "reply and I'll send a new one."
  4. If it fails twice, it is not expiry - check delivery.

  A sent link is not a paid invoice.
────────────────────────

Common objections

"We'd know if links were failing"

⚠️ You would know if somebody told you. Expired links produce no notification on either side — the only trace is an amount that stays unpaid.

"Just make the links last longer"

⇒ Sometimes you can, and it is worth asking. But the maximum is usually fixed by the provider, and a long-lived payment link is a real risk if it is forwarded.

"They should just ask for a new one"

⚠️ They should, and they do not. Assume silence after a link is failure, not progress.

"We send the link as soon as they book"

⇒ That is the most common pattern and the one that expires most. The booking and the payment happen at different moments; send the link at the second one.

"It's the guest's fault for not clicking"

⇒ Possibly, and it changes nothing. The money is still unpaid and the only person who can fix it is you.

"We use a system, so this doesn't apply"

⚠️ Systems are where this happens. A person handing over a card machine has no expiry problem at all — the timer only exists because the link does.

What to do this week

One   Ask how long each kind of link you send is valid for.
Two   Add the expiry to the message text. One clause.
Three Add "reply and I'll send a new one."
Four  List payment links sent this month that were never used.
Five  For anything recurring, ask for a link type with no timer.

Summary

• Links expire on timers you did not set and nobody is notified when they do
• A sent link is not a payment in progress
• Send links at the moment of readiness, not in advance
• Put the expiry and the replacement offer in the message
• For repeated fixed amounts, ask for a link that does not expire
• If it fails twice, stop blaming expiry and check delivery

A link that expired is indistinguishable from a link that was ignored. Only one of those is your problem to fix, and you cannot tell them apart without asking.