RipPay

Tap, sign, and settle: self-custody XRPL checkout powered by Ledger Nano X.

Comment

Inspiration

Cashless checkout today usually means trusting a custodial app, card network, or centralized processor. RipPay is inspired by a simpler idea: what if self-custody could work at point-of-sale UX speed?

The project positions the Ledger Nano X as the approval device while XRPL handles fast on-chain settlement, so users keep custody and merchants still get a smooth checkout flow.

We were also motivated by the familiar tap-to-pay experience. RipPay preserves that physical interaction through NFC/QR handoff, while making an important distinction clear:

NFC is only used for session handoff.
The actual cryptographic authorization happens on Ledger hardware over Bluetooth.

What It Does

RipPay is a self-custody XRPL checkout system:

  1. The merchant creates a checkout session.
  2. The buyer opens that session via QR, deep link, or NFC handoff.
  3. The buyer approves the payment on a Ledger Nano X.
  4. The signed XRPL transaction is submitted.
  5. The merchant sees live status updates:
    • SUBMITTED
    • VALIDATING
    • PAID

The implemented transaction primitive is XRPL Payment — not escrow or batching.

The backend build/verify flow enforces:

  • Destination
  • Amount
  • InvoiceID session binding

before forwarding the transaction to XRPL.

There is also a browser-first buyer path on Android Chrome using WebBluetooth + Ledger, which is currently the most demo-ready end-to-end flow.

How We Built It

RipPay is structured as a monorepo with separate buyer and merchant surfaces, plus a shared contract layer:

  • apps/web — Merchant checkout/session dashboard and browser Ledger pay flow
  • apps/ios — iPhone buyer app with Ledger BLE signing flow
  • packages/shared — Canonical session and API types shared across apps

Core Architecture Decisions

Backend-authoritative unsigned transaction

/prepare returns a canonical unsigned XRPL Payment with immutable fields:

  • Destination
  • Amount
  • InvoiceID

Hardware signing on the buyer side

  • iOS uses Ledger BLE transport plus XRP app functions:
    • getAddress
    • signTransaction
  • Web uses lazy-loaded WebBluetooth Ledger libraries to avoid SSR issues and signs from /pay/:id

Security verification before submit

The server decodes the signed blob and rejects tampering, including:

  • amount mismatch
  • missing signature
  • invalid invoice binding

Live payment UX

Frontends poll and update through payment status transitions, with demo flows centered on the merchant seeing PAID in real time.

Challenges We Ran Into

Hardware-dependent testing constraints

Some critical paths — especially WebBluetooth, BLE, and NFC — cannot be verified in CI. They require physical devices and specific environments, which adds demo risk and rehearsal dependency.

iOS NFC provisioning and entitlement complexity

ISO7816 support requires proper entitlements and a matching provisioning profile. Otherwise, NFC behavior can silently fail or be stripped out.

Ledger/XRPL edge compatibility

InvoiceID support can vary across Ledger XRP app versions. Older versions may reject certain fields, forcing careful fallback decisions to preserve security guarantees.

Cross-device NFC routing behavior on Android

HCE routing depends on foreground/default behavior, which makes it operationally fragile in live demos unless thoroughly rehearsed.

Accomplishments We’re Proud Of

Real self-custody checkout UX

The Ledger device is in the critical path, and payment approval is physically confirmed on hardware.

Tamper-resistant submit flow

The backend verifies signed blobs against session intent before accepting them, including:

  • amount checks
  • destination checks
  • invoice checks

Multiple buyer entry paths

QR, deep link, and NFC handoff all converge into a single signing flow, which is strong architecture for real-world checkout flexibility.

End-to-end lifecycle tests

The project includes tests for:

  • create
  • prepare
  • submit-signed
  • tamper rejection

This proves session-state integrity in code, not just in a demo.

What We Learned

Hardware UX is product UX

Pairing, app-open state, and user prompts matter just as much as protocol correctness in a payment flow.

Transport and trust anchor should stay separate

NFC and QR can be used purely to carry session identifiers, while the backend defines immutable payment intent and verification rules.

XRPL confirmations need explicit UX states

Users need to clearly see the difference between:

  • submitting
  • validating
  • final settlement

That visibility matters, especially when the network introduces delay.

What’s Next for RipPay

Based on the current codebase and docs, the strongest next steps are:

1. Harden the iOS NFC path

Improve production and demo reliability through:

  • correct entitlements
  • proper provisioning
  • repeated physical-device testing

2. Complete a real-device validation matrix for the WebBluetooth flow

Test across:

  • phone models
  • Ledger versions
  • success/failure conditions
  • measurable demo reliability metrics

3. Expand beyond the XRP Payment primitive

Once the baseline checkout flow is stable, RipPay can explore richer XRPL primitives. For now, the implementation is explicitly Payment-focused, and that should be presented as the current reality, with broader XRPL capabilities framed as roadmap.

Summary

RipPay is a self-custody checkout system designed to make crypto payments feel closer to tap-to-pay while preserving a strong security model. The key idea is simple but powerful:

  • session handoff can be lightweight and fast
  • approval should happen on trusted hardware
  • settlement should happen on-chain
  • verification should be enforced server-side against immutable session intent

That gives RipPay a compelling story: a checkout experience that feels modern, but keeps the user’s keys where they belong.

Built With

Share this project:

Updates