Alchemy Wallet APIs: Transaction Execution After Account Kit

An application already has customer logins and wallet balances. Its next feature lets an assistant execute an approved purchase without asking the customer to buy a gas token first. The integration question is not simply which SDK sends the transaction: it is which system authenticates the customer, which key authorizes spending, and who pays when execution is retried.

Research boundary: official documentation reviewed November 1, 2026. This is an architecture and migration analysis, not a report of a wallet migration or a funded payment test.

Start with the current product, not an old Account Kit tutorial

Alchemy’s deprecation notice covers Account Kit’s embedded wallets, signer support, key management and associated login/UI components. It directs new integrations to Wallet APIs with a separately chosen signer. That is a material change for a team expecting Alchemy to provide the entire login-to-payment stack.

The Wallet APIs overview describes a prepare, sign, submit and track lifecycle. The signer owns the login-and-key side; Alchemy supplies transaction infrastructure. For an agent product, make that split visible in the architecture review. An outage in authentication, a refused signature and a rejected transaction are different incidents with different owners.

Follow one approved purchase through the stack

Conceptual integration flow, not an observed transaction. The application must still connect the payment receipt to the merchant’s delivery record.

In this design, the application checks the order before preparing calls. A signer or a previously authorized session supplies the necessary authority. The sponsorship decision determines whether the configured service pays execution fees; it does not decide whether the goods were worth buying. After submission, the product tracks execution and separately updates its order state.

This separation also helps support teams. “Could not sign” should not produce the same retry instruction as “submitted but still pending.” A new signature request can be unnecessary, or dangerous, when an earlier purchase is already on its way to settlement.

Address continuity deserves a migration test of its own

Alchemy documents both EIP-7702 and non-7702 operation. The former can add smart-account behavior to the signer’s existing address; a non-7702 integration uses a separate smart-wallet address. Signer capability therefore affects more than developer ergonomics.

Before changing an existing application, inventory addresses used for deposits, token balances, approvals, order history and customer support. Then establish which remain valid for the selected account mode and network. Do not assume that swapping an SDK preserves every relationship attached to an address. A successful login says little about whether the application is now reading the correct account’s funds.

For a new project, resolve the account mode before presenting a permanent deposit address. For an existing project, treat the address map as migration data, with explicit rollback and support procedures. These are our implementation recommendations, not a claim that Alchemy automatically migrates those records.

There are two budgets to control

The gas sponsorship documentation describes policies and USD billing for sponsored gas. It also distinguishes sponsorship routes and access conditions: at review time, mainnet onchain paymaster sponsorship and ERC-20 gas payments were generally Enterprise features, with exceptions. Verify the actual route available to your account before designing around a testnet demo.

The customer’s purchase allowance and the application’s gas allowance are separate budgets. A small authorized transfer can still generate repeated infrastructure work. Conversely, an exhausted sponsorship budget may prevent a perfectly valid purchase from executing. The product needs a deliberate response to each condition, rather than silently switching who pays.

Decision	What to record before release
Who signs?	Provider, account mode, recovery owner and supported network
What may the agent spend?	Token, cumulative allowance, allowed operations and expiry
Who sponsors execution?	Policy, billing owner, limits and refusal behavior
When is an order paid?	Required transaction state and merchant reconciliation rule

Read session permissions at their actual granularity

Alchemy’s session-key reference distinguishes token allowances, contract access and function-specific permissions. Its ERC-20 allowance covers cumulative transfers and approvals; broad contract access is wider than a single function. A root permission grants unrestricted access.

For the hypothetical shopping assistant, inspect the exact grant rather than showing a generic “agent enabled” switch. Where the supported permission cannot express a required merchant or operation restriction, keep an additional enforced control or decline that workflow. Do not solve an inconvenient refusal by broadening the grant without a fresh user decision.

Retry execution without creating another order

The retry guide describes replacement of pending calls and warns that the original can still be included while a replacement is being attempted. A retry response alone is therefore not the final payment record.

Our recommendation is to retain one business-order identifier across submission attempts, preserve the relationship between call IDs and transaction hashes, and reconcile the chain outcome before opening a replacement purchase. Wallet APIs can reduce transaction plumbing; the application still owns the meaning of “buy once.” See the idempotency guide and Alchemy reference for the surrounding design decisions.