For stablecoin and payment teams

Know it arrived. Know when it is yours.

Accepting a stablecoin payment is two questions, and conflating them is expensive. Has the money appeared? is a detection problem. Can I ship? is a settlement problem, and every chain answers it differently.

The problem

Detected is not settled. Money on a chain can still be taken back. Shipping on first sight is selling goods against a transaction that may not survive a reorganisation.

Depth constants rot. “Twelve confirmations” is a number somebody chose once. It is meaningless on a chain with protocol finality and wrong on a chain that changed its parameters.

Polling is a system you did not want to build. A loop per network, a cursor per customer, a backoff per provider, and a bug in any of them means a payment nobody noticed.

The address is not the destination. On XRPL, Stellar and TON a payment needs a tag, a memo or a comment. An exchange will not credit a deposit without one, and neither should you.

What StoneReason does

One watch, per payment

You say which address, which asset and how much. A process here reads that one destination on a bounded schedule — no block scan, no history, no index of your customers.

Four standings, never one boolean

Expected, detected, settled and finalised are separate states with separate meanings. Your checkout decides which one it ships on, rather than inheriting somebody else’s default.

The chain’s own words

Base finalises when its batch lands on Ethereum. Stellar closes a ledger and there is nothing left to wait for. Both are reported as what they are, beside a policy you chose.

The payment model, in full →

What works today

9 networks are followed: arbitrum, avalanche, base, bsc, celo, polygon, stellar, ton and xrpl.
Token payments by contract address, with the amount compared as an integer count of the asset’s smallest unit — never through a floating-point number.
Routing values where the network needs one: an XRPL destination tag, a Stellar memo with its kind, a TON comment. Refused at creation if missing, rather than watched and never matched.
A receipt naming the occurrence by the chain’s own identity — block, transaction and log index on an EVM chain — so you can reconcile against it later.

Opening a watch

curl https://api.stonereason.com/v1/payments/watch \
  -H 'authorization: Bearer $XRPC_KEY' \
  -H 'content-type: application/json' \
  -d '{"network":"base",
       "asset":"0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
       "asset_decimals":6,
       "recipient":"0x742d…f44e",
       "expected_amount":"12.50",
       "amount_match_policy":"EXACT",
       "finality_policy":{"policy":"NATIVE_FINAL"},
       "idempotency_key":"order-1234"}'

The amount is a string. It is compared as an integer count of the smallest unit, because a float rounds and a rounded payment is a dispute.

What it does not do

It does not hold your money. Payments arrive at an address you control. There is no custody, no float, no settlement account.

It does not send. Watching for an incoming payment is the product. Broadcasting is not on the Beta surface.

Four networks are not served here. Ethereum, Tron, Solana and Bitcoin need a Data plane this deployment does not run. A watch on one is refused with that reason rather than accepted and never fired.

There is no SLA. Free Beta promises no availability, and the status page reports what was observed rather than what was promised.

Create a free account How Payments works