XRBC ecosystem · validated-ledger payment evidence

Request payment.Verify the settlement.

Create a deterministic XRBC invoice, inspect the exact payment fields, hand the request to Xaman for explicit approval, then verify the validated XRP Ledger result and preserve a reproducible evidence receipt.

Create payment request Open Xaman workflow Verify transaction

1. Define invoice2. Review fields3. Approve in Xaman4. Validate on XRPL5. Export evidence

Custody boundaryThe page never receives private keys or holds XRBC. Xaman controls signing.

Request boundaryInvoice generation is local. A ledger request exists only after an explicit payment action.

Evidence boundaryA receipt records the validated result; it does not prove delivery of off-ledger goods or services.

Where Settlement fits

The payment-evidence surface inside the XRBC ecosystem

Settlement has a deliberately narrower job than Risk Lens or Sentinel Forensics: bind a payment request, obtain explicit wallet approval, confirm validated-ledger finality, and preserve evidence of what actually settled.

1 · ReadinessInspect account, trustline, reserve and ledger state before relying on a payment workflow.

2 · SettlementCreate the hash-bound invoice and hand one explicit Payment request to Xaman.

3 · Independent risk contextForensics remains separate research. Its score never determines whether a settlement succeeded. 4 · Evidence & supportExport the validated receipt and retain it with merchant, accounting and support records.

Settlement truth rule: signed is not settled. Submitted is not settled. A transaction is treated as settled only after validated XRPL evidence returns tesSUCCESS and the required invoice/request fields match.

Checking the validated XRP Ledger…

Validated ledger—

Wallet sessionNot connected

Active invoiceNone

Create an XRBC payment request

The Invoice ID is generated as a SHA-256 hash and placed directly in the XRPL Payment transaction.

Invoice details

Enter the merchant destination and the XRBC amount requested.

Merchant XRPL receiving address The receiving account must have an XRBC trustline unless it is the issuer.

Destination helper On mobile this is a native drop-down. If you use the connected account as the merchant recipient, generate the invoice, then disconnect it and connect the payer before requesting payment. Self-payment is blocked.

Amount requested (XRBC) These are the only two fields required for a basic invoice.

Optional invoice detailsDestination Tag, invoice number, merchant label, expiration and description.

Destination Tag — optional Use only the tag supplied by the receiving service or merchant. A wrong tag can misroute an otherwise valid payment.

Invoice number — optional

Merchant or recipient name — optional

Invoice expiration — optional

Payment description — optional Maximum 240 characters. This is included in a transaction memo.

Enter the receiving address and XRBC amount. Optional fields are collapsed until needed.

Deterministic request: the Invoice ID is SHA-256 over the invoice number, destination, optional Destination Tag, XRBC amount, merchant label, description, expiration and creation time. A blank invoice number is generated automatically. Editing invoice fields after generation requires regeneration.

Payment request preview

This preview updates after the invoice is generated.

Invoice: —
Merchant: —
Destination: —
Destination Tag: Not used
Amount: —
Expires: —
Invoice ID: —
Integrity: Generate the invoice to calculate its SHA-256 identifier.

View signing-ready Payment JSON

Generate an invoice to create the XRPL Payment template.

Deliver and sign the payment request

Connect the payer's Xaman wallet. The payer reviews the destination, XRBC amount, Invoice ID, and six-digit XRBC verification memos before signing.

Xaman payment signing

Status: Not connected

Expected transaction review

PayerConnect Xaman

DestinationGenerate an invoice

Destination TagNot used

Amount—

Invoice ID—

Verification codeCreated with signing request

Signing boundary: compare these fields with Xaman. The six-digit code is written on-ledger using the same APP / CHALLENGE / DOMAIN memo convention used across the ecosystem, with the existing XRBC-SENTINEL binding retained for receipt compatibility.

Generate an invoice and connect Xaman to prepare a signing request.

Signing-request reset: resetting or refreshing this page clears the QR code, deep link and six-digit request code while preserving the invoice fields. The page also attempts to expire an unopened Xaman payload. If a request has already been opened in Xaman, reject that old request there before creating another.

The Xaman QR code will appear here after a signing request is created.

Verify an XRPL settlement

The desk checks the transaction through the existing Render-to-XRPL bridge and compares the validated result with the generated invoice.

Transaction hash

Paste a transaction hash or complete a payment through Xaman.

Validated settlement receipt

The receipt records what the validated ledger returned and whether it matches the active invoice.

Validated XRPL transaction

XRBitcoinCash settlement evidence

Transaction hash —

Transaction type —

Transaction result —

Validated ledger —

Sender —

Destination —

Destination Tag Not used

Delivered XRBC —

Ledger close time —

Invoice ID —

Invoice comparison —

Xaman request binding No active signing request was available for comparison.

Recent local invoices

Stored only in this browser. No customer database or server-side invoice history is created.