Self-serve subscription cancel

Give your customers a "Cancel my subscription" button without exposing your secret key or building a custom auth flow.

Customers should be able to cancel their subscription themselves. It's the friendliest thing to do, and it cuts down support volume. Strimz doesn't ship a hosted "Cancel my subscription" page because cancellation almost always involves business logic that's specific to your product. But the API call is one line; building the surrounding UI is straightforward.

Here's the pattern that works.

The shape

The customer is already authenticated in your app. They have a session cookie, a JWT, whatever you use. From their billing page, they click "Cancel subscription." Your server makes the Strimz API call. The Strimz secret key never reaches the browser.

[Customer's browser]
        │
        │  POST /api/account/cancel-subscription
        ▼
[Your server]
        │
        │  1. Verify their session.
        │  2. Look up their Strimz subscription id.
        │  3. Call strimz.subscriptions.cancel({ id }).
        ▼
[Strimz]

The Strimz API key stays on your server. The customer's auth happens however you already auth them. You don't need a separate Strimz-specific login.

Setup

You need the customer's Strimz subscription id. This was given to you in the subscription.created webhook when they signed up; you stored it on their account row.

-- Your users table
ALTER TABLE users ADD COLUMN strimz_subscription_id TEXT;

When subscription.created fires:

webhooks handler

case 'subscription.created': {
  await db.user.update({
    where: { walletAddress: event.data.payerAddress },
    data: { strimzSubscriptionId: event.data.id },
  })
  break
}

Now your server can look up the subscription id from the authenticated user.

The cancel route

app/api/account/cancel-subscription/route.ts

import { StrimzClient } from '@strimz/sdk'
import { getCurrentUser } from '@/lib/auth' // your existing auth
 
const strimz = new StrimzClient({ apiKey: process.env.STRIMZ_API_KEY! })
 
export async function POST(req: Request) {
  // 1. Verify their session.
  const user = await getCurrentUser(req)
  if (!user) {
    return Response.json({ error: 'unauthorized' }, { status: 401 })
  }
 
  // 2. Look up their subscription id.
  if (!user.strimzSubscriptionId) {
    return Response.json({ error: 'no_active_subscription' }, { status: 404 })
  }
 
  // 3. Call Strimz.
  try {
    const subscription = await strimz.subscriptions.cancel({
      id: user.strimzSubscriptionId,
      reason: 'customer self-serve',
    })
 
    return Response.json({
      success: true,
      cancelledAt: subscription.cancelledAt,
      accessUntil: subscription.currentPeriodEndAt,
    })
  } catch (err) {
    // already-cancelled, etc.
    return Response.json({ error: err.message }, { status: 400 })
  }
}

The button

app/account/billing/page.tsx

'use client'
 
import { useState } from 'react'
import { useRouter } from 'next/navigation'
 
export function CancelSubscriptionButton({ accessUntil }: { accessUntil: string }) {
  const [confirming, setConfirming] = useState(false)
  const [isPending, setIsPending] = useState(false)
  const router = useRouter()
 
  const cancel = async () => {
    setIsPending(true)
    const res = await fetch('/api/account/cancel-subscription', { method: 'POST' })
 
    if (res.ok) {
      router.refresh() // re-fetch billing state
    } else {
      alert('Something went wrong. Please contact support.')
    }
    setIsPending(false)
    setConfirming(false)
  }
 
  if (!confirming) {
    return <button onClick={() => setConfirming(true)}>Cancel subscription</button>
  }
 
  return (
    <div className="confirm">
      <p>
        Are you sure? You won't be charged again. Your access ends{' '}
        {new Date(accessUntil).toLocaleDateString()}.
      </p>
      <button onClick={cancel} disabled={isPending}>
        Yes, cancel
      </button>
      <button onClick={() => setConfirming(false)} disabled={isPending}>
        Never mind
      </button>
    </div>
  )
}

The page that uses it:

app/account/billing/page.tsx

import { getCurrentUser } from '@/lib/auth'
import { CancelSubscriptionButton } from './cancel-button'
 
export default async function BillingPage() {
  const user = await getCurrentUser()
  const subscription = await strimz.subscriptions.retrieve(user.strimzSubscriptionId)
 
  return (
    <div>
      <h1>Billing</h1>
      <p>
        Plan: <strong>Pro</strong> · {subscription.amount} {subscription.currency} / month
      </p>
      <p>Next charge: {new Date(subscription.nextChargeAt).toLocaleDateString()}</p>
      <CancelSubscriptionButton accessUntil={subscription.currentPeriodEndAt} />
    </div>
  )
}

That's the whole flow. Strimz stops charging as soon as the cancel call returns. Keeping access until currentPeriodEndAt is your product's choice, since the customer already paid for that period.

The API also queues an on-chain cancel. It works with the subscriptions contract from the next testnet redeploy (#142). On the current deployment it reverts, so the contract still lists the subscription as live. Strimz does not charge it.

When the cancellation lands

subscription.cancelled fires during the cancel call, with data.status: 'cancelled'. You already have the details from the API response, but update from the webhook too so every path ends in the same state.

case 'subscription.cancelled': {
  const sub = event.data
  await db.user.update({
    where: { strimzSubscriptionId: sub.id },
    data: {
      cancelledAt: new Date(sub.cancelledAt),
      accessUntil: new Date(sub.currentPeriodEndAt),
    },
  })
  break
}

No later event fires when the period ends. Revoke access when accessUntil passes, from your own job or on the next request.

A customer can also cancel from their wallet by calling cancel() on the subscriptions contract. Strimz marks the subscription cancelled, but no webhook fires for that path today, so check subscriptions.retrieve if your records and Strimz disagree.

Why this pattern

The Strimz API key never touches the browser. The customer's auth uses your existing system; you don't need to give them a Strimz-specific login. The cancellation is one API call from your server; your server controls the policy (do they need to confirm? do they get a refund? do they see a "are you sure?" page?).

We don't ship a Strimz-hosted cancel page because the right cancellation policy varies. Some products refund unused time; some don't. Some run a win-back flow; some let customers leave immediately. Building one cancel UX into Strimz would be wrong for most merchants. The primitive is what you need; the policy is yours to compose.