# Crypto processing

**Status:** Dark-flag — live behind a cohort or flag

A crypto-only payment link plus recurring subscriptions, paid one tap at a time by the payer — never an authorised pull in v1.

> **Live with dashboard v2 (2026-10-08)**
>
> Crypto processing is gated by `payment_links_crypto_only` (crypto-only links and subscriptions), `api_v1.payment_links` (every payment-links, clients, products and payments operation) and `api_v1.subscriptions` (the subscription operations). While `api_v1.payment_links` or `api_v1.subscriptions` is off, its operations answer `503 temporarily_unavailable`. While `payment_links_crypto_only` is off, creating a crypto-only link, or creating or resuming a subscription, answers `409 capability_unavailable`, and existing subscriptions issue no new invoices. While the crypto rail itself is paused, activating a crypto-only link answers `409 capability_unavailable` too.

## Concept

Two related surfaces:

1. **A crypto-only payment link** — an ordinary `payment_links` object with `settlement_kind: crypto_only` and `accepted_rail_kinds: ["crypto"]`. It activates on a Bridge-less eligibility branch (a healthy Swaps Wallet and accepted payment-link terms, no Bridge customer required) and settles straight to the merchant's own wallet.
2. **Subscriptions** — a version-1 `scheduled_invoices` kind: a series of invoices reissued on a fixed interval (`monthly` / `quarterly` / `yearly`), each one an independent crypto-only payment link the payer pays themselves. No card-style authorised pull exists in v1 — that is an explicit v2-shaped kind reserved in the schema, not something v1 can do.

## Resources

| Object | What it is |
|---|---|
| `payment_links` (crypto-only) | The same object as [Payment links](/products/payment-links), constrained to crypto rails. |
| `payments` (crypto) | Adds verdict states `underpaid`, `overpaid`, `unmatched` on top of the ordinary payment lifecycle. An `unmatched` payment carries `unmatched_reason` (`partial_before_cancel` or `deposit_after_close`, `null` on rows from before the field existed) and the `payment.unmatched` event carries it too. The money is held for support, never released or refunded automatically. See [Payment links](/products/payment-links#when-money-arrives-and-no-payment-matches). |
| `subscriptions` | The schedule itself — amount, interval, next due date, the merchant's settlement wallet, plus a derived (never stored) `overdue` flag. |
| `subscription invoices` | One issued invoice per cycle — `not_issued`, `open`, `paid`, plus a derived (never stored) `overdue` flag. |

## Fee and minimums (locked)

The payer pays the invoice plus 1% in one transfer; the merchant receives the exact invoiced amount — the Tempo watcher has zero tolerance for a partial match. Minimum invoice: **$5** in the dashboard, per payment and per subscription period; the API does not enforce that floor on crypto-only links or subscriptions. Accepted stablecoins: USDC.e, pathUSD, USDT0, USD1, cUSD (all 6 decimals). Crypto processing is USD only.

## Minimal flow

1. `POST /v1/subscriptions` — create the schedule; no money moves yet.
2. On each due date, an invoice is issued as its own crypto-only payment link.
3. The payer pays that link directly — the same flow as any [payment link](/products/payment-links).
4. `GET /v1/subscriptions/{id}/invoices` for payment history; an overdue invoice does not pause or cancel the subscription by itself.

Crypto processing has no e-mails of its own yet, and the payer is not e-mailed the invoice: share each link with the payer yourself, and follow payments and subscription invoices through [webhooks](/events-webhooks) and the dashboard.

## What an agent can and cannot do here

On the hosted MCP server, `create_subscription` and `get_subscription` are `dark-flag`: the server does not register them yet, even while the switches in the note above are on. Until it does, an agent uses the REST operations above, which follow those switches. `create_subscription` drafts the schedule only; `get_subscription` returns one subscription and its derived `overdue` flag, not its payment history.

Nothing about a subscription authorizes automatic payment — every invoice is its own payer-initiated payment link, never an authorised pull the API triggers on the merchant's behalf.

Next: [Payment links](/products/payment-links) for the machine this reuses · [Changelog](/changelog) for changes to this surface.