How to Accept Crypto on a TypeScript SaaS Without Custody

Most developers assume that accepting cryptocurrency requires trusting a third-party platform with their funds. That assumption is outdated. You can build a non-custodial crypto payment system where your customers pay directly into wallets you control, without ever touching private keys in your application code. For a TypeScript-based SaaS, this means designing a flow where the software acts as a watcher and notifier, not a vault.

The core problem isn't just technical; it's regulatory and financial. If your SaaS holds customer funds in an omnibus account, you risk being classified as a Money Services Business (MSB) under U.S. law, triggering heavy KYC and AML compliance burdens. By keeping custody outside your stack, you remain a software vendor with standard data security obligations. This guide walks through how to architect that separation using modern tools, from hosted gateways to fully self-hosted nodes.

Key Takeaways

• Non-custodial means the merchant or customer controls the private keys; the gateway only monitors transactions.
• TypeScript stacks integrate via REST APIs, WebSockets, or SDKs that generate unique addresses per invoice.
• You have three main paths: hosted non-custodial services, self-hosted open-source processors, or custom node connections.
• Security relies on keeping signing keys off the server, often using hardware wallets or external signing services.
• Reconciliation is harder without automatic fiat conversion, requiring robust internal accounting logic.

Understanding the Non-Custodial Architecture

In a traditional custodial setup, like using a major exchange API, funds sit in a pool controlled by the provider. In a non-custodial setup, every invoice generates a unique payment address derived from your own wallet’s public key. The money flows directly from the payer’s wallet to your wallet on-chain. The "gateway" in this context is simply software infrastructure that watches for these specific transactions and notifies your backend when they confirm.

This distinction matters because it eliminates counterparty risk. If the gateway goes bankrupt or freezes accounts, your funds are safe because they were never held there. However, it shifts the burden of exchange rate volatility and tax reporting entirely onto you. There is no automatic conversion to USD or EUR; you receive exactly what was sent, in whatever asset was chosen, at the moment of settlement.

Choosing Your Integration Path

You don't need to build everything from scratch, but you do need to decide how much control you want over the infrastructure. Here are the three viable models for a TypeScript SaaS in 2026:

1. Hosted Non-Custodial Gateways: Services like Aurpay or Bitcart handle the blockchain monitoring for you. They provide REST endpoints and webhooks. You connect your wallet's public key (xpub), and they derive addresses for you. Fees typically range from 0.5% to 1% per transaction. This is the fastest path to production.
2. Self-Hosted Processors: Tools like BTCPay Server or Bitcart allow you to run your own instance. You host the software, which connects to blockchain nodes. This offers maximum privacy and zero gateway fees, but you manage the servers, updates, and uptime. It’s ideal if you already have DevOps capacity.
3. Custom Node Integration: You write TypeScript code that talks directly to Bitcoin or Ethereum RPC nodes or explorer APIs. This gives you total control but requires significant engineering effort to handle edge cases like double-spends, reorgs, and confirmation timeouts.

Technical Implementation in TypeScript

Regardless of the model, the core components of your TypeScript backend remain similar. You need a service module to create invoices, a database layer to track status, and a webhook handler to update subscription entitlements.

Start by defining your invoice schema. Each record should store the unique payment address, the expected amount, the currency (BTC, ETH, USDT, etc.), and the current confirmation count. When a customer checks out, your frontend requests a new invoice from your backend. Your backend calls the gateway API or derives the address locally, saves it to PostgreSQL, and returns the address and QR code to the user.

Next, handle the confirmation logic. Blockchain transactions aren't instant. Bitcoin might take 10 minutes to an hour for finality, while Ethereum takes seconds. You need a configurable threshold for "paid" status. For low-value SaaS subscriptions, 1-3 confirmations might be acceptable. For higher values, wait for 6+ blocks. Use WebSocket connections if your gateway supports them for real-time updates, or poll the API every 30 seconds if not.

// Example TypeScript Pseudo-code for Invoice Creation
async function createInvoice(amount: number, currency: string) {
  const address = await gatewayClient.generateAddress(currency);
  const invoice = await db.invoices.create({
    amount,
    currency,
    address,
    status: 'pending',
    expiresAt: new Date(Date.now() + 15 * 60 * 1000)
  });
  return invoice;
}

Managing Keys and Security

The biggest mistake developers make is storing private keys in environment variables on the server. In a non-custodial setup, your online runtime should ideally never have access to private keys. Instead, use watch-only addresses. Your gateway or node connection monitors the public address. When a payment arrives, you sign the transaction (if needed for withdrawal) using a hardware wallet like a Ledger or Trezor, or an external signing service.

If you're using a hosted gateway like TxNod, the process is simplified. You connect your extended public key (xpub) to the dashboard. The gateway derives unique addresses for each invoice. The TypeScript SDK can even re-derive these addresses locally to verify they match, ensuring the gateway isn't sending funds to a wrong address. This adds a layer of trustlessness without requiring complex cryptographic knowledge in your app code.

Handling Volatility and Reconciliation

Since you're settling in crypto, price swings between the time the customer sees the quote and the time the transaction confirms can affect your revenue. To mitigate this, set short invoice expiration times (15-30 minutes). If the price moves more than a certain percentage (e.g., 2%), invalidate the invoice and ask the customer to refresh it.

For accounting, map each confirmed transaction to an internal order ID. You'll need to log the exact hash of the blockchain transaction, the timestamp, and the fiat value at the moment of confirmation. This data is crucial for tax reporting. Unlike custodial gateways that provide consolidated monthly reports, you will likely need to export raw transaction logs and feed them into your accounting software manually or via script.

Common Pitfalls to Avoid

• Ignoring Network Fees: On congested chains, network fees can spike. Ensure your invoice amount covers the base cost plus a buffer, or clarify who pays the gas fee (usually the sender, but stablecoin transfers vary).
• Double Crediting: Always ensure your webhook handler is idempotent. If a webhook fires twice due to network issues, don't credit the customer's subscription twice. Check the transaction hash before updating status.
• Partial Payments: Decide your policy upfront. Do you accept partial payments? Most SaaS setups require full payment. Reject anything below 99% of the required amount.
• Chain Selection: Don't support every chain initially. Start with BTC and one stablecoin chain (like Ethereum USDT or TRON USDT) to keep complexity manageable.

Frequently Asked Questions