Introduction
Recurring crypto subscription infrastructure with automatic payment splits.
Recurring crypto subscription infrastructure with automatic payment splits. Create plans, subscribe wallets, and receive signed webhooks as subscriptions bill.
Networks
Tidepay supports EVM chains (Polygon, Arbitrum, BNB Smart Chain, Base) and Solana. A plan's network is determined entirely by its tokenKey (e.g. usdc-polygon vs usdc-solana) — there is no separate "network" field to set. Wallet address fields (merchantDestinationWallet, a customer's walletAddress) accept either an EVM hex address or a Solana base58 address; which one is expected follows from the plan's tokenKey. Payout splits (split on plan creation) are EVM-only.
Customers
A Customer represents the payer — the wallet (and, later, other payment credentials) that funds a subscription. Create a Customer first, then pass its id as customerId when creating a Subscription. A Customer can be created before its wallet is known (e.g. while you're still onboarding the payer) — walletAddress is optional and can be set later with PATCH /customers/{customerId}, but the subscription won't begin billing until it's present.
Paylinks
A Paylink is a reusable, shareable checkout link tied to a Plan — the self-serve alternative to calling POST /subscriptions yourself. Create one with POST /paylinks, share the returned url, and anyone who opens it gets a Customer and a pending Subscription created automatically, landing directly on the wallet-connect checkout page — no prior API call or customerId needed. Set active: false via PATCH /paylinks/{paylinkId} to disable a link without deleting it.
Optionally set description/imageUrl for the redemption page, availableQuantity/expiresAt to limit a link's lifetime, and afterCompletion to customize what happens once checkout completes (a custom success message, or a redirect to your own URL). A redemption request against a deactivated, expired, or fully-redeemed link always returns the same 404 Not found — there is no distinct status code per reason.
When creating a paylink, provide either an existing planId, or a plan object to create the underlying plan at the same time — exactly one is required. Implicit plan creation doesn't support payout splits; create the plan separately via POST /plans first if you need one.
Where to go next
- Authentication — how to get and use your API key.
- Sandbox mode — testing your integration without real funds.
- API Reference — every endpoint, generated from the live OpenAPI spec.