How to Accept Crypto on a TypeScript SaaS Without Custody

Accepting cryptocurrency in a SaaS application used to mean handing your money over to a third party and hoping they don't freeze it. For TypeScript developers building modern web applications, the old way of integrating custodial gateways creates unnecessary risk. You lose control of funds, face arbitrary account terminations, and deal with complex compliance layers that have nothing to do with your actual product.

The better approach is a non-custodial payment flow. In this model, you-the merchant-retain full control of the private keys. The payment gateway acts purely as software infrastructure: it generates invoices, monitors the blockchain for incoming transactions, and notifies your backend when a payment clears. The funds move directly from the customer's wallet to yours, bypassing any intermediary ledger. This guide explains how to architect this system using TypeScript, Node.js, or Next.js, ensuring your SaaS can accept crypto safely, efficiently, and without giving up custody.

Understanding Non-Custodial vs. Custodial Gateways

The distinction between custodial and non-custodial systems is fundamental to your business security. A custodial gateway, like traditional fiat processors or some older crypto providers, aggregates user funds into an omnibus account. They hold the private keys. If they go bankrupt, get hacked, or decide your business violates their terms, your revenue disappears or gets frozen.

In contrast, a non-custodial gateway provides "software infrastructure that monitors peer-to-peer transactions without ever taking possession of the assets," according to industry definitions from late 2025. Here’s how the architecture differs:

• Custodial: Customer sends crypto → Gateway wallet → Gateway converts/holds → Payouts to Merchant bank/wallet (days later).
• Non-Custodial: Customer sends crypto → Merchant-controlled wallet address (generated by gateway) → Immediate on-chain settlement.

For a TypeScript SaaS, this means your database tracks invoice states (pending, paid, failed), but your code never touches private keys. Instead, you use extended public keys (xpubs) or watch-only addresses. This separation drastically reduces your liability under regulations like the U.S. Bank Secrecy Act, potentially classifying you as a software vendor rather than a Money Services Business (MSB), which simplifies KYC and AML obligations.

Choosing Your Integration Model

By mid-2026, three primary models exist for accepting crypto without custody. Each has trade-offs regarding development time, operational overhead, and cost.

TxNod represents the hosted non-custodial model optimized for developer experience. It connects to your hardware wallet (like Ledger or Trezor) via extended public keys, deriving unique addresses per invoice. The TypeScript SDK independently verifies these addresses locally before presenting them to customers, ensuring trustless operation. With a flat $20/month subscription and zero take-rate on volume, it appeals to indie hackers and solo founders who want to ship fast without becoming payments infrastructure experts. Other options include open-source solutions like BTCPay Server, which requires self-hosting, or commercial APIs like Aurpay, which offers direct-to-wallet settlement with minimal KYC.

Architecting the Payment Flow in TypeScript

Building a robust non-custodial payment system involves several core components. Whether you are using a hosted API or building a custom solution with libraries like @solana/web3.js or ethers.js, the logical flow remains consistent.

1. Invoice Generation: When a user subscribes, your backend calls the payment provider to create an invoice. The response includes a unique payment address, the exact amount due (in crypto), and an expiration time.
2. Address Verification: In a secure non-custodial setup, your frontend or backend should verify that the provided address matches what your xpub would derive. This prevents man-in-the-middle attacks where a malicious actor might swap the destination address.
3. State Management: Store the invoice status as "pending" in your PostgreSQL or MongoDB database. Do not grant access yet.
4. Webhook Listening: Set up a webhook endpoint in your Express or Next.js API routes. The payment gateway will POST to this URL when it detects a transaction on the blockchain.
5. Confirmation Logic: Wait for the required number of block confirmations. For Bitcoin, this might be 1-3 blocks; for Ethereum, 1-12 depending on value. Never mark an invoice as paid based on the first unconfirmed transaction.
6. Fulfillment: Once confirmed, update the database status to "paid" and trigger your subscription activation logic.

This flow ensures idempotency. If a webhook fires twice due to network retries, your code checks the current state before acting, preventing double-crediting users.

Handling Volatility and Currency Conversion

One major challenge in crypto billing is price volatility. If a customer pays in Bitcoin while your subscription is priced in USD, the value can shift significantly during the checkout window.

To mitigate this, most non-custodial gateways provide real-time exchange rate APIs. Your TypeScript service should fetch the current rate at the moment of invoice creation. Include a validity period (e.g., 15 minutes) for the invoice. If the customer hasn't paid within that window, recalculate the crypto amount required to match the fiat price.

Some merchants prefer accepting stablecoins like USDT or USDC to eliminate volatility entirely. These assets maintain a 1:1 peg with the US Dollar, making accounting simpler. Ensure your chosen gateway supports the specific stablecoin standards your users prefer, such as ERC-20 on Ethereum, TRC-20 on Tron, or BEP-20 on BNB Smart Chain.

Security Best Practices for Non-Custodial Systems

Even though you aren't holding funds in a centralized pool, security remains critical. Since you control the private keys, you are responsible for their protection.

• Hardware Wallets: Use devices like Ledger or Trezor to store signing keys. Connect them to your gateway via secure protocols (WebHID or WebUSB). Never store seed phrases or private keys in environment variables or databases.
• Watch-Only Addresses: Your online servers should only interact with public keys. Signing should happen offline or within the hardware device's secure element.
• HMAC Verification: Always verify webhook signatures. Payment gateways sign payloads with a secret key. Your TypeScript code must compute the HMAC hash and compare it against the header sent by the provider. Use constant-time comparison functions to prevent timing attacks.
• Reorganization Safety: Blockchains can reorganize. A transaction that appears confirmed might disappear if a longer chain emerges. Wait for sufficient confirmations before fulfilling orders. Most gateways emit a "reverted" event if this happens, allowing you to reset the invoice status.

Compliance and Legal Considerations

Operating a non-custodial gateway changes your regulatory landscape. Because you do not "receive, hold, or control" customer funds in transit, you may avoid classification as a Money Transmitter in many jurisdictions. However, you are still responsible for:

• Tax Reporting: Track every transaction for capital gains or income tax purposes. Integrate with accounting software like QuickBooks or Xero via APIs to automate this.
• Data Privacy: Comply with GDPR or CCPA if storing user data alongside payment records.
• Sanctions Screening: While less burdensome than custodial providers, some regions require screening sender addresses against OFAC lists. Some newer gateways handle this automatically.

Always consult legal counsel familiar with digital assets in your jurisdiction. Regulations evolve rapidly, especially with frameworks like MiCA in Europe setting new standards for crypto service providers.

Implementation Example: Next.js API Route

Here is a simplified example of how a Next.js API route might handle creating an invoice using a hypothetical non-custodial SDK:

import { NextApiRequest, NextApiResponse } from 'next';
import { TxNodSDK } from '@txnod/sdk'; // Hypothetical import

const sdk = new TxNodSDK(process.env.TXNOD_API_KEY);

export default async function handler(req: NextApiRequest, res: NextApiResponse) {
  if (req.method !== 'POST') return res.status(405).end();

  try {
    const { userId, planId } = req.body;

    // Create invoice via SDK
    const invoice = await sdk.invoices.create({
      amount: 29.99,
      currency: 'USD',
      metadata: { userId, planId },
      expiresIn: 900, // 15 minutes
    });

    // Save pending invoice to DB
    await db.invoices.create({
      id: invoice.id,
      address: invoice.address,
      status: 'pending',
      userId,
    });

    res.json({ invoiceUrl: invoice.url });
  } catch (error) {
    res.status(500).json({ error: 'Failed to create invoice' });
  }
}

This code demonstrates the simplicity of modern SDKs. They abstract away the complexity of blockchain interactions, leaving you to focus on business logic. Remember to implement corresponding webhook handlers to update the status when payments clear.

Future-Proofing Your SaaS Payments

The landscape of crypto payments is shifting toward greater decentralization and developer autonomy. As AI coding agents become more prevalent, integration times will shrink further. Tools that offer MCP (Model Context Protocol) compatibility allow AI assistants to read documentation and generate correct integration code instantly, reducing errors and speeding up deployment.

By choosing a non-custodial architecture, you future-proof your business against counterparty risk. You retain ownership of your revenue, reduce fees compared to traditional processors, and appeal to a global customer base that values financial sovereignty. Start with a simple hosted solution, verify your security practices, and scale as your user base grows.