What a link id reveals
A checkout URL identifies the tool author to anyone holding it. A property of the design, not a defect.
A Moove payment-link id is not a secret, and anyone holding one can read the payee’s identity.
Why the read is public
GET /v1/payment-link/{id}takes no key — by design, because the payer has no Moove account and no key, so the hosted checkout page has to be able to read the link it renders. Tollbooth depends on exactly that: it is what lets a server poll for settlement without spending its own rate-limit budget, and what would let a hosted gateway poll without ever holding a tenant’s key.
We confirmed it directly: a read of a real link id with no X-API-Key header returns the full object.measured · 2026-09-07
What it discloses
| field | what it reveals |
|---|---|
destinationAddress | The tenant's settlement wallet address |
userId | The tenant's Moove account id |
user.handle | The tenant's Moove handle |
user.wallet.provider | Which wallet they use, e.g. MetaMask |
toAmount, status, receivedAmount, transactionUrl | The charge itself |
What follows
- A checkout URL contains a link id. Treat it as you would any link that identifies you: fine to hand to the person paying, not fine to paste into a public issue or a shared log.
- Tollbooth never logs a checkout URL or a link id. The fingerprints it logs are of handles, and a handle is never derived from a link id — a test guards that.
- Tollbooth never uses a link id as a handle, for the same reason: it would be a bearer credential anyone could read.
- If you would rather your wallet address were not derivable from a checkout URL, this provider cannot give you that. It is inherent to a public read, not something a flag turns off.
The operator dashboard, when it ships, shows fingerprints only — never a handle, never a link id — for the same reason. See security.