upto scheme

The scheme's own summary is that it authorizes a transfer of up to a maximum amount from a client to a resource server, with the actual amount charged determined at settlement time based on resource consumption during the request. Its stated uses are the ones where cost is unknowable in advance: tokens a model generates, bytes transferred, compute consumed. Settlement cannot come before the request runs, because the amount is not known until it has.

What the scheme requires is what makes an open-ended amount safe to sign. Each authorization is settled at most once and is consumed whatever amount it settled for. Each carries an explicit start and end time. Each binds the recipient address cryptographically, so neither the server nor a facilitator can redirect the funds to an address the client did not sign for. And the settled amount must be at or below the authorized maximum, which it may fall well short of when little was used.

One field means two things depending on when it is read, and that is the practical hazard. The amount of the payment requirements is the maximum the client authorizes at verification time, and the amount actually to be settled at settlement time. A reader holding one value out of that exchange cannot tell from the value alone which of the two it is.

exact is the other shape and the more legible one from outside: a fixed price stated in the payment challenge and settled for exactly that. An endpoint quoting this scheme is quoting a ceiling, so a reading of its terms records what it could charge rather than what it did.