Payment flow
A Spendkit approval is permission for one exact payment. The Agent's linked wallet still sends the transaction, and the Router checks the rules again before moving USDG.
The Agent proposes an amount, a recipient, and a token such as USDG.
Preview returns ALLOW or DENY without sending a transaction. Authorization, if allowed, is short-lived and tied to those exact details.
The wallet submits the exact transaction and pays gas. The Router checks the current Policy, then transfers USDG from that wallet.
The Agent records the transaction hash. Spendkit reconciles the receipt and shows the resulting status.
The Agent does not receive an authorization for this payment and should stop. A direct wallet transfer made outside Spendkit is outside these Policy checks.
Exact Runtime sequence
- Call
spendkit_get_connectionandspendkit_get_policyto confirm identity, wallet, network, and current limits. - Call
spendkit_preview_paymentwith a decimal-string amount and recipient. A denied preview is read-only. - When the Agent genuinely intends to pay, call
spendkit_authorize_paymentwith a stableidempotencyKey. Checkallowed,intentId,authorization.paymentWallet, and the returnedtransaction. - The bound Payment Wallet submits exactly that Router transaction. The reference local demo asks the user to confirm the displayed amount, recipient, wallet, and chain before submission.
- Call
spendkit_record_payment({ intentId, txHash }), thenspendkit_get_payment_status({ intentId }). A successful authorization or broadcast is not yet a confirmed payment.
When a result is uncertain
Use one idempotency key per logical payment. If the wallet or network does not clearly report whether a transaction was submitted, inspect the existing intent, transaction hash, and payment status before doing anything else. Do not blindly send a second blockchain transaction. A failed or reverted receipt needs investigation before another attempt.