Crypto Payments vs Cards: Billing Rails in Practice

When a crypto-native business needs to collect payments, the choice between onchain billing and card rails is more than a technical detail. The payment rail you pick shapes everything from user experience to settlement risk. For teams already operating in crypto, this is not about replacing Stripe or PayPal with an onchain demo. It is about choosing the right tool for how your customers hold and move value.

How Card Rails Work for Recurring Billing

Card networks are built for consumer payments. A merchant collects a card number and billing address, either directly or through something like Apple Pay. The payment processor submits an authorization. If the bank approves, the merchant can capture the funds (immediately or later).

Recurring payments use stored card credentials. The merchant asks for permission on the first transaction, then charges later without the customer present. This is convenient for subscriptions. It also introduces risk. If a customer disputes a charge, the card network can pull back funds by reversing the payment. This is known as a chargeback. The merchant pays a fee and must prove the charge was legitimate.

Every card transaction sits in a stack of intermediaries: the card network, the issuing bank, the acquiring bank, the payment processor. Settlement can take days. Fees add up: interchange, assessment, and processor markup. Typical total cost for a business is 2.5% to 3.5% per transaction, sometimes more for international cards.

Onchain Billing: What Actually Happens on Payment

Onchain billing moves stablecoin from the customer’s wallet to the merchant’s settlement address. There is no bank in the middle. The customer signs a transaction for each payment or approves a smart contract to transfer up to a fixed cap for recurring charges. The transfer is final once confirmed on chain.

There is no chargeback. If a customer changes their mind, the merchant can refund, but there is no way to reverse the original transaction with a third party. Settlement happens in a single block. The only fees are network gas, which can be low on chains like Base and Polygon.

Example: Monthly Subscription, Cards vs Onchain

Suppose you sell a SaaS product for $100 a month. You have 500 customers. Let’s look at fee breakdown and what happens if a customer disputes a charge.

Card Rails

• Gross revenue: $100 x 500 = $50,000
• Typical fee: 2.9% + $0.30 per transaction
• Total fee: $1,450 (percentage) + $150 (fixed) = $1,600
• Net to merchant: $48,400
• Chargeback: Customer disputes a $100 payment. Card network pulls $100 + $15 fee = $115 from your account. You must submit evidence to contest it.

Onchain (USDC on Base)

• Gross revenue: $100 x 500 = $50,000
• Typical network fee: $0.05 per transfer (Base)
• Total fee: 500 x $0.05 = $25
• Net to merchant: $49,975
• Chargeback: Not possible. If refund is needed, merchant sends 100 USDC back in a new transfer.

Code Example: USDC Subscription with Bounded Approval

Onchain recurring billing should never require unlimited spending. Here is an example of bounded ERC-20 approval in Solidity:

// Customer approves 1200 USDC for annual subscription (12 x $100)
IERC20(usdc).approve(billingContract, 1200 * 1e6); // USDC has 6 decimals

// Billing contract pulls 100 USDC per month, up to the cap
function charge(address customer, uint256 amount) external {
    require(amount <= 100 * 1e6, "Max monthly");
    // logic to decrement allowance and transfer
}

The customer signs the approval for a specific cap. Each charge is a new blockchain transaction, visible and final. No one can pull more than the cap. The merchant cannot charge indefinitely.

Where Card Rails Win

Cards excel in conversion, especially for customers outside crypto. Most people already have a card on file with their device or browser. Chargebacks, while a risk for merchants, are a form of consumer protection in some jurisdictions. Card networks handle fraud prevention, PCI compliance, and KYC. For a business selling to the broad public, these features can matter more than fees or finality.

Integration is usually straightforward. Libraries and hosted checkouts exist for every major stack. No one needs to think about gas, addresses, or private keys.

Where Onchain Billing Wins

For crypto-native teams, onchain billing allows you to collect directly from a customer’s wallet with no middleman. Settlements are fast and final. There is no risk of chargeback clawbacks. Fees are predictable and low, especially for stablecoins on L2s.

You can build composable, programmable billing. For example, usage-based billing that pulls from an onchain allowance, or invoices that settle atomically when paid. Refunds are explicit transfers, not reversals.

Onchain billing is best when your customers are already holding value in their wallets, and expect to interact with dapps. You do not need to build out KYC, PCI, or bank compliance. You do not need to wait days for funds to clear.

What Changes for a Crypto-Native Business

Moving from cards to onchain billing changes the risk model. Revenue is not at risk from chargebacks. Finality means you must handle refunds as new payments. Support must be ready to explain that there is no dispute process beyond your own policies.

Accounting may need to adapt. Onchain payments settle instantly, but you may need to reconcile wallet inflows with customer records. Hosted checkouts can abstract some of this, but integration will need to handle web3 UX: connecting wallets, gas estimation, and handling failed transactions.

Here is an example in TypeScript using ethers.js to initiate a USDC payment:

const usdcAddress = '0x...';
const amount = ethers.utils.parseUnits('100', 6); // 100 USDC
const tx = await usdcContract.transfer(merchantAddress, amount);
await tx.wait();

The customer signs this with their wallet. If the transaction fails, nothing moves. If it confirms, the payment is done.

How We Handle This at Reclack

At Reclack, we support businesses that want final, onchain settlement for recurring and one-time payments. We never hold funds. Every payment moves from the customer’s wallet to the merchant’s settlement address. Recurring charges use bounded, customer-signed approvals for USDC on Base, Ethereum, and Polygon. There are no chargebacks, and no one is ever asked for a seed phrase or private key. If you want to see how this works in practice, you can learn more at https://reclack.com.