How Non-Custodial USDC Payments Fit SaaS Billing Flows

Stablecoin payments onchain are not new. The mechanics of moving USDC from one wallet to another are well known. What has changed is how these flows now support SaaS billing models, without merchant custody or card rails. This post breaks down non-custodial stablecoin payments, the onchain flow, and what it means for SaaS businesses collecting recurring or one-time fees.

Non-Custodial Payment: What Does It Mean in Practice?

A non-custodial payment flow means the funds never touch an intermediary. The customer signs a transaction in their own wallet. USDC moves from that wallet to the merchant’s settlement address. The SaaS provider never sees a seed phrase, never holds customer funds, and does not need to manage wallets for others. Payment is direct, final, and visible onchain.

This contrasts with custodial services, where the provider takes custody of funds on behalf of the payer or the merchant. In non-custodial SaaS flows, the merchant’s risk profile changes. There is no float, no pooled customer balance to manage, and no regulatory burden from holding client money. The onchain settlement is both the payment and the receipt.

SaaS Billing Patterns: What Changes With Onchain Stablecoins?

Most SaaS companies bill on a recurring or pay-per-use basis. With USDC onchain, both patterns are possible. The difference is in the mechanics:

• One-time payment: The SaaS presents an invoice or payment link. The customer pays from their wallet. USDC settles to the merchant’s address.
• Recurring billing: The customer signs a bounded approval onchain. This allows the SaaS to collect up to a fixed maximum each period. The cap is explicit and visible before signature. No unlimited or hidden approvals. Each collection is a separate transaction, governed by the cap.

There is no card network, no chargeback window, and no third party holding onto the funds during the process. When a payment is confirmed onchain, it has settled.

Example: Monthly SaaS Subscription With Bounded Approval

Suppose you run a SaaS app that charges $49 per month. You want to let customers pay in USDC, on Base or Polygon. Here is how the flow looks non-custodially:

1. Customer visits your hosted checkout.
2. They connect their wallet (e.g. MetaMask, Coinbase Wallet).
3. The checkout displays the monthly price and requests approval to pull up to $49 in USDC per month. The approval is capped, no more than $49 in a period.
4. Customer signs the approval onchain.
5. On billing day, your backend calls the USDC transfer function to move $49 from the customer’s wallet to your settlement address. If the balance is insufficient, the payment fails. You can retry, or notify the customer.
6. Settlement is onchain. You see the transfer in your merchant wallet. Your SaaS app marks the invoice as paid.

Real Figures: Onchain Settlement Example

Let’s say the customer’s address is 0xC123...DEF4, and your merchant address is 0xM333...AAA1. On the first of the month, your backend triggers the transfer.

// Example ERC20 transfer
IERC20(usdcAddress).transferFrom(
    customerAddress, // 0xC123...DEF4
    merchantAddress, // 0xM333...AAA1
    49 * 1e6         // $49 USDC (6 decimals)
);

The transaction appears onchain. You can confirm by querying the USDC contract’s events, or by inspecting either wallet in a block explorer. There is no need to reconcile offchain ledgers or wait for a payout batch. The payment is visible and final as soon as the block confirms.

Onchain Stablecoin Flow: Failures and Edge Cases

Not every payment attempt will succeed. Here are the main cases:

• Insufficient balance: The transfer fails. No USDC moves. Your SaaS app can retry later, or prompt the customer to top up.
• Approval revoked: If the customer revokes the approval after signup, the next collection fails. You lose the right to pull funds, and billing pauses until the customer re-approves.
• Cap reached: If your SaaS attempts to pull more than the approved cap, the transaction fails. Only collections within the cap and period succeed.
• Network congestion or high gas: The customer may need to keep enough native token (ETH, MATIC, or ETH on Base) to cover gas. If gas is too high, you can retry when conditions improve.

Each failure is deterministic. There is no ambiguity about whether the payment settled. There are no chargebacks, and the merchant cannot reverse a payment once it confirms.

Merchant Payment Address: Why It Matters

In non-custodial flows, the merchant’s payment address is the destination. All USDC lands there, not in a pooled or escrow account. This has two important consequences:

• Security: Only the merchant controls their settlement address. If you rotate keys or move to a new wallet, you update the destination in your SaaS config.
• Reconciliation: There is one source of truth. Every USDC received at your address is a payment. You do not need to trust a third party to release funds, and you can track all incoming payments onchain.

For developers, this means you can automate reconciliation and reporting with standard web3 tools or APIs. You own the treasury and can integrate analytics, reporting, or offramps as needed.

How Reclack Handles Non-Custodial SaaS Payments

We built Reclack to support non-custodial USDC billing for SaaS. All payments move from the customer’s wallet to the merchant’s settlement address, never to us. Approvals are capped and visible. We provide hosted checkout, invoices, recurring and usage-based billing, and customer portals on Base, Ethereum, and Polygon. To see what a non-custodial stablecoin flow looks like in practice, visit reclack.com.