On this page

Settlement & Revenue Sharing

Claim earned payments onchain and distribute them to the configured beneficiaries.

Check what has settled#

The merchant ledger records accepted credit, debited requests and budget usage. Settlement claims an earned voucher or rail entitlement onchain. Those amounts may differ until a claim confirms.

Check the claim transaction and rail state after a service debit. Watch close and expiry deadlines too, since they can end the remaining claim window.

Purchasing service credit and billing each request
Purchasing service credit and billing each request

Fund an escrow#

Configure the funding driver with the factory, rail and asset identities, runtime hashes, decimals, kind, authority, budget, receiver and timers. prepare returns the withdrawal destination and amount. The holder must separately prove and send that Pool withdrawal.

Once assets arrive, deploy and activate the escrow. fund is an alias for those steps. It does not move money from a wallet or construct the private spend proof.

MethodAction
prepare()Return the predicted funding recipient and amount
deploy()Deploy the configured escrow
activate()Activate assets already received by the escrow
cancel()Cancel through the funding authority's escrow path
forwardRefundCredits()Forward rail refunds to the immutable external receiver

Distribute earnings#

A Splitter pays settled credit or underlying assets to beneficiaries fixed at deployment. Its issuer, mode and shares are immutable. Cumulative release accounting prevents paying the same entitlement twice.

Point the SDK at an existing splitter. Deploying it and choosing beneficiaries happen outside this interface.

javascript
const { createSplitterBackend } = require("./sdk/payment-sessions/index.cjs");
const splitter = createSplitterBackend({
  ...splitterDeployment, provider, signer: relayerSigner,
  creditIssuer, creditCodeHash,
});
const before = await splitter.status();
await splitter.claim(); // For a splitter deployed in settled-credit mode.
// Asset-mode splitters use their separately reviewed redeem/claim path.

Recover an interrupted claim#

Save broadcast intent before sending. After a timeout, keep it pending or uncertain and check chain state before retrying. If another relayer claims the voucher first, your transaction can revert even though the payment has settled.

A ledger commit, onchain claim and provider job can succeed or fail separately. Use durable job IDs and define how your application resumes failed work or refunds it.