Skip to content
1Claw Academy
Curriculum/Transactions & Treasury2 minAdvanced · Lesson 7 of 16

Lab: pay a paywall without funding a wallet

Lab

Run the actual 1claw pay flow against a mock paywall in dev mode: challenge capture, digest binding, the paid retry, all without a chain or a cent.

Everything in the previous lesson was about what the vault refuses to sign and why. This lab runs the part that is safe to run without any of that infrastructure: the flow itself, end to end, against a local paywall.

Concept

ONECLAW_PAY_DEV=1 short-circuits the vault entirely. The dev signer never contacts it and produces a header no real paywall would ever honour, precisely so this exercise cannot be mistaken for a real payment.

  1. 1

    Clone the example and start the mock paywall. It listens on :4022 and returns a real, spec-shaped 402.

    bash
    git clone https://github.com/1clawAI/1claw-examples.git
cd 1claw-examples/x402-pay-cli
node paywall.mjs &
  2. 2

    Confirm the 402 shape yourself before paying it. This is the same accepts[] structure from the earlier x402 lesson: scheme, network, maxAmountRequired, payTo, asset.

    bash
    curl -s -i http://localhost:4022/premium
  3. 3

    Pay it, in dev mode. --agent takes any string here; dev mode never asks the vault to resolve it.

    bash
    ONECLAW_PAY_DEV=1 1claw pay --agent any http://localhost:4022/premium
Tip

Real output from this exact command: three status lines (402, signed, 200) followed by the paid resource. The recipient shown after the 402 line is the dev signer's placeholder address, not the paywall's real payTo, which is the tell that nothing here touched a chain.

Run it a second time. The output is identical: the mock paywall issues a fresh, spec-shaped 402 every call, and dev mode always signs instantly with no passkey wait. Against a real vault, the first payment in strict mode would instead print an authorize link and wait for a passkey touch before the signed line ever appears, and --mode session would create a spending grant on that touch so later payments inside its cap and window need no further prompt.

That gap, between what dev mode lets you run in two minutes and what a real vault actually enforces, is the lesson. A digest that binds the transfer value, a grant that cannot exceed the agent's own configured maximum, an allowlist that means nobody when it is empty: none of that is visible from the CLI output of a successful payment. It only shows up when something is refused, which is exactly why the earlier lesson's scenario exercise mattered more than this lab's happy path.

Check your understanding

2 questions
1

In this lab's output, why does the recipient shown after the 402 line differ from the paywall's real payTo address?

2

What would differ if this lab ran against a real, pay-enabled agent instead of dev mode?