Request Finance vs Apa: Invoicing vs On-Chain Checkout

Request Finance is a financial-operations suite for crypto-native teams. You issue an invoice denominated in the currency you like — often fiat such as USD or EUR — and your client pays it in crypto from their own wallet. The product also covers accounts payable, batch payouts, payroll and expense workflows, and it produces the reconciliation records that make crypto bookkeeping survive an audit. It is the tool a finance team reaches for when the job is 'bill this client' or 'pay these 40 contractors.'

Apa approaches the same money from the checkout side. Instead of an invoice, you get a hosted checkout page or a shareable payment link, plus a developer API and webhooks to wire payments into an app or store. A customer lands on the page, pays in crypto, and the payment settles on-chain to the wallet, asset and chain you nominate. There is no ledger of unpaid invoices to manage — the unit of work is a single completed payment.

Both are non-custodial and settle on-chain, so the trust model is the same. The choice between them is really a choice of workflow: recurring, itemised billing and payables (Request Finance) versus point-of-sale and programmatic checkout (Apa).

Request Finance is non-custodial by design. It is built on the open-source Request Network, and the protocol's own site is explicit that funds move directly from the payer's wallet to the recipient's wallet, and that Request 'has no access to them at any stage.' Because the money never passes through a custodial layer, Request notes there is no payment-institution licence or VASP registration standing between you and your funds.

Apa is non-custodial in exactly the same sense: payments settle straight to a wallet you own, and Apa never holds a balance on your behalf. There is no platform account your money sits inside waiting to be withdrawn.

This is the single most important thing the two products share, and it is what separates both from custodial gateways. When a provider is custodial, your payment lands in their balance first and you rely on their solvency, their compliance status and their payout schedule to get it out. With Request Finance and with Apa, settlement and receipt are the same event.

Request Finance is broad. It supports 350+ crypto and fiat currencies across 20+ networks, including EVM chains such as Ethereum, Base, Polygon, Arbitrum, Optimism and BNB Chain, plus non-EVM support for Solana and Tron. Invoices can be denominated in fiat while the payer settles in crypto such as USDC or USDT, which is convenient for teams that think in dollars but transact on-chain.

Apa is deliberately narrower: 9 core assets (BTC, ETH, SOL, USDC, USDT, POL, BNB, AVAX and TRX) across roughly 10 chains (Bitcoin, Ethereum, Solana, Base, Polygon, BNB Chain, Avalanche, Tron and more). The tighter set keeps the checkout simple and the settlement routing predictable.

On settlement mechanics, Request Finance's default path is on-chain wallet-to-wallet: the crypto the payer sends lands in your wallet. It also offers an optional crypto-to-fiat off-ramp that instead converts the payment and pays it out to a bank account over ACH, SEPA, SWIFT or local rails. Apa settles on-chain to your wallet in the asset and chain you choose, and lets you decouple pay-in from payout — a customer can pay in BTC while you receive USDC.

Request Finance's headline invoicing fee is unusually low and clearly published. Issuing invoices is free, and the payer pays 0.1% per invoice, capped at a maximum of $2 per invoice, as of early 2026. For a business sending high-value invoices, that $2 cap makes the effective percentage vanishingly small — a $50,000 invoice still costs $2 to settle.

The crypto-to-fiat off-ramp is priced separately and starts at 1%, charged on top of the amount being paid out; Request's own documentation gives the example that paying a $1,000 bill at a 1% fee means sending $1,010 worth of crypto. Larger off-ramp volumes can qualify for tailored rates.

Apa's own pricing is a flat 1.5% that is final and all-in, dropping to 0% for direct same-asset settlements, and it settles straight to your own wallet in one on-chain step — there is no platform balance and no separate withdrawal fee to get value where you want it. It is worth being clear that this all-in point does not divide Apa from Request Finance the way it divides Apa from custodial gateways: Request Finance is non-custodial too, so like Apa it settles directly wallet-to-wallet with no withdrawal step, and its native invoicing cost is simply the payer's 0.1% capped at $2. The genuine cost differences are narrower and specific — Apa can settle same-asset payments at 0% and natively supports a broader set of on-chain assets, while Request Finance's route to a bank account adds its 1%+ crypto-to-fiat conversion charge on top.

With Request Finance's default flow, you denominate an invoice in fiat for clarity but receive crypto to your wallet, so you carry whatever price risk that asset has until you convert it. Teams that want to avoid volatility use the crypto-to-fiat off-ramp, which locks the conversion and settles the payout to a bank account in fiat — trading the 1%+ fee for zero price exposure.

Apa handles volatility differently, at the checkout layer. Pay-in is decoupled from payout: the customer can pay in a volatile asset like BTC while you elect to receive a stablecoin such as USDC, so you hold dollars-on-chain the moment the payment confirms without leaving crypto rails or waiting on a bank.

In short, both give you a route to a stable outcome. Request Finance's route ends in fiat in a bank account; Apa's route ends in a stablecoin in your wallet. If your accounting lives in fiat and you want money in the bank, Request's off-ramp is the cleaner fit; if you want to stay on-chain but out of a volatile asset, Apa's payout selection does it natively.

Neither product exposes you to chargebacks, and for the same structural reason: these are on-chain crypto payments, and once a transaction confirms it is irreversible. There is no card network to file a dispute with and no acquiring bank that can claw a settled payment back weeks later.

For Request Finance, this means an invoice marked paid stays paid — the reconciliation record reflects a final, on-chain event. For Apa, a confirmed checkout payment is final the moment it settles to your wallet.

The practical upshot is the same for both: you lose the buyer-protection mechanics of cards, so refunds are a deliberate action you initiate rather than something a customer can force, and you gain certainty and the elimination of chargeback fraud and the fees that come with it. This is a core advantage both tools share over card-first processors.

Request Finance's primary surface is its hosted invoicing dashboard, where you create, send and track invoices and shareable invoice/payment links, alongside accounts-payable, payroll and expense tooling. For programmatic use it exposes a REST API and webhooks, and it offers accounting integrations so invoice data flows into your books. The centre of gravity is finance operations, not a storefront.

Apa's surface is checkout: a hosted checkout page, shareable payment links for when you have no site at all, and a developer API plus webhooks for embedding payments into an application or e-commerce flow. The centre of gravity is 'take a payment,' whether that is a human clicking a link or a backend creating a charge.

If your integration job is 'bill clients and reconcile,' Request Finance's dashboard and API are shaped for it. If your job is 'accept a payment inside my product or store,' Apa's checkout, links and webhooks are shaped for it. Many teams could reasonably use both — Request Finance for billing clients, Apa for point-of-sale checkout.

Choose Request Finance if your core need is invoicing, accounts payable, payroll or crypto accounting. If you send bills to clients, pay a roster of contractors in crypto, or need reconciliation records that keep an auditor happy, it is purpose-built for that, and the free-to-issue, 0.1%/$2-capped invoicing fee is hard to beat. Its optional fiat off-ramp also suits teams that ultimately need money in a bank account.

Choose Apa if your core need is checkout. If you are selling products or services and want a hosted page, a payment link, or an API-driven flow that settles on-chain to your wallet — with the freedom to receive a stablecoin regardless of what the customer paid — Apa is built for that job and is self-hostable end to end.

Because both are non-custodial and settle on-chain, this is rarely an either/or on trust; it is a decision about the shape of the work. A services business might send Request Finance invoices to enterprise clients while running Apa checkout for self-serve purchases on its site.

Getting started with Apa takes minutes because there is no balance to fund and no custodial account to verify before money can reach you. You connect the wallet you want to be paid into, choose the assets and chains you will accept from Apa's 9 supported assets across roughly 10 chains, and decide which asset and chain you want to receive — for example, accept anything but settle to USDC.

From there you can share a payment link immediately, embed the hosted checkout, or wire the API and webhooks into your product for programmatic charges and real-time payment notifications. Every confirmed payment settles straight to your wallet with no platform balance in between.

If you also send invoices, nothing stops you from pairing Apa's checkout with a dedicated invoicing tool. But if your immediate problem is 'let customers pay me in crypto and settle it to my own wallet, on my own terms,' Apa is the fastest non-custodial path to a working, self-hostable checkout.