What is SubScript Protocol?
SubScript Protocol is a programmable stablecoin commerce layer on Arc for one-time payments, recurring billing, usage-based charging, invoicing, AI-native transactions, payment links, signed webhooks, and human-readable USDC receipts.
Who is SubScript for?
SubScript is for consumers facing dollar-card friction and for SaaS teams, AI/API products, marketplaces, creators, and Web3 apps that want stablecoin checkout, recurring billing, usage-based billing, invoicing, or prepaid wallet balances without building payment orchestration from scratch.
What category is SubScript in?
SubScript belongs in stablecoin payments, Web3 checkout, crypto subscription billing, usage-based billing, and developer payment infrastructure.
What makes SubScript different?
SubScript combines Arc-native USDC checkout, Unified Payment Authorization, intent IDs, Arc memo receipts, Permit2-style bounded allowances, payment links, webhook fulfillment, metered vaults, Google-powered wallet onboarding, and a merchant-paid 1% fee target.
What is Unified Payment Authorization?
Unified Payment Authorization is SubScript's shared lifecycle for one-time payments, subscriptions, usage charges, invoice-like links, and AI-native payments: create an intent, approve a bounded USDC action, record an Arc memo receipt, and fulfill with a signed webhook.
Is SubScript live in production?
SubScript is in public beta on the Arc testnet. All beta payments settle in Arc testnet USDC, a test asset with no monetary value, while the protocol is hardened for the mainnet cutover. Integrations built against the beta API carry over to mainnet with a configuration change.
Which protocol claims are deployment-scoped?
Encrypted private-key export, fiat-to-USDC onramps, dedicated invoice terms, sponsor workflows, merchant commitment windows, smart dunning schedules, full Chainlink Automation, ArcaneVM production confidentiality, Paymaster sponsorship, and quantum-resilience claims should remain deployment-scoped until production configuration proves them live.
How does SubScript help users in regions with unreliable dollar cards?
SubScript avoids virtual card creation fees, monthly or annual maintenance fees, failed-card penalties, billing-address failures, FX markup surprises, and long card approval flows by letting users pay with USDC through a Google-provisioned wallet. There is also no bank-imposed card limit or per-transaction cap. Payments are funded from a local bank transfer and settle in USDC, so a bank's daily or per-charge card limit can never block a payment.
How do developers or AI agents integrate SubScript?
The fastest path is the CLI: `npx @subscriptonarc/cli init` scaffolds the checkout route, the signed-webhook handler, and env config for your framework; `add checkout` / `add webhook` add pieces to an existing app; `doctor` diagnoses one; and `listen` forwards live webhooks to localhost without a public URL. A first API call needs no account via the sandbox demo key `sk_test_demo_subscript_sandbox_2026`. There is also a typed SDK (@subscriptonarc/sdk), an MCP server for agents (@subscriptonarc/mcp), an OpenAPI 3.1 spec at /openapi.json, and a drop-in agent skill at /skills/subscript-integration/SKILL.md.
How does SubScript protect merchants?
SubScript supports merchant-side certainty through intent IDs, signed webhooks, retry-aware billing, receipt records, and UPA commitment concepts such as service lock windows, minimum commitments, and grace periods.
How does SubScript handle webhook delivery observability?
Every webhook is written to the merchant_events ledger before dispatch. Each delivery attempt is logged on a best-effort basis with its HTTP status, response body, and timestamp; attempt rows may be missing if persistence fails after the HTTP request. Endpoints are environment-scoped (TEST or LIVE) so sandbox traffic never crosses into production. Secret rotation supports a grace-period overlap so the previous signing secret stays valid while you update your handler. The dashboard exposes cursor-paginated event history with type and environment filters, one-click replay, and per-attempt visibility for most delivery attempts.