A subscription should have clear limits.
The amount, interval and cancellation rules matter as much as the first successful charge.
The first payment is only one part
A recurring payment needs an agreement the customer can understand: how much can be charged, how often, when it starts and how to stop it. It also needs a way to handle missing funds, failed attempts and cancellation.
For USDC, moving tokens once and authorizing future transfers are separate actions. A checkout should make that distinction visible before the customer signs.
Keep permissions bounded
OurPay’s subscription contract uses defined payment amounts, billing intervals and payment limits. A customer grants a limited token allowance and authorizes the subscription. Renewal execution then has to satisfy the contract’s checks.
The customer can cancel the authorization on-chain or revoke the token allowance. Network transactions require gas, and the wallet remains the place where the customer reviews and approves the initial actions.
Every network is a separate rollout
A contract deployed on Polygon does not exist automatically on Base, Arbitrum or Ethereum. Each network needs its own funded deployment, configuration, verification and tests before recurring payments can be activated there.
Polygon is the first activated recurring USDC network. The first live payment and cancellation have been exercised. Shared support for other EVM networks is part of the rollout, and one-time network availability should not be read as recurring-payment availability.
UPI has its own subscription mechanism
An ordinary UPI QR does not authorize monthly debits. Automatic UPI renewals require a supported mandate flow and bank or payment-partner integration. Until that is available, a payment request for each renewal must remain an explicit customer action.
One subscription dashboard can bring these records together, but it should never promise an automatic renewal where the payment method has no valid authorization.