## Problem A rule held at one entrance and not at the others, which is the shape [#3621947](https://git.drupalcode.org/project/kessai/-/issues/3621947) closed twice over and this is the third instance of it. `PaymentEngine::assertMetadata()` refuses a metadata name that is empty or longer than `PaymentMetadata::NAME_LENGTH`, and a value longer than `PaymentMetadata::VALUE_LENGTH`. Its docblock gives the reason, and `docs/architecture.md` cites that reason as the model for the amount bound beside it: otherwise the value reaches the database and what the caller gets back is the database's complaint about a column it has never heard of, on the path that takes money; and on a server that truncates rather than refusing, the payment becomes findable by a value nobody asked about. It is called from `create()` and from nowhere else. `authorizeToken()` and `chargeToken()` share `createTokenPayment()`, which asserts the kind, the amount and the account and then hands the caller's metadata straight to `createPayment()`, which writes a row per name. So the two doors that hold or charge a card the payer already authenticated — the doors that move money with the payer gone — are the two with no bound at all. It is reachable from the network. `PaymentApiController::takeTokenPayment()` reads the metadata off the request body and `ConsumerScope::assertMetadata()` checks only that no name is in the reserved namespace, never a length. So a consumer POSTing to `/kessai-api/token-payment` with a 300-character value gets a database exception rendered as `500 The payment could not be taken.`, where the same body on `/kessai-api/payment` is answered `422` with a sentence naming the value and the limit. ### And the refusal beside it states a reason that is no longer true `ConsumerScope::assertMetadata()` refuses a name starting with `kessai_` and tells the consumer that "that space says which consumer a payment belongs to". It does not, and has not since the consumer became a column on the payment: nothing anywhere writes a `kessai_` metadata name. Reserving the namespace is still right; the sentence a consumer is shown when it hits the rule is not. ## What shipped The bound moved onto the guard all three create doors share, which is where its neighbours already sit. At the door rather than at the one writer they share: a door answers with the payment that already stands before it writes anything, so a refusal at the writer would let a request carrying a name this engine cannot store be answered happily by a payment that does not carry it. Swept with it: the `@throws` on both token doors, which was short of the metadata rule and of the amount magnitude rule that has held on all three since #3621947; and `docs/architecture.md`, which named the bound only as the reason for the amount's. `ConsumerScope`'s reserved-namespace refusal told a consumer that `kessai_` "says which consumer a payment belongs to". It has not since the consumer became a column on the payment, and nothing writes such a name anywhere. The rule is still right — it keeps the room to put something there later — and the sentence now says that instead. ## Tests | Test | Against the unfixed code | |---|---| | `PaymentEngineTest::testEveryCreateDoorHoldsTheMetadataBound` | `authorizeToken() must refuse a name longer than the column.` | Nine cases: three rules against all three doors, so a guard three doors share cannot quietly lose one of them again. Then the other side of it on a door that had no bound at all: the longest name and value the columns take are charged and read back. AI-Generated: Yes (Claude Code was used to help draft this issue summary and to write the code and tests on the merge request. I reviewed and ran the work myself before posting it.)