Copy page

Products

Crypto processing

dark-flag

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

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, 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.
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.
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 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 for the machine this reuses · Changelog for changes to this surface.