# Recurring payments

> [!CAUTION]
> **There is no dedicated recurring-billing API yet.** The *first* card payment can opt into the saved-card / merchant-initiated (MIT) flow via the `subscription` block on `POST /initialize-payment` (see [Server-to-Server → Saved cards and recurring payments](https://api.fynex.ai/payments-api/v2/docs#tag/server-to-server)). What's missing is the lifecycle surface: no public endpoint to charge a previously-stored card by reference, and no subscription create/manage/cancel API. If you need full recurring/subscription billing now, contact your Fynex representative — and do not rely on any `/api/v1/checkout/*` endpoints; they are not part of this API.

---

## What recurring payments will do

Recurring payments let you charge a returning customer without presenting a card form again. The customer provides their card once; Fynex stores an encrypted token on its side and returns a reference your backend uses for future charges — your servers never hold raw card data.

| Concept | What it is |
|---------|------------|
| MIT | Merchant-Initiated Transaction — a charge your server triggers without the customer present. |
| Saved card | An encrypted, PCI-scoped card token held on Fynex's infrastructure. |
| `merchantCustomerId` | A string you choose (typically your internal customer/user ID) that future charges reference. |

> [!NOTE]
> **PCI scope.** Even though raw card data stays on Fynex's infrastructure, instructing Fynex to store credentials and triggering MIT charges moves your integration into a higher-scrutiny PCI DSS category (SAQ D / Merchant Level 2). Consult your QSA before going live with recurring billing.

---

## Current state

- `POST /initialize-payment` **does** accept a `subscription` block (`subscription.enabled`, `subscription.allowSubsequentMerchantInitiated`) plus a `merchantCustomerId`. Setting these on the first payment opts it into the upstream processor's saved-card / MIT flow. See [Server-to-Server](https://api.fynex.ai/payments-api/v2/docs#tag/server-to-server).
- What's **not** yet available: a public endpoint to charge a previously-stored card *by reference* (no "charge saved card" call, no `storeCredential` field), and no subscription lifecycle API (create / update schedule / cancel). Storage is driven by the `subscription` block above, not a separate call.
- The dedicated recurring-billing surface is in development.

**To use recurring billing today:** contact your Fynex representative to discuss options for your account.

---

## What to prepare (before the API ships)

You can make the eventual migration smoother by structuring your data now:

| Data point | Why |
|------------|-----|
| A stable `merchantCustomerId` per customer | Will key the customer's saved cards once the API ships. |
| First-payment reference (`externalOrderRef`) | Links the initial card capture to the customer record. |
| Customer consent record | MIT charging requires documented cardholder agreement for stored-credential reuse. |

---

## See also

- **[Server-to-Server](https://api.fynex.ai/payments-api/v2/docs#tag/server-to-server)** — Take the initial card payment today via `POST /initialize-payment`.
- **[Hosted Checkout](https://api.fynex.ai/payments-api/v2/docs#tag/hosted-checkout)** — Collect the first payment without handling card data.
- **[Concepts](https://api.fynex.ai/payments-api/v2/docs#tag/concepts)** — Key domain concepts: GenericPayment, SellerAccount, operationalMode, and more.