Product
Payments
Detecting a transfer is easy. Knowing that this customer paid this invoice, that the amount is right, that it has settled by the chain's own rule, and that it was not already on the chain before you asked — that is the product.
A session states an obligation
You open a session naming the network, the asset by its native identifier, the amount as a person writes it, and the destination. Everything afterwards is measured against that statement rather than inferred from chain traffic.
A ticker is never accepted as an asset. USDT names a different
contract on every network and more than one on some, so the session takes the
contract, the mint or native.
If XRPC has not established how many decimals an asset has, the session is refused rather than the amount reinterpreted.
"code": "INVALID_REQUEST",
"message":
"nobody established how many decimals
0x8335...2913 has, so an amount in it
cannot be read. Give `decimals`
explicitly, or watch an asset XRPC knows",
"refusal": {
"refusal": "DECIMALS_UNKNOWN"
}The creation floor
Before a session exists, XRPC reads the chain head and records it. A payment at or below that height was on the chain before your offer existed, so it cannot pay for it.
The floor is the maximum of three positions that are never conflated: what has been delivered to you, what has been read by the ingest, and the chain head itself. A delivery cursor is never used as a chain head.
If a network cannot establish a chain head safely, session creation on that network is refused. A floor is never invented.
"creation": {
"chain_head": 51184176,
"creation_floor": 51184176,
"created_at_ms": 1789157699734
},
"finality": {
"native": {
"condition": "FINALIZED",
"model": "PROTOCOL_CONDITION",
"distance_is_meaningful": false
},
"policy": { "policy": "NATIVE_FINAL" }
}Four standings, kept apart
Reconciliation does not produce a status. It produces four answers that become true in different orders, and only their combination decides whether you should release goods.
Amount
NOTHING_SEEN, UNDERPAID,
EXPECTED_AMOUNT_SEEN, OVERPAID. Underpayment is a
standing, not an error.
Finality
Settlement in the chain's own vocabulary. NOTHING_TO_SETTLE is
not the same as not yet settled.
Observation
Whether XRPC is actually watching, and to what height. If observation is not
ESTABLISHED, silence means nothing.
Timing
Whether your offer still stands. A deadline is separate from how long XRPC keeps watching.
may_release_goods is computed from all four. It is the only field
that answers the merchant's actual question, and it is false whenever any part of
the picture is missing.
Non-custodial, by architecture
Money never touches StoneReason
The payer pays your address directly. XRPC watches a chain it cannot write to, holds no key, and has no path to move funds.
No pooled or omnibus account
There is no StoneReason balance, no sweep and no settlement step. What the chain shows is the whole of the money movement.
Signed webhooks
Payment events are delivered with an HMAC-SHA256 signature, with delivery ids that do not repeat and resume that survives a restart.
The receipt says what it is not
"headline": "WAITING",
"may_release_goods": false,
"observation": { "standing": "ESTABLISHED", "read_to_height": 51184180 },
"basis": {
"standing": "XRPC_OBSERVATION",
"why_not_a_proof":
"this is XRPC's record of what it read from the chain, not a proof
from the chain. It carries no validator signature and no inclusion
proof, and it cannot be checked by anybody who does not trust XRPC.
To verify independently, take the native identity of each entry to
any node or explorer for that network"
}Where payments run
9 networks are followed on this deployment through the light path: arbitrum, avalanche, base, bsc, celo, polygon, stellar, ton and xrpl. One bounded read per session per pass, every 12 seconds. No block scan, no history and no local store — what is held is a cursor per session.
4 more are qualified through the Data plane — ethereum, tron, solana and bitcoin — which ingests them properly. That plane is not deployed here, so those four are not being followed and sessions on them are not offered.
You will find one endpoint that reports 13 payment-enabled networks and another that reports 4. Neither is wrong on its own terms: one counts networks with an acquisition path, the other counts Data-plane qualification. The operational number for this deployment is 9.