Accepting XRP and RLUSD Payments: An Operational Guide for Businesses

No merchant account application. No 2.9% processing fees. No 30-day fund holds. XRP payments arrive in 3 seconds, finalize permanently, and cost fractions of a cent. The operational challenge isn't the technology — it's structuring the workflow.

Accepting XRP or RLUSD requires fundamentally different infrastructure than accepting card payments. There's no gateway to approve you, no payment processor managing reconciliation, no dispute process. You're working directly with a settlement network that operates at the protocol level.

That simplicity is also the operational gap: without proper tooling for invoice management, payment matching, and on-chain verification, you're doing a lot of manual work. Here are four implementation patterns, from zero infrastructure to fully automated.

What You Need Before Starting

Three prerequisites, in order of importance:

• An XRPL wallet address. XAMAN (mobile) is the lowest-friction wallet for non-technical operators. Your wallet address is your "merchant account." Any XRP or RLUSD sent to it arrives immediately and is yours.
• A destination tag system. Destination tags are 32-bit integers appended to incoming payment requests. They let you match a payment to a specific invoice or customer. Without them, distinguishing $500 from Customer A versus $500 from Customer B requires manual inspection of timestamps and amounts.
• An on-chain verification mechanism. XRPL's JSON-RPC API (account_tx endpoint) lets you query recent transactions against your wallet and verify that a specific payment arrived with the correct amount and destination tag.

Method 1: Pure Manual (Zero Infrastructure)

For single-person operations or very low transaction volume, this works. The XRPL payment URI format makes it slightly more professional than sharing a raw address:

xrpl:rYourWalletAddress?amount=50000000&dt=1001&sl=Invoice%20%231

Where amount is in drops (1 XRP = 1,000,000 drops), dt is your destination tag, and sl is a memo. This URI, when clicked on mobile, opens XAMAN with everything pre-filled. The customer sees exactly what they're paying and to whom before confirming.

Limitation: verification is manual, doesn't scale beyond handful of transactions per week, and provides no automated receipts or bookkeeping.

Method 2: QR Code Payment Pages

Any QR code library encodes the payment URI. For web applications:

// Using any QR library
const xrpDrops = Math.floor(invoiceAmountXRP * 1_000_000)
const paymentUri = `xrpl:${WALLET_ADDRESS}?amount=${xrpDrops}&dt=${destinationTag}`
// or XAMAN deep link for mobile-first:
const xamanLink = `https://xaman.app/detect/pay?to=${WALLET_ADDRESS}&amount=${invoiceAmountXRP}&dt=${destinationTag}`

For RLUSD invoices specifically, the XAMAN deep link format handles the token specification automatically — the customer sees "Pay 250 RLUSD" rather than needing to configure anything themselves.

Method 3: Automated On-Chain Verification

The verification logic queries XRPL's public RPC endpoint:

// Verify XRP payment
const response = await fetch('https://xrplcluster.com', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    method: 'account_tx',
    params: [{ account: WALLET_ADDRESS, limit: 20, ledger_index_min: -1 }]
  })
})
const { result } = await response.json()
const confirmed = result.transactions.find(t =>
  t.tx.TransactionType === 'Payment' &&
  t.tx.DestinationTag === EXPECTED_TAG &&
  t.tx.Amount === String(EXPECTED_DROPS)  // XRP amount in drops
  // For RLUSD: t.tx.Amount.currency === 'USD' && t.tx.Amount.issuer === RLUSD_ISSUER
)

XRP vs. RLUSD for Business Payments

RLUSD is often preferable for invoicing and B2B settlement. The customer pays exactly $X regardless of XRP price movements between invoice generation and payment. For recurring billing, service contracts, or any scenario where invoice amount and received amount need to match exactly, RLUSD eliminates exchange rate variance from the accounting workflow.

XRP remains useful when speed and cost are paramount and the parties are comfortable with a brief settlement window to handle spot price conversion at either end.

Method 4: Managed Invoice Platform

The InvoiceDLT workflow illustrates this pattern: create an invoice via dashboard or API, receive a shareable payment URL with embedded QR code and XAMAN deep link, the platform monitors XRPL until the payment arrives and sends confirmation to both parties. The entire flow is automated after invoice creation.

Common Implementation Mistakes

• Reusing destination tags. Generate a unique tag per invoice. If two customers share a tag, manual reconciliation is required. Use a counter or UUID-derived integer.
• Verifying the tag but not the amount. A customer can send the wrong amount and satisfy a tag match. Always verify both DestinationTag AND the exact amount.
• Treating XRP amounts incorrectly. XRP amounts in XRPL transactions are in drops (1 XRP = 1,000,000 drops). RLUSD amounts use decimal strings. These are different formats and must be handled separately in your verification logic.
• Waiting for multiple confirmations. XRPL has BFT finality. Waiting for "safe" is unnecessary and delays your user's confirmation experience. One validated ledger is final.
• Not requiring destination tags. Omitting this requirement means every payment without a tag is an unmatched transaction you must manually reconcile. Make destination tags mandatory in your payment UI.

Tax and Accounting Treatment

In the US, XRP received as payment is treated as property under IRS guidance. You recognize income equal to the fair market value of XRP at the time of receipt. Maintain records of each payment with timestamp, XRP amount received, and XRP spot price at receipt time.

RLUSD received simplifies this: $1 in = $1 of income. No exchange rate tracking required. For businesses preferring clean accounting, invoicing in RLUSD and holding in RLUSD (or immediately converting to USD via exchange) is the operationally simplest approach.

XRPL's full transaction history is public and permanently on-chain. Export your complete payment history via any XRPL analytics API for accounting software integration — no manual reconciliation against bank statements required.