This guide assumes no prior Tari or Ootle experience. It starts from downloading the wallet daemon on a blank server and ends with a completed test payment in WooCommerce. Every link is clickable. Every command is copy-paste ready.

1. Overview — how the pieces fit together

The plugin is one of three moving parts. WooCommerce handles the storefront and orders. The wallet daemon holds your keys and signs transactions. The indexer reads on-chain state and streams events. Nothing works until all three are running and reachable.

Checkout flow, end to end: customer clicks “Pay with Ootle” → plugin calls the wallet daemon’s JSON-RPC to create a payment → customer pays on the Ootle network → an OrderPlaced event lands in the indexer → your webhook listener POSTs to ?wc-api=ootle_webhook → the plugin verifies the signature and marks the order complete.

2. Install the Ootle wallet daemon

The wallet daemon is the only process that holds your private keys. It signs every transaction the gateway sends. Everything else is read-only. Run it somewhere your WordPress server can reach over the network, and nowhere else.

2.1 · Download the wallet daemon

The release ships a standalone tari_ootle_walletd binary per platform. Note: there is no tari_ootle_wallet_cli binary in the release — the CLI is not published as a prebuilt asset. You interact with the daemon directly over JSON-RPC (which is what the plugin does).

Get the current filenames and hashes from the releases page — the build hash (9c62606) changes with each release.

# Linux example — paste the hash from the release's .sha256 file
echo "8cfdae03cc7dc7987752b2f1ae94046fc5c15258e1e26e0587977f7230712fae  tari_ootle_walletd-0.45.0-9c62606-linux-x86_64" | sha256sum -c -

2.2 · Choose your network

2.3 · Start the daemon

This command runs the daemon on the esmeralda testnet, bound to localhost so only this machine reaches it. The web UI is served on the same host at port 5100.

tari_ootle_walletd --network esmeralda --listen-on 127.0.0.1:5100 --authentication none --enable-vite-dev-port 5173

Open http://localhost:5100 in your browser to reach the wallet web UI — create accounts, check balances, claim testnet funds, and manage API keys from there.

3. Create an account and fund it

3.1 · Create a merchant account

There is no wallet CLI binary in the release — you drive the daemon over its JSON-RPC endpoint. First bootstrap a bearer token (with --authentication none, this needs no passkey), then create the account.

# 1. Bootstrap an Admin bearer token (auth=none: no passkey, no WebAuthn)
TOKEN=$(curl -s -X POST http://127.0.0.1:5100/json_rpc -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"auth.request","params":{"permissions":["Admin"],"credentials":{"None":null}},"id":1}' \
  | python3 -c "import sys,json; print(json.load(sys.stdin)['result']['token'])")

# 2. Create the merchant account (returns the account + its Ootle address)
curl -s -X POST http://127.0.0.1:5100/json_rpc -H "Content-Type: application/json" \
  -H "Authorization: Bearer $TOKEN" \
  -d '{"jsonrpc":"2.0","method":"accounts.create","params":{"name":"merchant"},"id":2}' \
  | python3 -m json.tool

Note the owner_public_key and the otl_esm_… address from the response — you paste the public key into the plugin’s Merchant Public Key field later.

3.2 · Claim testnet funds (testnet only)

Two ways, both free on esmeralda:

The account argument is a tagged enum, not a bare name — pass the component address as {"ComponentAddress":"…"}. A claim also needs a max_fee.

ADDR="component_4293145b…"  # your account's component_address
curl -s -X POST http://127.0.0.1:5100/json_rpc -H "Content-Type: application/json" \
  -H "Authorization: Bearer $TOKEN" \
  -d "{\"jsonrpc\":\"2.0\",\"method\":\"accounts.create_free_test_coins\",\"params\":{\"account\":{\"ComponentAddress\":\"$ADDR\"},\"max_fee\":1000},\"id\":3}"

3.3 · Confirm your balance

curl -s -X POST http://127.0.0.1:5100/json_rpc -H "Content-Type: application/json" \
  -H "Authorization: Bearer $TOKEN" \
  -d "{\"jsonrpc\":\"2.0\",\"method\":\"accounts.get_balances\",\"params\":{\"account\":{\"ComponentAddress\":\"$ADDR\"}},\"id\":4}" \
  | python3 -m json.tool

You must see a non-zero balance before moving on. An empty account cannot pay transaction fees, and every Ootle transaction pays fees in TARI.

4. Mint an API key

The plugin authenticates to the wallet daemon with a long-lived, permission-scoped API key. An Admin mints it once; the plugin then presents it as a Bearer token on every JSON-RPC call. There is no interactive login, no JWT exchange, and no session to refresh.

4.1 · How the key works

4.2 · Choose the smallest scope set

Grant only the permissions the plugin actually needs. An agent cannot self-promote: permissions come from the stored key row, not from anything the plugin sends.

4.3 · Create the key via Web UI (optional)

The web UI works too, but only if WebAuthn can reach it — open http://localhost:5100/api-keys and log in via passkey. If you hit an “invalid domain” error (WebAuthn rejects non-localhost origins), use the JSON-RPC method in 4.4 instead — it needs no browser at all.

4.4 · Create the key over JSON-RPC (no CLI, no passkey)

With --authentication none, mint the key directly against the daemon using the bootstrap token. The raw key prints to the response once — pipe it straight into your secret store.

# Basic key with two scopes
curl -s -X POST http://127.0.0.1:5100/json_rpc -H "Content-Type: application/json" \
  -H "Authorization: Bearer $TOKEN" \
  -d '{"jsonrpc":"2.0","method":"auth.create_api_key","params":{"name":"wordpress-gateway","permissions":["AccountInfo","TransactionGet"]},"id":3}' \
  | python3 -m json.tool

# With an expiry (unix seconds; None = never)
curl -s -X POST http://127.0.0.1:5100/json_rpc -H "Content-Type: application/json" \
  -H "Authorization: Bearer $TOKEN" \
  -d '{"jsonrpc":"2.0","method":"auth.create_api_key","params":{"name":"wordpress-gateway","permissions":["AccountInfo","TransactionGet"],"expires_at":1893456000},"id":4}' \
  | python3 -m json.tool

# Granting Admin requires the explicit confirm_admin flag
curl -s -X POST http://127.0.0.1:5100/json_rpc -H "Content-Type: application/json" \
  -H "Authorization: Bearer $TOKEN" \
  -d '{"jsonrpc":"2.0","method":"auth.create_api_key","params":{"name":"full-access","permissions":["Admin"],"confirm_admin":true},"id":5}' \
  | python3 -m json.tool

4.5 · What the daemon protects you from

• Wrong, revoked, or unknown key — identical error message and timing for all three; an attacker cannot enumerate valid hashes.
• Out-of-scope request — the stored scope set is enforced against every endpoint; the request fails with InsufficientPermissions.
• Non-admin minting keys — rejected; only Admin reaches the key-management endpoints.
• Expired key — silently filtered out; the next request fails exactly like a revoked key.

5. Install the plugin

6. Configure the plugin

Go to WooCommerce → Settings → Payments. You’ll see the Payment providers list — find the Ootle Payment Gateway row (badged “Test mode”) and click its Manage button to open the settings form. Fill in every field below, then Save changes at the bottom of the page.

6.1 · Stealth (Confidential) Payments — the six fields

Checking Stealth (Confidential) Payments turns on private settlement: every order settles to a
one-time stealth address with a blinded amount (Pedersen commitment) and an encrypted on-chain
memo. Six fields control this. Fill them from your wallet daemon’s JSON-RPC responses.

Getting the values from the daemon

With your Admin token from section 3, run these against http://127.0.0.1:5100/json_rpc:

{
  "jsonrpc": "2.0",
  "method": "accounts.list",
  "params": { "offset": 0, "limit": 10 },
  "id": 1
}

Copy component_address → Merchant Account, and owner_public_key → Merchant Public Key.

{
  "jsonrpc": "2.0",
  "method": "accounts.associate_stealth_resource",
  "params": {
    "account": { "ComponentAddress": "component_…" },
    "resource_address": "resource_…"
  },
  "id": 2
}

The response returns the resource address and view_key. Paste them into
Resource Address and Resource View Key.

{
  "jsonrpc": "2.0",
  "method": "accounts.get_balances",
  "params": { "account": { "ComponentAddress": "component_…" } },
  "id": 3
}

Ensure the account holds enough TARI to cover the Max Fee you set, plus settlement. On testnet,
claim from the faucet with accounts.create_free_test_coins.

6.2 · Finding your API base URL

6.3 · Generate a webhook secret

Run this in your terminal and paste the output into the Webhook Secret field. This secret signs outgoing webhook payloads so the plugin can prove they came from a trusted source. It is never sent to the wallet daemon.

openssl rand -hex 32

7. Connect the webhook

Without a webhook, orders stay in “pending” forever — the plugin never learns the payment succeeded. Your indexer listener (or any monitoring service) must POST to the endpoint below whenever an on-chain payment event matches an order.

The payload carries an event type and a session id. The plugin looks up the order by session id and updates its status. Six event types are supported:

8. Test a payment

8.1 · Add a test product

8.2 · Place a test order

8.3 · Troubleshoot connection failures

9. Going to production

9.1 · Pre-launch checklist

• Switch the network — restart the daemon with --network mainnet.
• Turn off Test Mode — uncheck it in plugin settings so SSL verification is enforced.
• Update the API Base URL — point at your production daemon endpoint.
• Use HTTPS — front the daemon with a reverse proxy and a valid certificate.
• Rotate the API key — mint a production key with production scopes; revoke the testnet key.
• Set a key expiry — long but finite, so a leaked key eventually dies.
• Fund the account — confirm the merchant account has mainnet TARI for fees.
• Place one live order — a small real purchase before announcing the gateway.

9.2 · Security rules that are not optional

10. Reference — settings at a glance

11. Where to get help