Add optional user funding to an existing AI credit app

Your app already sells AI credits. Customers have balances, receipts, and expectations about what those credits buy. Adding user-funded AI should not turn their previous purchases into a migration problem.

Treat AI Pass as an optional funding route before considering any broader pricing change. It connects a user-funded wallet through OAuth; it is not a provider-key BYOK field. Keep your current app login, deployment, and credit system working while you introduce it. The AI Pass integration guide explicitly calls for preserving existing billing behavior.

Write the customer promise first

A useful launch notice says: "You can keep using your existing app credits. AI Pass is an optional way to fund supported AI actions. Connecting does not convert, remove, or spend your existing credit balance."

Make that statement an acceptance criterion. Do not merely place it in an email while changing the default funding source underneath customers.

Keep purchased credits, promotional credits, subscription allowances, and wallet-funded usage distinguishable in your records. They may have different terms. Do not invent an exchange rate between an app credit and a wallet currency amount, or shorten previously promised validity because a new route exists.

If a separate commercial change is necessary, communicate it separately and honor applicable commitments. An integration rollout is not a shortcut around those obligations.

Add a route selector without rewriting the ledger

Represent the chosen funding source explicitly on each operation. An existing action should keep using app credits unless the user chooses otherwise. For an AI Pass operation, record its route and available usage references without subtracting app credits for the same inference.

A software fee may still exist, but it must be a separately disclosed charge rather than an accidental double debit. Keep provider-key BYOK available if the product already supports it.

Place the selector near the paid action and show both the current app-credit balance and connection state where useful. Never silently fall back from an empty wallet to app credits. Ask: "Use your app credits for this attempt?" and show the applicable cost basis before proceeding.

For browser integrations, start with the SDK documentation. Use the REST documentation when the architecture calls for backend OAuth. Neither path requires moving the app to another host.

Roll out by cohort and action

The following is a proposed rollout plan, not a report of an actual deployment:

Cohort	Enabled behavior	Evidence required before expansion
Internal testers	One supported action with explicit route choice	Existing credit debits remain correct; wallet actions do not debit those credits
Invited volunteers	Opt-in connection on the same action	Cancellation restores work; funding labels match operation records
Small existing-customer cohort	Optional connection while old balances remain usable	No unexplained balance changes or route confusion in reviewed cases
New customers	Funding choice explained during first use	Users can identify who funds the action and recover failed attempts
Wider release	More supported actions after individual checks	Each action passes billing, recovery, and support checks

Keep cohort assignment stable. A customer should not see the option disappear because a random experiment bucket changes on refresh. Track eligibility separately from their chosen default.

You can observe existing app-credit traffic without sending duplicate model requests. Do not "shadow test" by generating a second paid result through the wallet.

Define stop conditions before launch

Stop expansion if a wallet operation also consumes app credits, a funding label disagrees with the stored route, cancellation starts generation, or an unknown outcome triggers an automatic paid retry.

Track connection completion, first successful action, recovery after failure, route-specific support requests, and credit-ledger discrepancies. Compare cohorts carefully: enthusiastic volunteers are not a reliable proxy for all existing customers.

A low connection rate may mean the offer is unnecessary for that cohort. It is not permission to make the old route harder to find.

Roll back new dispatch, not customer history

Use separate controls for showing the option and accepting new wallet-funded operations. If there is a serious defect, block new affected dispatches with a clear message. Continue displaying saved results and reconciling requests already in flight.

Restore the previous app-credit flow only when the customer explicitly chooses it for a new attempt. Do not reroute an unresolved wallet operation after a timeout. That can turn a rollback into a duplicate purchase.

Preserve operation records, original balances, and the data needed to investigate. Avoid destructive schema changes during the early rollout so the older application path can still read its records. Decide how customers can disconnect even while new connections are disabled.

Before expanding again, test with an account that has paid credits, an expired connection, and a saved unfinished draft. The migration succeeds when that customer can still use what they already bought and understands exactly what the optional new route changes.