Verifying a customer payment, end to end
No model decides whether money moved. A payment notice arriving in a dedicated platform mailbox is matched against exactly one pending expectation on reference, amount and currency, from a trusted sender with an aligned authentication pass. Anything that does not match all of it is held for a person to look at. This is operator work, and it deliberately lives outside every customer workspace.
Why this one is operator-only#
Almost everything in Connect is one implementation serving two audiences. This is one of the few exceptions, and the reason is not capability but role: verifying that a customer paid is running the platform, not using Connect. A customer's own billing view is a status — what plan is active, what the allowances are — and nothing more.
The records live in the control plane rather than in any workspace, alongside platform identity and sessions. That placement is what stops a payment record being visible through a workspace-scoped screen, and it is the same reason website enquiries addressed to the operator sit outside every workspace too.
What counts as evidence#
Activation is fail-closed: every condition must hold, and the failure of any one of them sends the notice to review rather than through. The conditions are deliberately dull, because a dull check is one that cannot be talked into a false positive.
- The notice arrived in the dedicated platform payment mailbox, which is connected with read-only access and nothing wider.
- The sender is on the trusted payment-sender list — an allow-list, not a guess at what a bank's address looks like.
- Authentication passed and is aligned with the sender's own domain, so a lookalike address does not qualify.
- The notice was not forwarded. A forwarded payment notice never activates automatically, whatever it says.
- The reference resolves to exactly one pending expectation. Zero is not enough and two is worse.
- The amount and currency match that expectation exactly. Close is not a match.
Stage by stage#
- Trigger — an expectation is created for a workspace with a reference, an amount and a plan, and then a payment notice arrives in the platform mailbox.
- User or external event — the customer pays, and their bank or provider emails a notice. Nobody is asked to upload a screenshot.
- Authentication and workspace resolution — the operator's own authority is required to reach any of this, and a customer session is refused rather than served a narrowed version.
- Ingest or request — the mailbox is scanned in bounded batches, with the messages already seen remembered so the same notice is not reprocessed.
- Canonical record — a verification row is created and linked to the expectation it matched, carrying the reference, the amount, the currency and the address it was expected from.
- Reasoning — none, and this is the load-bearing decision. No model reads the notice to judge whether payment happened; the match is deterministic or it is not a match.
- Knowledge, memory and rules — untouched. A payment teaches Connect nothing about the customer's business.
- Autonomy and approval — automatic activation happens only when every condition holds. Otherwise the verification is marked for review and waits for an operator, who must type an exact confirmation phrase to approve it by hand.
- Action through a provider — the confirmation email is sent from a sender the operator explicitly chose. A transactional sender is never guessed.
- Result — the expectation moves from pending to confirmed by a conditional update; if it was already confirmed the verification is recorded as a duplicate rather than applied twice.
- Relationship, timeline and memory — the workspace's entitlement is updated: the paid plan, its daily limits, an active status, and the removal of any required signature line.
- Audit, usage and Needs You — every money action is audited with its result, and anything held for review is visible as work waiting rather than as a message that went quiet.
When it does not match#
| Finding | What it usually means | What the operator does |
|---|---|---|
| Sender not on the allow-list | A new bank address, or a notice from somewhere unexpected | Confirm the source, then approve by hand or add the sender deliberately |
| Authentication not aligned | A forwarded or spoofed notice | Treat as unverified; ask the customer for the reference |
| Reference matched none or several | A mistyped reference, or two open expectations sharing one | Correct the expectation, then re-run |
| Amount or currency differs | A partial payment, or a fee deducted in transit | Decide deliberately; nothing activates on a near miss |
A held verification is not a failure of the flow — it is the flow working. Every one of these is a case where activating automatically would be guessing, and the cost of guessing wrong is a plan activated for money that did not arrive, or a customer told their payment was not seen when it was.
An expectation whose reference is already in play cannot be created twice: a uniqueness guard on the active reference is created fail-closed, so two open expectations cannot quietly share one identifier and turn a single notice into an ambiguous match.
Questions#
Can a customer see this flow?
No. A customer session is refused at the operator boundary rather than shown a reduced version. What a customer has is a billing status: the plan in force and the allowances that come with it.
Does an AI model read the payment notice?
No, and that is deliberate. Whether money moved is decided by exact matching on a reference, an amount and a currency from an authenticated, trusted sender. A model's opinion about a payment email is not evidence.
What happens if the same notice is processed twice?
The second pass finds the existing verification by the message's own identifier and returns its outcome. If the expectation was already confirmed, the attempt is recorded as a duplicate rather than applied, so a plan cannot be activated twice by a retry.