Canonical: https://builtonarc.app/guides/recurring-payments-in-usdc-on-arc # Recurring payments in USDC on Arc: subscriptions without a card mandate Updated 2026-09-02. How USDC subscription payments work on Arc without card mandates — allowances, pull vs push, session keys, and dunning without card retries. > A card-based subscription runs on a mandate — the customer authorizes the merchant once, and the card network handles every subsequent charge, retry, and dispute automatically. USDC has no equivalent network-level mandate system; recurring payment on Arc has to be built explicitly, using either a token allowance a merchant can pull against or an account-abstraction pattern where the customer's wallet pushes payments on a schedule. This guide covers both, and the dunning problem that follows from neither having a card network's automatic retry. Nothing described here is live; Arc mainnet is 16 September 2026. ## Pull: an allowance the merchant draws against The closer analog to a card mandate is a token allowance — a standard ERC-20 mechanism (USDC on Arc follows this same token standard, since Arc is EVM-compatible) where the customer authorizes a specific contract to pull up to a set amount from their balance. A merchant's subscription contract can then pull the subscription fee on the billing date without requiring the customer to actively approve each individual charge. This is the pattern closest to "set it and forget it" from the customer's perspective, but it puts real trust in the merchant's contract to pull only what was agreed — the allowance amount and any expiry need to be scoped tightly, and the customer needs a clear way to see and revoke the allowance if they want to cancel, since there's no card-network-style one-click cancellation happening on the merchant's side by default. ## Push: the customer's wallet initiates each payment The alternative is push-based: the customer's wallet — often through an account-abstraction pattern using session keys, a scoped, time-limited signing authority that lets a wallet make repeated small payments without asking the user to sign every single one — initiates each billing-cycle payment itself, on a schedule. This shifts more of the trust relationship onto the customer's own wallet infrastructure rather than the merchant's contract, which some customers and some regulatory contexts may prefer, at the cost of more sophisticated wallet tooling being required on the customer side. Session-key-based push billing is a newer, less standardized pattern across the industry generally than allowance-based pull, and a provider offering it should be evaluated on how mature and audited their specific implementation is, not assumed to be equally battle-tested as the underlying allowance standard. ## The core tradeoff: merchant trust vs. customer tooling requirements Pull (allowance-based) puts more responsibility on the merchant's contract behaving correctly and transparently; push (session-key-based) puts more responsibility on the customer's wallet supporting the pattern correctly. Neither eliminates the fundamental difference from card billing: both require the customer to take an explicit on-chain action (approving an allowance, or authorizing a session key) that has no direct card-mandate equivalent in familiarity, and both require your checkout to explain that action clearly enough that a non-crypto-native subscriber doesn't abandon the flow at that step. ## Dunning without a card retry Card-network dunning — the automatic retry logic when a charge fails due to insufficient funds or an expired card, often with several attempts over days before a subscription lapses — has no direct equivalent in a USDC allowance or session-key model, because there's no card network sitting in the middle retrying anything. If a pull attempt fails because the customer's balance is insufficient, or an allowance has expired or been revoked, that failure is immediate and final for that billing cycle unless your own subscription system builds retry logic — re-attempting the pull after a delay, and notifying the customer directly (email, in-app) that a scheduled payment failed and needs attention, since there's no card network doing that notification for you. This is a real engineering and operations gap in this category as of 2 Sep 2026: dunning logic for USDC subscriptions is something you or your provider has to build deliberately, not something inherited from the payment rail. Ask any subscription-billing provider you evaluate specifically how they handle a failed pull attempt — this is one of the clearer differentiators between a demo-quality integration and a production-ready one. ## What to build or evaluate before a subscription launch Concretely: choose pull or push based on your trust model and customer sophistication, build (or confirm a provider builds) clear allowance/session-key visibility and revocation for the customer, and build explicit dunning logic — retry attempts, failure notifications, and a defined grace period — since none of that comes free with the payment rail the way it does with a card network. {{entries:category=payments-payouts}} Built on Arc is an independent directory. Arc is a Circle product; we are not affiliated with, endorsed by, or operated by Circle. Sources: - [Circle Announces Founding Validator Cohort and Major Integrations for Arc](https://www.circle.com/pressroom/circle-announces-founding-validator-cohort-and-major-integrations-for-arc-ahead-of-september-16-mainnet-launch) - [Arc | The Economic OS — official site](https://www.arc.io/) ## Questions **What's the closest USDC equivalent to a card subscription mandate?** A token allowance — the customer authorizes a merchant's contract to pull up to a set amount, on a schedule, without approving each individual charge. It's the closer analog, though it requires the customer to take an explicit on-chain action to set up, unlike a stored card. **What are session keys, and how do they relate to recurring payments?** A scoped, time-limited signing authority granted to a wallet, part of the broader account-abstraction pattern, that lets a wallet make repeated small payments (like subscription billing) without the user manually signing every one. It's a push-based alternative to allowance-based pull billing. **What happens if a scheduled USDC payment fails?** Nothing automatic — there's no card-network dunning system retrying it for you. Your subscription system needs to build its own retry logic and customer notification, or the billing cycle simply fails silently from the customer's perspective. **Is push or pull billing more mature as a pattern?** Allowance-based pull is closer to a standardized, widely used pattern (built on the standard ERC-20 allowance mechanism). Session-key-based push billing is newer and less standardized across the industry — evaluate any specific implementation's maturity directly rather than assuming parity. **Is recurring USDC billing live on Arc yet?** No — Arc mainnet launches 16 September 2026. Any subscription billing flow described here should be built and tested against Arc testnet in advance.