docs(specs): update auth-capture evm spec

specs/schemes/authCapture/scheme_authCapture.md → specs/schemes/auth-capture/scheme_auth_capture.md

@@ -1,12 +1,12 @@
-# Scheme: `authCapture`
+# Scheme: `auth-capture`
 
 ## Summary
 
-`authCapture` is a payment scheme where funds can be held and settled later. The client authorizes a maximum amount, and the facilitator submits it — either locking funds in escrow for later settlement (two-phase) or sending them directly to the receiver with refund capability (single-shot).
+`auth-capture` is a payment scheme where funds can be held and settled later. The client authorizes a maximum amount, and the server or facilitator submits it — either locking funds in escrow for later settlement (two-phase) or sending them directly to the receiver with refund capability (single-shot).
 
-The **captureAuthorizer** is the entity authorized to authorize, capture, void, refund, or charge a payment. In a facilitator-submits flow, that's either the facilitator itself or any smart contract that ends up calling the underlying escrow.
+The **captureAuthorizer** is provided by the server and is the entity authorized to authorize, capture, void, refund, or charge a payment. In a facilitator-submits flow, that's either the facilitator itself or any smart contract that ends up calling the underlying escrow.
 
-Unlike `exact`, which has no built-in mechanism for returning funds, `authCapture` supports returning funds to the client through void, refund, and reclaim.
+Unlike `exact`, which has no built-in mechanism for returning funds, `auth-capture` supports returning funds to the client through void, refund, and reclaim.
 
 ## Example Use Cases
 
@@ -16,14 +16,14 @@ Unlike `exact`, which has no built-in mechanism for returning funds, `authCaptur
 
 ## Settlement Paths
 
-The scheme supports two settlement paths, selected via `extra.autoCapture`:
+The scheme supports two settlement paths, selected by the operation `type` passed to the facilitator:
 
-| `autoCapture`     | Behavior                                                                                                                     |
-| :---------------- | :--------------------------------------------------------------------------------------------------------------------------- |
-| `false` (default) | Two-phase. Funds held in escrow. CaptureAuthorizer can capture, void, refund. Client can reclaim if capture deadline passes. |
-| `true`            | Single-shot. Funds sent directly to receiver. CaptureAuthorizer can refund post-settlement.                                  |
+| `type`      | Behavior                                                                                                                     |
+| :---------- | :--------------------------------------------------------------------------------------------------------------------------- |
+| `authorize` | Two-phase. Funds held in escrow. CaptureAuthorizer can capture, void, refund. Client can reclaim if capture deadline passes. |
+| `charge`    | Single-shot. Funds sent directly to receiver. CaptureAuthorizer can refund post-settlement.                                  |
 
-### Two-phase (`autoCapture: false`, default)
+### Two-phase (`type: "authorize"`)
 
 ```
 AUTHORIZE → RESOURCE DELIVERED → CAPTURE / VOID → (REFUND)
@@ -35,7 +35,7 @@ AUTHORIZE → RESOURCE DELIVERED → CAPTURE / VOID → (REFUND)
 4. **Reclaim**: If the capture deadline passes without action, the client can reclaim directly.
 5. **Refund**: After capture, the captureAuthorizer can refund within the refund window.
 
-### Single-shot (`autoCapture: true`)
+### Single-shot (`type: "charge"`)
 
 ```
 CHARGE → RESOURCE DELIVERED → (REFUND)
@@ -47,6 +47,12 @@ CHARGE → RESOURCE DELIVERED → (REFUND)
 
 No capture, void, or reclaim — funds are never held in escrow.
 
+## Server Operations
+
+Facilitators MUST provide a mechanism for servers to perform `authorize`, `charge`, `capture`, `void`, and `refund` operations. Servers select the operation by passing a `type` field to the facilitator's `verify` and `settle` endpoints. Network bindings define the payload fields required for each operation.
+
+Facilitators MAY require proof that the server controls the signed authorization's `payTo` address before performing server-initiated operations. Facilitators that require this proof MUST signal it with `extra.serverAuthorizationRequired` in the payment requirements. Network bindings may define a `serverAuthorization` field for this purpose.
+
 ## Core Properties
 
 ### Fund Safety
@@ -69,15 +75,15 @@ Two absolute-timestamp deadlines govern the payment lifecycle (network-specific
 
 ## Relationship to `exact`
 
-| Aspect     | `exact`            | `authCapture`                                                         |
+| Aspect     | `exact`            | `auth-capture`                                                        |
 | :--------- | :----------------- | :-------------------------------------------------------------------- |
 | Settlement | Immediate transfer | Via escrow (two-phase) or direct with refund capability (single-shot) |
 | Refundable | No                 | Yes (both paths)                                                      |
 | Fee system | None               | Configurable (min/max bounds, client-signed)                          |
 
 ## Appendix
 
-Network-specific implementation details (contracts, signature formats, verification logic) are in per-network documents: `scheme_authCapture_evm.md` (EVM).
+Network-specific implementation details include contracts, signature formats, and verification logic in per-network documents.
 
 ### References