Ripplit

Inspiration

Group payments always break at the same point: one person fronts the bill, everyone promises to “pay later,” and the purchase either gets delayed or turns into awkward chasing. We wanted a checkout flow where the purchase only goes through when the group is actually funded—no trust, no reminders, no spreadsheets.

What it does

Ripplit is a GroupPay “payment method” for a marketplace checkout. Alice starts a GroupPay request, picks Bob and Chen by handle (not raw XRPL addresses), and pays her share. Bob and Chen open their own payer pages and click Agree & Pay. Each share is locked on the XRPL Testnet using escrows. Once everyone has paid, Ripplit automatically finishes the escrows and the marketplace order flips to PAID. If the group doesn’t complete by the deadline, the order expires and funds can be refunded via escrow cancellation.

How we built it

We built Ripplit as a simple webapp using:

• XRPL Testnet for escrow-based settlement and live verification
• xrpl-py to submit and monitor XRPL transactions
• FastAPI for the backend API (order creation, request state, escrow tracking, callbacks)
• Static web pages for three “apps”: the Marketplace, the Ripplit hosted checkout, and two payer views (Bob + Chen)

Funds come from the XRPL faucet so the demo works with free test XRP. For deterministic escrow finishing, we store the escrow references needed to finish/cancel later—specifically Owner and OfferSequence.

Challenges we ran into

• Designing a flow that’s trust-minimized but still simple for users (handles instead of addresses, and minimal steps).
• Keeping state consistent across three different user views while also tracking XRPL ledger confirmations.
• Getting the escrow lifecycle right end-to-end: create, detect, finish, and handle expiry/refunds cleanly.
• Making the demo resilient to network delays and transaction finality on testnet.

Accomplishments that we're proud of

• A complete, working “group checkout” loop: FUNDING → PAID only when all shares are actually locked and finished on XRPL.
• Two separate payer experiences (Bob and Chen) that feel like real payment approvals, not just a single-user demo.
• A DID-style contact list so Alice selects co-payers by @handle, avoiding address copy/paste errors.
• A merchant-friendly integration pattern with redirect + callback so this can plug into a real checkout flow.

What we learned

• Blockchain is most useful when it enforces a coordination rule that normal apps struggle with—here, conditional settlement and deterministic refunds.
• Escrow-based flows are powerful, but they require careful handling of references, deadlines, and edge cases.
• UX matters: switching from “send me money” to “lock your share, then we purchase” dramatically changes group behavior.

What's next for Ripplit

• Support real stablecoin settlement (e.g., RLUSD) and more flexible split rules (weights, caps, deposits).
• Add anti-flake features like small refundable bonds and automated reminders.
• Improve merchant tooling: dashboard, webhook retries, and order reconciliation.
• Expand beyond “one order” into multi-bill trips and events, with audit trails and receipt hashing for transparency.

Built With

• cryptoconditions
• fastapi-(web-api)
• faucet
• html/css/javascript
• html/css/javascript-(frontend-uis).-frameworks:-fastapi-(web-api)
• python-(backend)
• testnet
• uvicorn-(asgi-server).-platforms:-xrpl-testnet-(ledger).-xrpl-libraries/apis:-xrpl-py-(transaction-submission-+-wallet-utilities)
• xrpl
• xrpl-json-rpc-(ledger-queries)