Payment Auth
Payment auth is a lens for systems where the durable object is not the asset but the permission to keep paying, keep serving, or keep a merchant flow alive.
Questions worth asking:
- What gets authorized: a paid request, wallet session, account grant, checkout mandate, or hosted spend policy?
- Who verifies it later: merchant server, wallet, facilitator, grant server, or PSP?
- How long does that authority live, and who can narrow, revoke, retry, or reroute it?
- Is the real leverage in moving money, or in controlling the object that says future payment attempts are still allowed?
Canonical cut
- Request-native paid access: x402
- Grant-and-account rail: open-payments plus gnap
- Merchant-session rail: walletconnect-pay
- Hosted operator rail: stripe and bridge-xyz
- App-owned signing rail: privy and turnkey
Keep the auth object legible
- In the request-native case, the permission travels with the request.
- In the grant-and-account case, the durable object is the relationship, not the one-off checkout click.
- In the merchant-session case, the control surface is retries, support, refund flow, and packaged route state.
- In the hosted-operator case, the control surface is merchant onboarding, payout-recipient state, and policy middleware.
- In the app-owned signing case, the control surface moves into backend wallet policy, session defaults, and recovery assumptions.
- Keep circle-usdc separate in your head. That is issuer rail control, not the auth object itself.