21.1. Wallet Browser Integration Manual

Websites can advertise Taler actions and explicitly request browser-wallet features without depending on a particular extension identifier. All page integrations are subject to the wallet user’s preferences. Websites must retain an ordinary Taler link or another fallback because extension injection and link interception are not available in every browser or navigation path.

21.1.1. Advertising a Taler action

A page can advertise a wallet action in its document head:

<meta name="taler-uri" content="taler://withdraw/bank.example/operation-id">

The extension validates the URI before opening or presenting it. The first taler-uri element in document order is the page’s advertised action; an invalid first element is not skipped in favor of a later element. Ordinary Taler links are handled separately when activated.

When automatic opening is disabled, the extension can expose the current page’s validated action through its popup. Metadata inserted, removed, or changed in the document head is observed; the page body is not scanned.

21.1.2. Requesting browser-wallet features

Additional features are requested with a comma-separated list:

<meta name="taler-support" content="uri, callback, api">

Tokens are trimmed and compared case-insensitively. Unknown tokens are ignored. Each known feature is independently controlled by the user’s wallet settings:

uri

Handle a primary-button activation of a link whose href is a recognized Taler action. Pages must retain the Taler URI in href so that native handlers and copy-link behavior remain available.

callback

If window.talerCallback is a function, call it with {present: true} when the WebExtension becomes available. Callback execution is best-effort. A page must not rely on receiving a later present: false notification.

api

Inject the legacy-compatible window.taler object asynchronously. A compatibility integration that needs to detect injection should also request callback and wait for it. The object currently has no supported callable methods; new integrations should use taler-uri, the uri feature, and talerCallback instead.

Without taler-support, the page receives no callback or API and its links are not intercepted. Advertising an action with taler-uri remains independent of these requested features.

21.1.3. The page API

The api feature makes the legacy-compatible window.taler object available after asynchronous injection. The extension does not overwrite a value owned by the page. There are currently no supported callable methods on this object. Implementation-specific properties are outside the website contract and must be ignored. In particular, the object exposes no wallet RPC, balance, transaction, identity, or storage capability.

window.talerCallback is supplied by the website and is separate from the injected object. It is the supported way to learn that requested integration became available; it is not a wallet-provided API method.

21.1.4. Security and privacy

The content script only reads relevant head metadata and user activations; it cannot access wallet-core or wallet data. Requests cross the extension runtime channel, and the background rechecks both the sender and the current preference before acting. Every URI candidate is parsed authoritatively before it is stored or opened.

The compatibility entry point must be page-accessible and therefore treats all URL input as untrusted. It rejects framing and does not connect to the wallet host or render wallet controls inside a frame. On Chromium, a site that already knows the stable extension identifier may still be able to probe that resource. Disabling callback and API integration prevents the standard presence signals but cannot make the installation undetectable by every browser-specific probing technique.

Implementation history and rejected alternatives remain recorded in DD 39: Taler Wallet Browser Integration Considerations.