Documentation

RocketForge Pay documentation explains how our non-custodial PayFi invoices are intended to work across the XRP Ledger, Flare, RLUSD, USDT0, and future bank-rail partners. Whether you're sending your very first invoice as a solo operator — or running hundreds a month as a growing team — this page explains how RocketForge Pay works for you. It's also written for the technical readers building integrations on top of it.

Last updated: September 1, 2026

Company: RocketForge Pay Inc.

Contact: contact email TBD

Registered address: Toronto, Ontario, Canada

Status legend

Overview

RocketForge Pay Inc. is building non-custodial PayFi invoicing for the XRP and Flare ecosystems. The working product idea is simple: an invoice that pays itself once the client sends payment through a supported settlement rail.

A merchant creates an invoice in CAD or USD. The client can pay with crypto or, in future versions, through a bank-rail partner. On the crypto side, payment can settle directly from the client wallet to the merchant wallet. RocketForge does not take custody of funds. The platform’s role is to create the invoice, present payment instructions, match settlement data, and issue a settlement receipt.

Rails line:

• XRP Ledger: first payment rail for XRPL invoices.
• Flare / FTSO: targeted pricing infrastructure for price-locked invoice quotes.
• RLUSD: planned USD stablecoin support on XRPL.
• FLR: planned Flare-native asset support.
• USDT0: planned omnichain stablecoin support.
• Bank rails via partner: planned support for card, ACH, and Interac payments.
• Partner payout financing: planned referral-based future capability, not currently available.

Non-custodial model:

RocketForge Pay is designed to keep merchants in control of their own funds. For crypto settlement, the client pays from their wallet to an address controlled by the merchant. RocketForge does not hold merchant private keys. RocketForge does not maintain a balance sheet or hold customer escrow for crypto payments.

Current pre-launch status:

• Landing page and waitlist backend: Live.
• First merchant cohort onboarding: Building.
• XRPL invoice MVP: Building.
• Flare FTSO price-lock: Planned
• RLUSD rails: Planned
• FLR rails: Planned
• USDT0 rails: Planned
• Bank rails via partner: Planned
• Public invoice API and x402-compatible payment payload: Planned

Getting started

RocketForge Pay is launching in waves. The first public experience is a waitlist and targeted merchant cohort.

1. Join the waitlist

The waitlist is open through the landing page. It collects basic business information so RocketForge can identify early merchant use cases.

Live

2. Enter the first merchant cohort

Selected freelancers, agencies, and small businesses will be onboarded into the first invoice testing group. The cohort is focused on XRPL invoice creation, sending, client payment, and settlement matching.

Building

3. Create, send, get paid, and grow

The planned merchant workflow is:

• Create: build an invoice in CAD or USD.
• Send: share an invoice link with the client.
• Get paid: the client pays using a supported rail; payment settles into the merchant’s own crypto wallet or, in future, through a partner bank settlement.
• Grow: reuse invoice templates, track paid invoices, export records, and prepare for API or agent-based settlement.

Building for XRPL invoice flow

Planned for bank settlement, API access, and growth tooling

How invoicing works

A RocketForge Pay invoice moves through five broad stages.

Stage 1 — Create the invoice

The merchant creates an invoice with:

• Invoice number or reference.
• Currency amount in CAD or USD.
• Merchant name and business details.
• Logo upload to brand your invoices.
• Client name or optional client email.
• Line items or payment description.
• Expiry or quote window.
• Supported payment method selection.

Stage 2 — Generate a payment quote

The client sees the amount due. If paying in crypto, RocketForge converts the CAD or USD amount into the required asset amount for the selected payment window.

The target production behavior is:

• Quote the invoice at creation using a price feed.
• Lock the crypto payment amount for a short window, around 30 minutes.
• Expire the quote after the window unless the merchant generates a new quote.

Flare’s FTSO oracle is targeted as the future price-lock mechanism for production.

Paid subscription clients will get live quote generation based on the current market value of the chosen asset.

FTSO-powered production price-lock: Planned

Stage 3 — Client pays

The client opens the invoice link and chooses a payment method.

For XRPL payments:

• The client sends XRP to the merchant’s XRPL address.
• If an invoice uses destination tags, the payment instructions include the required destination tag.
• The client submits the payment from their own wallet, or from an exchange withdrawal screen that supports XRPL destination tags.

For future bank rails:

• The client may pay by card, ACH, or Interac through a partner.
• Merchant settlement would occur through the partner flow, not through RocketForge holding funds.
• The exact partner mechanics, payout timing, and dispute rules are not finalized.

Bank rails via partner: Planned

Stage 4 — Settlement and auto-matching

For XRPL settlement, the payment is recorded on-chain. RocketForge’s matching layer is intended to identify:

• Which invoice was paid.
• Which transaction satisfied it.
• How much was received.
• Which asset was received.
• What network fee applied.
• When settlement occurred.

Destination tags help match payments automatically. The destination tag acts like an invoice identifier attached to the payment so the invoice can be marked paid without manual reconciliation.

XRPL auto-matching in the invoice MVP: Building

Stage 5 — Settlement receipt

Once a payment is matched, the system should generate a Settlement Receipt for both the merchant and the client.

A Settlement Receipt is a machine-verifiable payment proof. It is intended to include:

• Invoice ID or number.
• Invoice currency and amount due.
• Payment asset.
• Amount paid.
• Merchant receiving address.
• Destination tag, when used.
• Transaction hash.
• Network fee or payment cost.
• Settlement timestamp.
• Invoice status.
• Settlement status.

The Settlement Receipt is designed as payment evidence, not a tax certificate or accounting audit. Merchants remain responsible for bookkeeping, tax treatment, and compliance obligations.

XRPL settlement receipt in the invoice MVP: Building

Receipt export and API access: Planned

Payment rails explained

The following table separates the underlying network or rail from RocketForge’s product integration. Some networks exist and are live, while RocketForge invoice rails may still be building or planned.

Typical XRPL payment characteristics used in documentation:

• Settlement is usually measured in a few seconds rather than minutes.
• Network fee is extremely small, around $0.00001 XRP.
• Destination tags are useful when multiple invoices can settle to one XRPL address.
• On-chain transactions are irreversible once confirmed.

These are network characteristics, not guarantees. Actual timing and fees can vary with network conditions and client wallet behavior.

Security and custody

RocketForge does not hold crypto keys

For crypto rails, the merchant controls the receiving wallet. RocketForge creates invoice instructions and matching data, but it does not take custody of merchant private keys.

RocketForge does not hold crypto funds

For XRPL invoice payments, funds move directly from the client wallet to the merchant wallet. There is no middleman balance held by RocketForge. There is no RocketForge crypto escrow in the MVP model.

What happens on-chain

When the client sends payment, the transaction is recorded on the relevant public network. RocketForge’s role is to read settlement information and associate it with the correct invoice. The transaction itself is controlled by the payer and the network, not by RocketForge.

Destination tags and invoice matching

On XRPL, a destination tag is an optional field that can identify a specific payment purpose within a broader account or hosted-address setup. RocketForge may assign a destination tag to an invoice so incoming payments can be matched automatically.

Important operational notes:

• The client must enter the destination tag exactly as shown.
• Some wallets or exchanges handle tags differently than native XRPL wallets.
• If a payment lacks the correct destination tag, matching may require manual reconciliation and is not guaranteed.
• If a payment goes to the wrong address or wrong asset, it may be unrecoverable.

Manual reconciliation for untagged XRPL payments: Planned

Bank rails and custody boundary

Bank, card, ACH, and Interac rails are planned through a partner. Because fiat rails usually involve payment intermediaries, the custody and settlement path differs from crypto rails. RocketForge does not plan to hold fiat balances for customers at any point. During a bank-rail payment, the client’s funds move from the client’s bank account toward the merchant’s bank account through the partner’s regulated payment infrastructure. RocketForge’s role is limited to presenting payment instructions, matching the settled payment to the invoice, and issuing a settlement receipt. How a transfer settles depends on the rail and on whether funds cross a border:

• Domestic Canadian payments (Interac e-Transfer or EFT): funds stay in Canada and remain in CAD, moving between Canadian bank accounts with no currency conversion and fewer intermediaries. This typically means faster settlement and lower costs.
• Cross-border payments to the United States (ACH or card networks): funds leave the payer’s country and settle into a US-based account. This can involve conversion into USD, US payment-system intermediaries, and a longer settlement window than a domestic transfer.
• Other international payments (wire or international card networks): funds cross borders through additional correspondent banks, which adds currency conversion steps, intermediary fees, and time before the merchant receives funds in their own currency.

In every case the custody boundary is the same: while a bank-rail payment is being processed, funds sit with the regulated payment partner, not with RocketForge, and settle to the merchant’s own bank account. Corridor-specific details (settlement timing, currency conversion, and fees) will be published as the partner flow is finalized.

Bank rails via partner: Planned

Data and privacy

RocketForge collects only the information needed to operate the waitlist and merchant flow. Email communications for marketing follow Canadian anti-spam expectations, including consent, identification, and unsubscribe mechanics. The privacy page will describe data handling in detail.

Privacy and compliance policies: Building

CASL-compliant marketing workflows: Building

Privacy contact email: contact email TBD

Not financial, legal, tax, or compliance advice

RocketForge Pay documentation describes product behavior and planned features. It is not legal, tax, accounting, financial, or regulatory advice. Merchants are responsible for their own invoice terms, tax collection, sanctions screening, anti-money-laundering obligations, consumer protection rules, and local financial regulations.

x402 and machine-readable invoices

RocketForge Pay is designed to support machine-readable invoices that expose settlement data in a structured JSON format. The goal is to allow future agents, API clients, and payment-aware applications to retrieve invoice terms, understand what must be paid, verify settlement, and continue a workflow automatically.

This is related to the emerging x402 standardization effort for machine and agent payments over HTTP. In simplified terms:

• An agent or software client requests an invoice or service.
• The system returns a 402 Payment Required response or equivalent machine-readable instruction.
• The JSON payload describes the required payment, asset, amount, destination, expiry, and receipt format.
• After payment, the system returns a verifiable settlement receipt.

RocketForge’s first documentation audience should not assume this API is live. The current waitlist and MVP experience focus on human-facing invoice links and settlement matching. The public invoice API and x402-compatible payload are roadmap items.

Public x402-compatible invoice API: Planned

Illustrative settlement payload

The example below is illustrative only. It is not a live endpoint, not a signed production payload, and not a completed public specification.

{
  "invoice_id": "RF-INV-2026-000123",
  "invoice_status": "awaiting_payment",
  "invoice_currency": "CAD",
  "invoice_amount_due": "1250.00",
  "payment_asset": "XRP",
  "payment_amount_due": "1200.55",
  "payment_method": "xrpl",
  "merchant_receiving_address": "rExampleXRPLAddressPlaceholder",
  "destination_tag": "741234",
  "quote_expires_at": "2026-02-01T18:00:00Z",
  "price_source": "planned_ftso",
  "price_source_status": "planned",
  "network_fee_estimate": "0.00001",
  "network_fee_currency": "XRP",
  "settlement_receipt_schema": {
    "invoice_id": "string",
    "payment_asset": "string",
    "amount_paid": "decimal_string",
    "merchant_address": "string",
    "destination_tag": "string",
    "transaction_hash": "string",
    "network_fee": "decimal_string",
    "settled_at": "timestamp",
    "status": "paid"
  },
  "x402": {
    "version": "draft",
    "status": "planned"
  }
}

Machine-readable invoice payload specification: Planned

Signed settlement receipt endpoint: Planned

Agent-to-agent payment testing mode: Planned

FAQ

What is live today?

Only the public landing page and waitlist backend are live. The XRPL invoice MVP is building. Most payment rails, APIs, and exports are planned.

How long does XRPL settlement take?

XRPL transactions are typically confirmed in a few seconds, often in the 3-to-5 second range, but timing depends on network behavior and client wallet submission. RocketForge’s invoice matching and settlement confirmation are part of the MVP and are currently being built.

How does the price-lock work?

The target production model is that the invoice amount is converted from CAD or USD into the selected crypto amount using a price feed, then locked for a short payment window, such as around 30 minutes. The client pays the locked crypto amount during the window.

Flare FTSO is the targeted oracle mechanism for production price-locking. RocketForge plans to support several quoting modes so each invoice can use the approach that fits the merchant and the client:

• Time-locked quotes: the quote stays valid for a payment window chosen by the client, from minutes to hours, during which the displayed crypto amount is fixed.
• Auto market-value quotes: the CAD or USD amount is converted automatically at the current market value into the supported asset of the client’s choice — XRP, FLR, RLUSD, or USDT0 — so the client always sees the real-time equivalent.
• Manual token amounts: the merchant enters the invoice amount directly in tokens (for example, a fixed number of XRP or RLUSD) rather than in a fiat currency.
• Live matching: the payable amount follows the live market value of the chosen asset up to the moment of settlement, removing the need to rely on a short fixed-rate window.

FTSO production price-lock: Planned

Why do destination tags matter?

A destination tag helps identify which invoice an XRPL payment corresponds to. If a merchant uses one XRPL address for many invoices, the destination tag allows RocketForge’s matching layer to connect the payment to the correct invoice. If the client omits or enters the wrong destination tag, automatic matching may fail.

What if the client sends without a destination tag?

RocketForge may provide a manual matching workflow where the merchant can attach an unknown transaction to an unpaid invoice. This should not be treated as guaranteed or immediate.

Manual invoice matching: Planned

Can crypto payments be reversed or charged back?

Crypto payments on public networks are usually irreversible once confirmed. RocketForge cannot reverse a completed XRPL, Flare, RLUSD, or USDT0 payment on the merchant’s behalf. The merchant and client must coordinate directly if a refund is needed.

What about bank card, ACH, or Interac chargebacks?

Bank-rail disputes depend on the partner, payment method, and legal framework. Card payments may be subject to issuer dispute rules. ACH and Interac flows have different risk and chargeback characteristics. RocketForge has not finalized a bank partner, dispute policy, or chargeback allocation model.

However, RocketForge will work to set up practical ways to support our clients in this matter.

Bank rails and dispute handling: Planned

How do refunds work?

Because RocketForge does not hold crypto funds, a crypto refund means the merchant sends funds from their own wallet to the client’s wallet. RocketForge may later provide a refund workflow that helps generate a refund invoice, record a return transaction, and update the original invoice status.

Refund invoice workflow: Planned

Automated refund receipt generation: Planned

What fees will merchants pay?

Network fees are separate from platform fees. XRPL network fees are around $0.00001 XRP. RocketForge will offer free and subscription-based plans. The plans will differ by the number of invoices that can be sent each month, the complexity of the available settings, and the level of automation.

Can clients pay in crypto but invoice in CAD or USD?

Yes, the product model is CAD or USD invoices with client-facing payment options in crypto or, in future, bank rails. The quote converts the invoice currency into the payment asset for the selected window.

Which assets are supported?

The first intended live rail is XRP on XRPL. Planned assets include RLUSD on XRPL, FLR on Flare, and USDT0. Bank payments may settle in CAD or USD through a partner.

• XRP: Building for RocketForge invoice integration.
• RLUSD: Planned
• FLR: Planned
• USDT0: Planned
• CAD/USD bank settlement: Planned

What is a Settlement Receipt?

A Settlement Receipt is a machine-verifiable payment proof. It should show the invoice identifier, amount paid, asset, transaction hash, destination tag if used, fee, and settlement time. It is intended to give merchants and clients a clear payment trail without requiring RocketForge to hold custody of funds.

Settlement receipt generation for XRPL: Building

Settlement receipt export/API: Planned

Can I export invoices for accounting?

The target export formats include invoice status data, settlement references, transaction hashes, and payment amounts. CSV and JSON exports are roadmap capabilities. Merchants should still use their own accounting system as the source of record for tax and bookkeeping.

CSV export: Planned

JSON export: Planned

Invoice API: Planned

Do merchants need an exchange account?

No. For crypto rails, merchants need their own wallet and can receive funds directly to their address. Clients also do not need a RocketForge-held wallet. However, the client and merchant should use compatible wallets that support the asset and, when required, destination tags or memos.

Is this a stablecoin product?

Not primarily. RocketForge Pay is an invoicing and settlement tool. Stablecoins such as RLUSD and USDT0 are planned payment assets, but the core product is non-custodial invoice settlement across crypto rails.

RLUSD and USDT0 rails: Planned

Can agents use RocketForge Pay invoices?

The product design anticipates machine-readable settlement payloads that could support agent payments. This is future architecture, not current capability. The x402-compatible API is planned.

Agent settlement mode: Planned

What information is shown publicly?

Crypto payments may be visible on public blockchains, including addresses and transaction amounts. Invoice metadata may include merchant name, client reference, amount, currency, asset, invoice number, and settlement receipt data. Clients should assume that public network transactions can be traced.

Glossary

PayFi

PayFi is a broad term for finance and payment workflows that use public-chain settlement. In RocketForge’s context, it means invoicing, payment matching, and settlement receipts using crypto rails while keeping merchants non-custodial.

FTSO

FTSO refers to Flare’s Time Series Oracle system. RocketForge targets FTSO as a future mechanism for price-locked invoice quotes. Production integration is not live.

FTSO price-lock integration: Planned

Destination tag

A destination tag is a field used with some public-chain addresses to identify the specific account, invoice, or payment purpose. On XRPL, destination tags are commonly used when multiple payments need to be distinguished for a shared address or hosted-account setup.

Non-custodial

Non-custodial means the user retains control of their own keys and funds. For crypto rails, RocketForge is designed not to hold private keys, client funds, or merchant balances.

x402

x402 refers to an emerging machine-payment standardization effort connected to the HTTP status code 402 Payment Required. The goal is to make payment requests, settlement instructions, and receipts machine-readable. RocketForge’s x402-compatible API concept is planned, not live.

x402-compatible API: Planned

RLUSD

RLUSD is a USD stablecoin expected to be supported on XRPL as a payment asset in future RocketForge releases. It is intended to provide dollar-denominated settlement without requiring a traditional exchange account.

RLUSD payments: Planned

USDT0

USDT0 is the omnichain deployment of Tether’s USDT, built on LayerZero’s Omnichain Fungible Token (OFT) standard and backed 1:1 by USDT locked on Ethereum. It is live on Flare today and serves as a native stablecoin for the Flare / XRPFi ecosystem. RocketForge plans to support USDT0 as a settlement asset on the Flare rail: merchants receive USDT0 directly on Flare, while inbound transfers from other USDT0-supported chains settle as the same token, with no wrapped or bridged variant required.

USDT0 payments: Planned

Settlement receipt

A settlement receipt is a machine-verifiable proof that a payment matched an invoice. It typically includes invoice ID, amount paid, asset, destination address, destination tag if used, transaction hash, fee, timestamp, and status.

Settlement receipt generation for XRPL: Building

Public settlement receipt API: Planned

Legal note

RocketForge Pay Inc. is a Canadian company based in Ontario, Canada. This documentation does not constitute legal, tax, accounting, financial, or regulatory advice. Service availability, payment rails, pricing, and compliance responsibilities may change before general availability. Unless a separate written agreement states otherwise, any legal notices, governing law, and dispute resolution relating to RocketForge Pay are set out in our Terms of Service and governed by the laws of the Province of Ontario, Canada.

Contact: contact email TBD

Registered address: Toronto, Ontario, Canada