Skip to main content
By the end of this page you can verify your seller configuration at boot with one call, and run a full pay-and-catalog loop on your own machine before you put anything on a public host. This uses preflight from @rail402.dev/sdk (also exported from @rail402.dev/seller-helpers).

​
What preflight checks

A payment fails for boring reasons: the receiver has no trustline to the asset, or the payTo account does not exist yet. Each of those fails a stranger’s first payment, not yours, so you never see it. preflight checks your payTo account and its asset trustline against live testnet state on Horizon and hands you back coded findings before you serve a single request.
preflight returns { ok: boolean, findings: [{ code, reason, severity }] }. Each finding has a machine-readable code, a non-null reason a human can read, and a severity. A blocking finding, like a receiver with no trustline to the asset, sets ok to false. A warning, like a transient network problem reaching Horizon, is reported but does not fail the check, so a Horizon blip never stops your server from booting.
Call preflight at boot. Catching a missing trustline on your own account when the process starts is much cheaper than discovering it when a buyer’s first payment is refused.

​
Test the whole loop locally

You do not need a public host to test the full path. Run a facilitator on your own machine, point your seller at it, and pay yourself.
1

Run a local facilitator

The CLI generates an ephemeral signer, friendbot-funds it, and serves on port 4022 with zero configuration. Allow loopback seller URLs so it will catalog a local endpoint.
2

Point your seller at it

In your resource server, set the facilitator URL to the local instance.
3

Pay your own endpoint

Pay the local route with the buyer helper, opting in to private hosts so it will pay a loopback URL. maxAmount is an atomic-unit string (7 decimals), so "100000" is 0.01 USDC.
4

Confirm it cataloged

Search the local facilitator for words from your description.
BAZAAR_ALLOW_PRIVATE_HOSTS and allowPrivateHosts exist for local testing only. On a real deployment, leave them off. The facilitator soft-drops private-host URLs from the catalog by design, which is what stops a hostile client from listing an internal address.

​
Wire-level conformance

To prove your deployment behaves at the wire level, run the conformance harness. @rail402.dev/conformance points the upstream x402 end-to-end suite at your facilitator and reports whether a stock, unmodified client settles against it. See Conformance.

​
Next steps

Charge for an endpoint

The full seller quickstart, from paywall to first settled payment.

Get discovered

Write metadata an agent can act on, and confirm your listing landed.

Conformance

Wire-test your deployment against the upstream e2e suite.

Self-facilitation

Run verify and settle in-process instead of pointing at a hosted facilitator.

​
When it fails

Every finding and every payment rejection carries a machine-readable code and a non-null reason. The ones you will meet most often are invalid_exact_stellar_payload_missing_trustline_recipient (the receiver has no trustline to the asset) and config_no_signer (no secret was configured for a call that needs to pay). Every code and its reason is in Errors.