OUTCOME · Planned · Create or advance
What changes
None today: this route is not executable. Its intended behavior is: no executable public mutation exists. A future HTTP 202 would create a settlement intent and retained commitments only; it would not prove MPC authorization, signing, submission, broadcast, confirmation, treasury credit, invoice payment, fulfillment, or final settlement.
WHY IT MATTERS
- Lets people and agents prepare for settle rotational wallet without falsely presenting roadmap scope as a live capability.
- Gives people and agents a contract-backed way to advance settle rotational wallet.
- Connects catalog and invoice operations to payment collection and treasury reconciliation without making presentation state or a reserved address proof of payment.
ISOLATION + AUTHORITY
Tenant, workspace, merchant, product, customer, invoice, checkout, collection wallet, payment, custody, treasury settlement, tax or compliance policy, and finality remain distinct. Merchant configuration or invoice state cannot authorize wallet signing, move funds, prove settlement, or grant publisher, matching, or trading authority. This planning record grants no runtime authority, and only deployed OpenAPI can define an executable public contract.
BEFORE YOU CALL
- First confirm that this operation is marked implemented-contract and exists in the currently deployed OpenAPI document; until then, no production request is valid.
- Its capability-registry profile is provisional integration guidance, not an executable request schema.
- Authenticate at the documented boundary: bearer+scope.
- Treat the proposed wallet_uuid (path), expected_wallet_version (body), expected_available_balance (body), settlement_currency (body), destination_reference (body), fee_policy (body), reason (body), step_up_token (body) as planning input only; re-generate the request from deployed OpenAPI before making a call.
- Use one Idempotency-Key only for retries of the same byte-equivalent logical mutation.
WHAT TO DO NEXT
- Keep this operation disabled in clients, agents, SDKs, and workflow automation while it remains planned-contract.
- Use the stated owner, lifecycle, authority boundary, and provisional settle rotational wallet profile to prepare requirements and conformance tests without sending a request.
- Monitor the capability registry for implemented-contract, then re-fetch deployed OpenAPI and validate its exact security, parameters, schemas, responses, and agent metadata before enabling the integration.
AGENT GUIDANCE
- Never call this planned contract, include it in an executable tool registry, or infer runtime availability from this readable page.
- Its capability-registry profile is provisional integration guidance, not an executable request schema.
- Use settle rotational wallet only for the purpose and lifecycle stage described by this operation; do not treat it as authority for an adjacent action.
- Treat the proposed wallet_uuid (path), expected_wallet_version (body), expected_available_balance (body), settlement_currency (body), destination_reference (body), fee_policy (body), reason (body), step_up_token (body) as planning input only; re-generate the request from deployed OpenAPI before making a call.
- Distinguish merchant readiness, product availability, invoice issuance, checkout presentation, payment observation, wallet synchronization, treasury settlement, cancellation, and reconciliation.
- After a timeout or conflict, read authoritative state before deciding whether an equivalent retry is safe.
- When implementation lands, discard generated requests based on this planning record and rebuild them from the deployed OpenAPI operation.