The Link the Mail Scanner Clicked First

The credit controller at a building-supplies wholesaler has done everything right. The largest customer’s accounts payable lead asked for portal access so she could stop emailing for copies of invoices, and an invitation went out at 9:02. At 9:40 she replies: “Your link says it has already been used. I haven’t clicked it before.” She is telling the truth. Her company’s mail gateway opened the link at 9:02 and four seconds, checked it for malware, found none, and in doing so signed in as her and spent the only use the link had.

Two days later she is emailing for invoice copies again, and the portal has one more dormant account. Nobody in the story did anything wrong. The link did exactly what it was designed to do, and the design was wrong for the mailbox it landed in.

Nobody keeps a password for a supplier

Start with why the link exists at all. A business’s customer portal is, from the customer’s side, one of dozens. The person who settles your invoices also settles invoices from the fuel supplier, the cleaning contractor, the freight forwarder and the software vendors, and every one of them would like her to create an account. She visits each portal perhaps once a month, at month end, when she is busiest. A password she uses twelve times a year is a password she resets eleven of them.

So she does what everyone does: she stops signing in and emails your accounts team instead. “Can you send me a statement?” “Can you resend INV-2207?” Each request costs your side ten minutes, the portal’s usage report says nobody uses it, and the conclusion drawn is that customers do not want self-service. They wanted self-service without one more password.

The emailed link wins on every line that matters to the customer, which is why it has become the standard for low-frequency access. But it moves the whole security question onto the link itself, and a link has to be careful in ways a password does not.

What a sign-in link has to get right

A sign-in link is a password that travels by email, so it should be short-lived, usable once, and worthless to anyone who reads it out of a database. In AWRA each link is a random 64-character token. Only its SHA-256 hash is stored, so someone with read access to the database holds nothing that signs anyone in. It expires 30 minutes after it is sent, and it works once: using it marks it spent inside a locked transaction, so two clicks arriving at the same moment cannot both succeed.

The request form is careful about who is asking, too. A customer who needs a fresh link types their address on the portal’s sign-in page and gets the same message whether or not that address has access: “If that address has access to a customer portal, a sign-in link is on its way.” The form cannot be used to find out who your customers are. Each address can be sent three links per quarter hour and each network twenty requests a minute, so the form cannot be used to flood a stranger’s inbox either. Past the limit the message stays the same; the emails stop.

All of that is standard practice. None of it would have saved the accounts payable lead in the opening scene, because every property in the table is about the token, and her problem was about who clicked it.

The trap: something else clicks first

Corporate mail rarely reaches a person untouched. Secure email gateways, link-rewriting services and sandboxing tools follow the links in incoming messages to see where they lead and whether the destination is hostile. Some fetch at delivery, some at the moment of the click, some both. From the server’s point of view, that fetch is indistinguishable from a person opening the link: it is an ordinary request for the URL.

1. The email is delivered

   The customer’s mail gateway receives the invitation and finds a link in it.

2. The scanner follows the link

   Before the person sees the email, the gateway requests the URL to check what is behind it.

3. A naive server signs in on that request

   If opening the URL is what spends the token, it is now spent — by a machine that throws the session away.

4. The person clicks

   Minutes later the real customer opens the link and is told it has already been used or has expired.

5. Trust goes with it

   To the customer the portal looks broken, and to your team the customer looks careless. Both are wrong.

The failure is worst exactly where you most want the portal to work: larger customers with managed mail, whose payables teams process the most invoices. A small customer on a personal mailbox never sees it. That is why it so often survives testing — the team testing the portal is signing in from its own mailboxes.

The cost is one extra click for the customer. The test suite pins the behaviour: fetching the link twice leaves it unused, pressing the button signs the customer in, and pressing it again afterwards fails. It is worth being precise about the boundary of the protection. It defends against the thing scanners overwhelmingly do, which is fetch. A tool that went further and submitted forms on the pages it visited would still spend a link — which is one more reason the link is short-lived and asking for another takes ten seconds.

A single-use link that is spent by looking at it will be spent by the first thing that looks — and in a corporate mailbox, that is never the person.

Who gets in, and how they are turned off

Nobody signs up to a customer portal; they are invited. Under Sales → Customer portal, someone with the permission to manage it picks the customer, enters a contact’s name and work address, and the invitation goes out with the first sign-in link. A customer can have as many contacts as it needs — the payables lead, her deputy, the buyer who answers quotes — and each signs in as themselves.

One address belongs to one customer in your workspace. If an address already has access for a different customer, the invitation is refused rather than quietly moved, because a portal login that silently switched accounts would show one customer another’s invoices. The same address can hold access to two different businesses’ portals; asking for a link then sends one email per business, and each link opens only its own.

Your plan sets how many portal logins can be active at once. Re-inviting someone who already has access does not take another place, and a disabled login does not count. The access list filters by customer, by status and by contacts who have never signed in — the last of those being the list to work through after a batch of invitations goes quiet. Invite, resend and revoke work from the mobile app as well as the web.

Revoking is immediate in a way that matters. The login is disabled, every link already sent stops working, and because the portal re-reads the contact on every request, someone who is signed in at that moment is signed out on their next click rather than whenever their session would have lapsed. When a customer tells you their payables clerk left on Friday, that is one click.

What the customer can do once inside

The first screen answers the question behind most month-end emails: how much do we owe, and how much of it is overdue. Below that are the five most recent invoices and any quotes waiting for an answer. Everything in the portal is filtered by your workspace and by that one customer, and every record is looked up through those filters, so changing a number in the address bar finds nothing that belongs to anyone else.

Only issued invoices appear. A draft, or an invoice held for approval, is never in front of the customer, and an invoice that has been fulfilled or part-credited stays visible with its balance until it is settled, because fulfilling an order is a stock event, not a payment.

The statement is the page that replaces the most email. It opens on the last six months, takes any date range, and carries an opening balance, each invoice, payment and credit note in date order with a running balance, and a closing balance. Because credit notes are on it, the figure at the bottom is what the customer actually owes.

Answering a quote from the portal is the same act as answering it from the link in the quote email: the quote is marked accepted or declined with the contact’s name and time, the decision is written to the audit trail, and whoever wrote the quote is told in their notifications. A quote that has expired or has already been answered cannot be answered again. Quotes still in draft never appear.

Paying from the portal goes through the payment gateways the business has connected, straight into the business’s own accounts. The customer can pay the full balance or any part of it, and the payment is recorded against the invoice when the gateway confirms it, not when the browser comes back — a closed tab does not lose a payment and a faked return page does not record one. The gateways are currently set up in one currency, so the Pay button appears only on invoices in that currency; an invoice in another currency shows its balance and the payments against it. The customer portal feature page walks through the screens.

Frequently asked questions