Follow a signing request to its real result
Opening a wallet, signing a request and completing a ledger action are different events. Your interface needs to tell the truth at each step.
Learn and inspect first. No wallet connection, seed entry, signing or transactions on this page.
Before you start
Bring the project identity and authority notes. You do not need a wallet for this lesson. If you later implement an integration, use a separate test environment and the current official Xaman documentation.
Your outcome: Design a signing journey that binds the correct user and intent, explains uncertainty, and awards a result only once after the required evidence.
Review Wallet Basics · Jump to the guided worksheet · Common problems · What to keep
Words you will use
- Payload
- A particular wallet signing request, with its own identifier.
- Callback or webhook
- A message notifying your application that something may have changed; fetch and verify the authoritative result.
- Backend
- The server-side part of an application where secrets and authoritative order checks belong.
- Validated ledger
- A ledger accepted by network consensus; a submission response alone is not this final evidence.
- Idempotent
- Safe to process repeatedly without repeating the business effect, such as granting an order twice.
Start with a clear request
A Xaman payload is a signing request. Your product should first explain the action, network, signing account, exact asset, recipient and amount or permissions. A sign-in identifies an account; it is not a payment. Never ask users to paste a seed, secret numbers or a private key into your page.
Give the user a real choice
Show the request in the wallet for independent inspection. Handle rejection, cancellation and expiry as normal outcomes. A return to your website or a QR scan alone proves nothing. Keep the intended action bound to the correct user/session and request identifier; do not accept a result belonging to a different request.
Verify beyond the callback
A callback is a reason for the backend to fetch the payload result, not proof to trust blindly. Check the resolved/signed state, expected account and intended network. For a ledger transaction, look up its transaction hash and verify validation, result and the exact intended operation. A signed request can still fail or remain unresolved on ledger.
Confirm payment facts
For payments, compare recipient, asset identity, delivered amount and any required destination tag/reference with the stored intent. Partial payments make the requested amount unsafe as a receipt: inspect delivered_amount in metadata. Record a transaction once so a repeat callback cannot grant a second entitlement. Unknown or unavailable ledger evidence stays pending.
Walk a pretend booking through every state
Write a pretend order O-17 for a 5 XRP workshop booking to Club Treasury on the intended rehearsal network. No real address or payment is supplied. Keep the order identity, wallet-request identity and transaction hash as three different fields.
- Before a request exists, write the stored intent: customer/session, expected action, expected signer where required, destination, network, asset, amount, any routing tag, expiry and order reference. A wallet address typed into a box is not proof of control.
- Write the confirmation text the member should see: what will happen, to whom, for what amount, and what it does not authorize. Separate an account SignIn from a Payment. Do not ask the user to sign an unrelated transaction to establish identity.
- Draw requested to rejected, expired or signed. Add pending verification after signing, then verified completion or confirmed failure. A browser return, QR scan or click is not a signed result; a signed result is not automatically a successful payment.
- Bind the request identifier to O-17 on the backend. On notification, fetch the payload result and compare it with that record. Confirm the expected signer and network. For SignIn verify the bound proof and session; there is no payment transaction to pretend was received.
- For a Payment, retrieve the transaction and metadata from the intended network. Require validated success, correct transaction type, recipient, asset identity, actual delivered amount and required routing fields. A screenshot, browser-provided success flag or requested amount is insufficient.
- Save completion and its unique transaction reference durably as one business operation. Delivering the same notification three times must still grant one booking. If the server stops between verification and entitlement update, recovery should finish the same order, not create a second payment request.
For the 5 XRP order, imagine the requested amount is 5 but the validated delivered amount is only 1. The order is not fully paid. If delivered amount is unavailable, keep verification unresolved rather than guessing. If evidence matches but a callback repeats, show the existing receipt rather than granting another seat.
Optional: connect the worksheet to a public record
Inspect a public Payment hash on its correct network in a read-only explorer. Locate validation state, transaction result, sender, destination, asset and metadata delivered amount. Distinguish the requested amount from actual delivery. A public hash can teach you how a receipt is read; it must never be reused as proof that your own fictional order was paid.
Official XRPL explorer directory · Network amendment references. Merely reading a public record does not need a wallet. Do not enter private or personal information in these exercises.
Common problems and what to check
The member signed but the page timed out
Show checking payment and recover the same request/transaction. Do not automatically invite a second payment. Explain how the user returns to the pending order.
A different wallet answered the request
Compare against the intended identity and policy. Reject a wrong signer where account control is required; do not silently relabel the order owner.
Testnet succeeded but a real order stayed locked
Confirm intended and observed networks. Test balances and transactions cannot settle a Mainnet order. Do not weaken the network check to make the test appear successful.
What to keep before moving on
Keep a state diagram, the O-17 intent worksheet, a list of verification fields and a duplicate/restart scenario. These are design artifacts, not production-ready authentication or payment code.
Explain your answer without looking at the worked example, then compare. If you guessed, revisit the relevant section. The checkboxes and quiz feedback stay on this page only; keep your project notes yourself.
Work through this example
Your checkout receives a “signed” callback, then its ledger lookup times out. The customer asks whether the order is paid. What should the interface show?
Compare your reasoning
Show verification pending with a recoverable status, not paid and not a request to pay again. Retry checking the same bound transaction. Complete the order only after validated successful payment matches the intended recipient, asset and delivered amount. Reject a mismatched request even if it is signed.
Steps are for this page only; reloading resets them.
Keep backend API secrets out of browser code. Use a documented Xaman integration model appropriate to the application. These pages have no wallet connection, QR signing request or submit action.
Check your understanding
A wallet says signed. Is payment complete?
Which payment amount should a receiver verify?
A callback repeats after a completed booking. What should happen?
A bound SignIn succeeds. Has the booking been paid?
Go deeper with official sources
Technical references checked 3 October 2026. Network amendments, wallet support and reserve rules can change. Check current documentation before implementing real transactions.