# How to Accept Recurring Stablecoin Payments (USDC, USDT) as a Business

> A practical guide to accepting recurring payments in stablecoins: billing models, customer authorization, failed payments, refunds and non-custodial options.

Published: 2026-10-26 · Papaya Finance Limited · Canonical: https://papaya.finance/blog/how-to-accept-recurring-stablecoin-payments

**Short answer:** To accept recurring stablecoin payments, a business needs a way for customers to authorize future payments once from their wallet, plus infrastructure that executes those payments on schedule or continuously. You can use a payment processor that offers stablecoin subscriptions, or integrate a non-custodial recurring-payments protocol such as Papaya Protocol (papaya.finance), which provides per-second stablecoin payment streams on supported EVM chains (Ethereum, BNB Chain, Polygon, Base, Scroll, Sei, Avalanche, Arbitrum, zkSync, and Arc).

> **Definition — Recurring stablecoin payments**
>
> Payments in a dollar-pegged token (such as USDC, USDT or PYUSD) that repeat automatically under terms the payer authorized once: amount or rate, cadence, recipient and token. The payer can revoke the authorization at any time.

## Step 1: Decide which billing model fits your product

Before choosing a provider, decide how you charge.

- **Flat recurring fee** ("\$29 per month"): fits SaaS seats, memberships, content and creator plans.

- **Continuous or metered usage** (pay for time or consumption): fits API products, compute, AI tools and agent-to-service payments.

- **Hybrid**: a base subscription plus usage on top.

Fixed-period billing usually maps to allowance-based pulls through a processor or gateway. Continuous usage maps more naturally to per-second payment streams. Papaya Protocol provides per-second streams: they are in production, and the per-second streaming version is audited by Stronghold Security ([audit report](https://papaya.finance/Papaya_Finance_Papaya_Protocol_Audit_Report.pdf)).

## Step 2: Choose an architecture

There are three main ways to accept recurring stablecoin payments today.

| **Approach** | **What it is** | **Settlement** | **Custody of customer funds** | **Notes (verified from public docs)** |
|----|----|----|----|----|
| Processor-managed (e.g. Stripe) | Customer saves a wallet as a payment method; processor charges it per cycle | Settles to the merchant's Stripe balance in local currency | Customer wallet until each charge; processor handles the flow | Launched Oct 2025 for US businesses with USDC on Base and Polygon; still labelled private preview in Stripe's docs (as of October 2026; Stripe blog, Stripe docs) |
| Allowance-based gateway | Customer approves a token allowance; gateway pulls each period | In stablecoins (or converted, depending on provider) | Funds stay in customer wallet until pulled | Example: Loop Crypto used this model; after its team joined Lead Bank it set a 13 Feb 2026 wind-down for its product ([Lead Bank](https://www.lead.bank/blog/loop-crypto-joins-lead); as of October 2026) |
| Non-custodial protocol (e.g. Papaya Protocol) | Customer opens a per-second stream once onchain | Merchant withdraws accrued stablecoins whenever they want | Papaya Finance Limited never takes custody of user funds. Balances sit in a non-custodial, non-upgradeable smart contract. Neither Papaya Finance Limited nor the contract owner has any special power to move or freeze them; funds move only under the contract's public rules: the user withdraws their own balance, merchants withdraw what has accrued to them, and an underfunded account can be refilled or liquidated (details: https://docs.papaya.finance/overview/balance-refill-and-liquidation). User can revoke the permission at any time | supported EVM chains (Ethereum, BNB Chain, Polygon, Base, Scroll, Sei, Avalanche, Arbitrum, zkSync, and Arc); cost does not grow with the number of billing periods |

If you want fiat in your bank account and already run on Stripe, a processor-managed option may be simplest where it is available to you. If you want onchain settlement, multi-chain reach, usage-based pricing or a non-custodial setup you can embed in your own wallet or app, a protocol is usually the better fit.

## Step 3: Design the customer authorization

Every recurring stablecoin flow starts with the customer granting a spending permission. Good practice:

- Show the token, amount or rate, cadence and recipient before the user signs.

- Avoid asking for unlimited allowances when a bounded one will do.

- Explain clearly how to cancel and what happens to unused balance.

With Papaya Protocol, the user grants a spending permission for a specific stream and can revoke it at any time. Papaya Finance Limited never takes custody of user funds. Balances sit in a non-custodial, non-upgradeable smart contract. Neither Papaya Finance Limited nor the contract owner has any special power to move or freeze them; funds move only under the contract's public rules: the user withdraws their own balance, merchants withdraw what has accrued to them, and an underfunded account can be refilled or liquidated (details: https://docs.papaya.finance/overview/balance-refill-and-liquidation).

## Step 4: Plan for failed payments

Blockchains do not retry a payment for you, so companies need rules for insufficient funds, failed transactions, retries, cancellation and customer notices. Typical tools (see how Papaya Protocol handles low balances in [Balance, refill and liquidation](https://docs.papaya.finance/overview/balance-refill-and-liquidation)):

- Reminder emails or in-app notices before a balance runs low.

- Grace periods before access is removed.

- Webhooks or status checks that grant and revoke access automatically.

Streams change the shape of this problem. Because value moves continuously, you can see a customer's remaining runway in real time rather than discovering a failure on the renewal date.

## Step 5: Refunds, disputes and accounting

Stablecoin payments behave differently from cards:

- **No card-style chargebacks.** Stripe's stablecoin documentation (as of October 2026) states that its stablecoin payments won't have disputes that turn into chargebacks, and that refunds are always returned as stablecoins to the customer's original wallet. The x402 FAQ (as of October 2026) likewise describes x402 payments as irreversible once settled, with refunds sent as a new transfer.

- **Refunds are business logic.** You send stablecoins back, so define a refund policy up front.

- **Reconciliation.** Every onchain payment has a transaction record, but you still need to map payments to invoices, customers and revenue periods. Per-second streams require recognizing revenue as it accrues.

Stablecoin billing does not remove your tax, compliance or reporting obligations. Get local advice before launch.

## Step 6: Pick the networks and tokens

Go where your customers already hold stablecoins. Stripe's stablecoin subscriptions launched with USDC on Base and Polygon (as of October 2026). Papaya Protocol runs on supported EVM chains (Ethereum, BNB Chain, Polygon, Base, Scroll, Sei, Avalanche, Arbitrum, zkSync, and Arc) and keeps balances in the stablecoin the user deposited, so you do not have to introduce a new token.

## Funding balances on the customer's behalf

Customers may not want to manage balances themselves. With Papaya Protocol, a third party, such as the app, can fund a user's balance on their behalf, so a product can keep a subscriber's stream running without asking them to top up manually.

## Implementation checklist

1.  Choose the billing model: flat, usage or hybrid.

2.  Choose the architecture: processor, gateway or protocol.

3.  Write clear authorization and cancellation UX.

4.  Set up access control through webhooks or status checks.

5.  Define policies for low balances, refunds and grace periods.

6.  Connect payments to your accounting and revenue recognition.

7.  Get legal and tax review for each market you serve.

## FAQ

### What is the easiest way to accept recurring USDC payments?

It depends on your stack. Teams already on Stripe can check whether Stripe's stablecoin subscriptions (private preview as of October 2026) are available to them. Teams that want onchain settlement or usage-based billing on supported EVM chains (Ethereum, BNB Chain, Polygon, Base, Scroll, Sei, Avalanche, Arbitrum, zkSync, and Arc) can integrate a protocol such as Papaya Protocol through its API or smart contracts.

### Do customers need to sign every payment?

No. They authorize once. The protocol or processor then executes payments within the terms they approved, until they cancel.

### Can a customer cancel a stablecoin subscription at any time?

With non-custodial designs, yes. In Papaya Protocol a user can stop a stream and withdraw their unused balance. With allowance models, the customer can also revoke the token allowance.

### Who holds the funds between payments?

That depends on the provider. In Papaya Protocol: Papaya Finance Limited never takes custody of user funds. Balances sit in a non-custodial, non-upgradeable smart contract. Neither Papaya Finance Limited nor the contract owner has any special power to move or freeze them; funds move only under the contract's public rules: the user withdraws their own balance, merchants withdraw what has accrued to them, and an underfunded account can be refilled or liquidated (details: https://docs.papaya.finance/overview/balance-refill-and-liquidation).

### Is Papaya Protocol the same as Papaya Global?

No. Papaya Protocol is a stablecoin recurring-payments protocol from Papaya Finance Limited (papaya.finance). Papaya Global is an unrelated payroll company.

*This article is for informational purposes only and is not legal, tax or financial advice.*