Nava Gateway payment lifecycle

The preview inserts a policy gate after structural x402 verification and before merchant settlement.

Resource-server path

1. The resource gate deterministically quotes an exact EIP-3009 USDC payment for Base or Base Sepolia.
2. If Guardian applies and verification fees are enabled, it obtains a separate fee requirement from the facilitator's /verification/quote endpoint.
3. With no X-PAYMENT header, the gate returns 402 with the merchant requirement and optional verification requirement.
4. The payer signs the merchant authorization and, when quoted, a separate verification-fee authorization.
5. The gate calls /verify. The facilitator pins the configured network/asset, enforces a minimum value when configured, verifies the merchant payment, validates the fee against a fresh authoritative quote, and then asks Guardian to evaluate the merchant payment.
6. On a terminal approved or rejected verdict, the facilitator settles the verification fee when one was required. A timeout/error is not terminal and does not settle the fee.
7. On rejection, the gate returns 402; the merchant payment is not settled.
8. On approval, the facilitator records the exact approved payment. /settle consumes that record before submitting the merchant transfer. Redis uses atomic GETDEL; the default in-memory implementation does not make its read/delete sequence atomic under concurrent calls.
9. After successful merchant settlement, the gate returns 200 and X-PAYMENT-RESPONSE.

The two payments are independent authorizations. Only the merchant payment is policy-gated. The fee pays for a completed verification and can therefore settle after either terminal outcome; the merchant receives funds only after approval.

Because approval consumption precedes merchant broadcast, a settlement failure or resource-gate 502 requires a new /verify before another /settle. A previously settled verification fee may require a fresh fee authorization for that new verification. Do not blindly retry /settle; first reconcile any uncertain on-chain result, then re-run verification for the exact payment.

Existing-facilitator path

1. Your verifier validates the x402 payment.
2. withGuardian short-circuits an invalid base result.
3. For a valid base result, verifyPayment maps the payment to a preview PaymentAction and waits within configured bounds.
4. withGuardian reports valid only when the returned verdict outcome is approved; rejected, timeout, and error results fail closed.
5. Your existing settlement path runs only after that valid response.

This wrapper path does not add fee settlement or an approval store. Those controls remain the responsibility of the integrating facilitator.

Outcome handling

Read verdict.outcome, not the wording of humanReason and not a reason-code allowlist. Preserve any unknown reasonCode for diagnostics. Missing, pending, malformed, timed-out, or error results are not approval.