AWaaS_

Three payment rails.
One call.

Visa Intelligent Commerce, Mastercard Agent Pay, and Coinbase x402 all shipped inside twelve months. None of them speak to each other. AWaaS is the neutral vault, policy, and routing layer that sits above all three, so an agent integrates payments once instead of three times.

Request SDK accessWhy us
trace txn_7f3a91  ·  rental application fee  ·  $50.00
0 msagent calls wallet.pay({ amount: 50, merchant: "mgmt_co", rail: "auto" })sdk
+38 mspolicy application_fee matched — under daily cap, merchant allowlistedpass
+61 msrouter selected visa_icc — card-preferred merchant, above stablecoin thresholdroute
+184 msvault returned agent token tok_••••4192 — HSM decrypt, single-usevault
+2.9 sPOST /acp/v1/instructions — purchase intent accepted201
+16.4 spasskey approval signed on device — 13.5 s waiting on humanauth
+19.1 sPOST /credentials — controls locked to merchant + amount + single use200
+23.2 ssettled on VisaNet — receipt rcp_11c8 returned to agentok
total 23.2 s  ·  system latency 9.7 s  ·  human 13.5 srails available: visa_icc · agent_pay · x402
fragmentationThe problem

Three rails, three token models, zero interop.

A team building an AI agent that needs to spend money today has to pick a side or build three integrations. Each rail has its own token lifecycle, its own authentication ceremony, its own webhook schema, and its own compliance surface. That work is undifferentiated for every single one of them.

Visa ICC
Instrument
Card-based fiat
Auth
Passkey, step-up on enroll
Surface
/acp/v1/instructions
Mastercard Agent Pay
Instrument
Card-based fiat
Auth
Agentic tokens
Surface
Agent token API
Coinbase x402
Instrument
USDC on Base
Auth
Wallet signature
Surface
HTTP 402 challenge

// these do not converge. Visa will not abstract Mastercard. Mastercard will not abstract Visa. Neither will route a stablecoin. The fragmentation is structural, not temporary.

interfaceThe surface

Everything an agent needs is three verbs.

Authorize a hold, execute a payment, cancel before commitment. Rail selection, token retrieval, and control enforcement happen underneath. Swapping rails is a config change, not a rewrite.

// hold a refundable deposit, release if the applicant doesn't qualify
const hold = await wallet.authorize({
  amount: 500.00,
  merchant: "mgmt_co_nyc",
  policy:   "holding_deposit",
  rail:     "auto",
});

await wallet.cancel(hold.id);        // no funds ever moved

// a $0.004 property-data call routes to x402 — no passkey, 180 ms
await wallet.pay({ amount: 0.004, merchant: "parcel_api", rail: "auto" });
stackThe layers

The hard part isn't the call. It's what's under it.

01 / VAULT

Agent identity

Each rail issues its own agent-scoped credential with a different lifecycle. The vault holds all three under one agent identity — HSM-backed, single-use issuance, automatic refresh, full revocation on agent termination.

02 / POLICY

Spend controls

Per-agent caps, merchant allowlists, category limits, time windows, and human-approval thresholds — authored once, compiled down to each rail's native control primitives so enforcement happens at the network, not in our code.

03 / ROUTER

Rail selection

Chooses on transaction size, merchant acceptance, settlement speed, and fee. Sub-dollar machine-to-machine goes to x402. Consumer-facing purchases go to a card rail. Automatic failover when a rail degrades.

operatorWhy us

We're not pitching this. We need it.

I run Spatial Web Inc.— four entities built from zero covering 3D capture, virtual tours, and AI property intelligence. Our leasing agent already takes a renter from a 3D tour to a completed rental application. The last step of that flow is a payment an agent has to make on someone's behalf, under a spend limit, with a cancel path. That is exactly the primitive AWaaS provides. We are our own first integration and our own first volume.

Operating today
Active 3D tours~1,000New York + Boston
Landlords with live inventory25
Listing distributionZillow · StreetEasyAPI integrated
Operating entities built from zero4
Engineering team3incl. founder
First transaction type in flightApplication feesin-tour, live pilot

Neutrality is the moat.Visa will not build an abstraction that routes to Mastercard. Mastercard will not build one that routes to Visa. Coinbase does not touch cards, and Stripe's economics are bound to the card networks. A credibly neutral layer can only be built by a party with no rail to protect.

Distribution is the wedge. Most agentic-payment infrastructure has no transactions to run through it. We have a vertical with real inventory, real intent, and a payment moment we already control end to end.

sequenceWhat ships when

Volume first, SDK second, platform third.

NOWin flight

In-tour application fees

Payment capture inside the 3D tour at peak renter intent, behind the wallet interface. Card rail first so it ships this month; the abstraction means the rail underneath is swappable.

+90dinternal

Second rail, second transaction type

x402 adapter for per-call property-data spend, plus refundable holding deposits using the authorize/cancel path. Two rails and two transaction shapes running on our own volume.

+180dexternal

Design-partner SDK

TypeScript and Python packages opened to a small set of vertical-agent teams. Policy dashboard, audit log, sandbox. Priced on transaction volume.

+12moplatform

Third rail and enterprise controls

Mastercard Agent Pay adapter, natural-language policy compiler, SOC 2 Type II. General availability for teams building agents that spend.

Early access

Building an agent that needs to spend?

We're taking a small number of design partners onto the SDK alongside our own volume. If your agent has a real transaction moment, we want to route it.

Email the founderRead the architecture