@antelopejs/interface-subscriptions 0.0.0-stage → 0.0.2

package/docs/1.introduction.md

@@ -0,0 +1,98 @@
+# Introduction
+
+`@antelopejs/interface-subscriptions` defines provider-agnostic recurring
+billing for AntelopeJS applications. A backend written against it bills a saved
+payment method every period and learns what happened — paid, failed, ended —
+without naming a provider, and without running a billing cycle of its own.
+
+## Why a second interface
+
+Every call in `@antelopejs/interface-payment` is request and response against
+the provider. A subscription is different in kind: it is a long-lived object
+that must be acted on **when nobody is calling**. It needs two things the
+payment contract never needed:
+
+1. **Durable state** — the subscription, its current period, its status.
+2. **The passage of time** — something must fire at each renewal.
+
+A provider with native subscriptions supplies both. A provider without them
+leaves the merchant to fire each charge, and then something has to supply both
+on the merchant's side. That something is a module with a database and a clock,
+which is a subscriptions module's business and not a payment module's — so the
+contract is its own interface, and:
+
+- a payment module whose provider cannot do subscriptions does not implement it,
+  rather than implementing it badly;
+- the generic fallback, `@antelopejs/payment-subscriptions`, can depend on a
+  database and a scheduler without forcing either on every payment consumer;
+- consumers that do not bill recurrently do not carry the surface.
+
+## Who fires the renewal
+
+The question that sorts providers is not "is there a subscription object" but
+"who fires each renewal charge". That is exactly what the fallback has to
+supply.
+
+| The provider fires renewals | The merchant fires them       |
+| --------------------------- | ----------------------------- |
+| Stripe, PayPal, Mollie      | Adyen, Checkout.com, Mangopay |
+
+The split is even, so the fallback is half the providers rather than a rare edge.
+[The capability matrix](./5.provider-capability-matrix.md) has the detail.
+
+## The portable core
+
+Expressible everywhere, including by the fallback:
+
+- an amount, an interval and an interval count;
+- a billing anchor (when the first paid period starts) or a trial end;
+- a status, including `past_due`;
+- cancelling now, or at the end of the period paid for;
+- the current period's start and end.
+
+Deliberately not modelled, because the fallback cannot honour them and a
+contract only some implementations keep is a lie: proration, dunning schedules,
+tax, coupons and discounts, metered billing, and more than one item per
+subscription. A backend that needs one of these uses the provider's own
+interface (`@antelopejs/interface-stripe`) alongside this one.
+
+## Built on the payment interface
+
+A subscription charges a method saved through `@antelopejs/interface-payment`,
+off-session. That pair — one on-session payment that saves a method, then any
+number of off-session charges against it — is the payment interface's portable
+recurring primitive, and this interface adds nothing underneath it.
+
+Identifiers cross the two interfaces unchanged: a subscription's `customer`,
+`paymentMethod` and `latestPayment` are payment-interface identifiers from the
+same account, and `provider` selects that account in both.
+
+## Installation
+
+```bash
+pnpm add @antelopejs/interface-subscriptions
+```
+
+Wire a module that implements it alongside a payment module.
+
+## Conventions
+
+**Amounts are the payment interface's `Amount`**: integer minor units and an
+uppercase ISO-4217 code.
+
+**Times are Unix epoch milliseconds**, and periods are counted in UTC.
+
+**Every mutating call takes an idempotency key**, positionally. Replaying it
+returns the original outcome within the provider-defined replay window,
+including rejections where the provider retains them. After expiration,
+applications must reconcile uncertain payments before retrying; replay
+protection is not indefinite.
+
+**A failed renewal is a status, not an exception.** The subscription goes
+`past_due` and a `subscription.payment_failed` event is raised. Only a declined
+_first_ period rejects, because then there is no subscription to put in a state.
+
+**`vendorData` is a read-only echo.** An implementation may surface what its
+provider said; no request accepts provider-specific settings, because a
+`Record<string, unknown>` that compiles against every provider and works on one
+hides exactly the coupling this interface exists to prevent.

package/docs/2.subscriptions.md

@@ -0,0 +1,147 @@
+# Subscriptions
+
+## Creating one
+
+The payer is not present when a subscription charges, so the mandate is taken
+first, through the payment interface. Create an on-session payment with
+`savePaymentMethod: true`, `customer` and `returnUrl`, and persist its ID.
+If it returns `requires_action`, send the payer to `redirectUrl`. Do not list
+saved methods or start the subscription while the payment is still pending or
+requires action, or if it failed or was canceled.
+
+After a verified `payment.succeeded` or `payment.authorized` event, or a server
+read with `GetPayment` reporting one of those states, use `ListPaymentMethods`
+to find the saved method matching that payment's `paymentMethod`. Do not select
+an unrelated method just because it appears first. The [README quick start](../README.md#quick-start)
+shows the checkout and reconciliation steps separately.
+
+`savePaymentMethod` cannot be combined with `offSession` — a mandate can only be
+taken from a payer who is there. That first payment is an ordinary one-off; the
+subscription starts after it, and its first period is a separate charge.
+
+```ts
+const subscription = await CreateSubscription(
+  {
+    reference: accountId,
+    customer,
+    paymentMethod: method.id,
+    amount: { value: 1900, currency: "EUR" },
+    interval: "month",
+    intervalCount: 1,
+  },
+  `subscribe-${accountId}`,
+);
+```
+
+Without a trial or a billing anchor, the first period is charged off-session
+before `CreateSubscription` resolves:
+
+| First charge             | Result                                                                                        |
+| ------------------------ | --------------------------------------------------------------------------------------------- |
+| Succeeded                | An `active` subscription                                                                      |
+| Still settling (a debit) | An `active` subscription; if the charge later fails it goes `past_due`                        |
+| Declined                 | Rejects with `SubscriptionPaymentError`, carrying the declined `Payment`. Nothing is created. |
+
+Replaying the idempotency key within the provider-defined replay window returns
+the saved outcome, including a rejection where retained by the provider.
+After expiration, applications must reconcile uncertain payments and subscription
+creation before retrying; the same key can create another charge.
+
+## Periods
+
+A period is `intervalCount` × `interval`, where the interval is `day`, `week`,
+`month` or `year`. Every implementation accepts periods up to a year; a longer
+one may be refused with `InvalidSubscriptionRequestError`.
+
+Periods are counted from the billing anchor in calendar units, in UTC, and never
+from the end of the previous period. A monthly subscription anchored on 31
+January renews on 28 February (29 in a leap year), then on 31 March — not on the
+28th of every month from then on.
+
+`currentPeriodStart` and `currentPeriodEnd` describe the period most recently
+billed for. The next charge is made at `currentPeriodEnd`.
+
+## Trials and billing anchors
+
+Both defer the first charge, and they are mutually exclusive.
+
+- **`trialEnd`**: the subscription is `trialing` until then, nothing is charged,
+  and the first paid period starts at the trial end.
+- **`billingAnchor`**: the subscription is `active` until then — it exists and is
+  in good standing — but nothing is charged until the anchor, where the first paid
+  period starts.
+
+In both cases the period before the first charge runs from creation to that
+time, so `currentPeriodEnd` is the trial end or the anchor.
+
+## Statuses
+
+| Status     | Meaning                                                                                        |
+| ---------- | ---------------------------------------------------------------------------------------------- |
+| `trialing` | Before `trialEnd`. Nothing charged.                                                            |
+| `active`   | The current period is paid for, or not yet due.                                                |
+| `past_due` | Charging the current period failed. The implementation is retrying under its own policy.       |
+| `canceled` | Ended. Terminal. `endedAt` and `endReason` (`requested` or `payment_failed`) say when and why. |
+
+When a renewal fails, the period still advances: the new period is the current
+one, and `past_due` says it is unpaid. When a retry succeeds the subscription is
+`active` again in the same period; the cycle does not move.
+
+### `past_due` is portable to report, not to predict
+
+What happens after a failure is the implementation's: a native provider follows
+the retry schedule configured in its dashboard, and the generic fallback follows
+its documented policy (three retries, one, three and seven days apart, then the
+subscription ends with `endReason: "payment_failed"`). Two subscriptions in the
+same state may therefore behave differently on different providers. Decide access
+from the status; do not schedule anything on the assumption of a retry date.
+
+## Recovering a `past_due` subscription
+
+If the saved method will not work again — an expired card — take a new mandate
+on-session and switch to it:
+
+```ts
+await UpdateSubscriptionPaymentMethod(
+  subscription.id,
+  newMethodId,
+  idempotencyKey,
+);
+```
+
+Nothing is charged by the switch. The next scheduled attempt uses the new method.
+
+## Cancelling
+
+```ts
+await CancelSubscription(id, `cancel-period-end-${id}`, "period_end"); // run out the paid period
+await CancelSubscription(id, `cancel-now-${id}`, "now"); // end immediately
+```
+
+Use distinct keys for distinct operations. Reuse a key only when retrying the
+same request; reusing the period-end key for immediate cancellation replays the
+first outcome instead of applying the change.
+
+- `period_end` sets `cancelAtPeriodEnd`. The status does not change until the
+  period ends, at which point the subscription ends instead of renewing. Asking
+  again is not an error.
+- `now` ends it at once. Nothing is refunded; refunds are `RefundPayment` on the
+  payment interface. A subscription set to end at period end can still be ended
+  now.
+- Either on a subscription that has already ended raises
+  `InvalidSubscriptionStateError`, unless the idempotency key is a replay.
+
+## Errors
+
+| Error                             | When                                                                         |
+| --------------------------------- | ---------------------------------------------------------------------------- |
+| `SubscriptionNotFoundError`       | No subscription has that identifier under that `provider`                    |
+| `InvalidSubscriptionRequestError` | A request outside the contract: a non-positive amount, a past trial end, ... |
+| `InvalidSubscriptionStateError`   | A change to a subscription that has ended                                    |
+| `SubscriptionPaymentError`        | The first period was charged and declined; nothing was created               |
+| `SubscriptionError`               | The base class; also the call could not be made at all                       |
+
+Each carries `providerCode` where the provider gave one.
+`InvalidSubscriptionStateError.status` is an optional `SubscriptionStatus`
+describing the actual state that blocked the operation. Its constructor is
+`new InvalidSubscriptionStateError(message, status?, providerCode?)`.

package/docs/3.events.md

@@ -0,0 +1,79 @@
+# Events
+
+A subscription changes while nobody is calling, so a backend learns of renewals,
+failures and endings from events.
+
+## The event set
+
+| Type                             | When                                                                         |
+| -------------------------------- | ---------------------------------------------------------------------------- |
+| `subscription.created`           | The subscription exists                                                      |
+| `subscription.payment_succeeded` | A period was paid for, including the first                                   |
+| `subscription.payment_failed`    | Charging a period failed; the status is `past_due`, or the retries are spent |
+| `subscription.canceled`          | It ended, for any reason                                                     |
+
+An event carries the subscription as it was when the event happened, and, for
+the two payment events, the payment-interface identifier of the charge in
+`payment`. Read the charge with `GetPayment` for the amount or the decline
+reason. A `subscription.payment_failed` has no `payment` when the provider
+refused to make the charge at all — the saved method had been removed, say.
+
+Changing the payment method and scheduling a cancellation at period end raise no
+event: the caller made those changes and already knows.
+
+## Receiving them
+
+```ts
+import { SubscriptionEvents } from "@antelopejs/interface-subscriptions";
+
+SubscriptionEvents.register("billing", async (event) => {
+  if (await alreadyHandled(event.id)) return;
+  await applyToAccount(event);
+});
+```
+
+`SubscriptionEvents` is a registering proxy, not a webhook route. Handlers are
+registered under an identifier unique within your module, and unregistered
+automatically when your module unloads.
+
+Register handlers when your module starts. An event is delivered to the
+handlers registered at the time; one raised while none are registered reaches
+nobody and is not kept.
+
+Delivery is **at least once**:
+
+- A handler that throws or rejects has not handled the event, and it is delivered
+  again later — to every handler, so de-duplicate on `event.id`.
+- A crash between a change and its delivery means the event is delivered when the
+  implementation next looks at that subscription.
+- In a cluster, each event is delivered by one instance, to the handlers
+  registered in that instance.
+
+Events may arrive late, and should not be read as more recent than state you
+already hold. `GetSubscription` is always current.
+
+## How implementations learn of them
+
+That is each implementation's business, and invisible to a consumer:
+
+- the generic fallback raises them from its own renewal clock, recording each in
+  its database with the change that caused it;
+- a native provider raises them from the provider's webhooks.
+
+## Relation to payment events
+
+Every subscription charge is an ordinary payment-interface payment, so its
+`payment.*` events reach your payment webhook route as well. They carry
+`SUBSCRIPTION_METADATA_KEY` (`antelopeSubscription`) in their metadata, set to
+the subscription's identifier:
+
+```ts
+const event = await VerifyWebhook(request);
+if (event?.payment?.metadata?.[SUBSCRIPTION_METADATA_KEY]) {
+  return; // a subscription charge: handled by the subscription event
+}
+```
+
+Handle a subscription charge in one place. The subscription event is the one
+that says what the charge meant — which period it paid for, whether the
+subscription is now `past_due`.

package/docs/4.implementing.md

@@ -0,0 +1,158 @@
+# Implementing the interface
+
+There are two kinds of implementation, and both are expected from the start.
+
+## Native: the provider fires renewals
+
+A payment module whose provider has first-class subscriptions (Stripe, PayPal,
+Mollie) implements this interface beside `@antelopejs/interface-payment`, in the
+same module, mapping each call onto the provider's subscription object. It owns
+no clock and no database.
+
+What it must do that the provider will not do for it:
+
+- **Validate with `ValidateSubscriptionRequest`** before anything reaches the
+  provider, so every implementation enforces the portable request shape. Defer
+  relative date validation to a provider that checks its idempotency cache
+  first; a replay must not fail because its original date has passed. An
+  unknown customer or payment method is an `InvalidSubscriptionRequestError`
+  too, never a `SubscriptionNotFoundError`, which is reserved for the
+  subscription itself.
+- **Report only its own subscriptions.** A provider account may hold
+  subscriptions made elsewhere — a hosted checkout, the dashboard. They were not
+  created through this interface, have no `reference`, and must not be listed,
+  read or raised as events.
+- **Charge the first period at creation, or refuse.** A declined first charge
+  rejects with `SubscriptionPaymentError` and leaves nothing behind. On Stripe
+  this is `payment_behavior: "error_if_incomplete"`.
+- **Count periods from the anchor**, in UTC calendar units. Providers that bill
+  from an anchor already do.
+- **Map the provider's statuses onto four.** Anything that means "a charge
+  failed and the provider is retrying" is `past_due`; anything that has ended or
+  will never charge again is `canceled`. Where the provider can hold a
+  subscription that will never charge again without ending it — Stripe's
+  `unpaid` — say so, and tell the merchant to configure it to cancel instead.
+- **Raise the four events** from the provider's webhooks. A module that already
+  normalises webhooks for the payment interface can raise subscription events from
+  the same deliveries.
+- **Mark charges** with `SUBSCRIPTION_METADATA_KEY` when it normalises the
+  underlying payments, so a consumer can tell them from one-off payments.
+- **Echo, never accept, `vendorData`.**
+
+## Fallback: the merchant fires renewals
+
+For every provider that leaves each charge to the merchant, wire
+`@antelopejs/payment-subscriptions`. It implements this interface on top of any
+payment-interface provider, keeps every subscription in
+`@antelopejs/interface-database`, and fires renewals from its own clock — the
+Redis scheduler when one is wired, polling the database when not.
+
+A payment module should not implement this interface by embedding a clock of its
+own: that would put a mandatory database and scheduler into a payment module.
+
+## Wiring an implementation
+
+The calls are declared directly as the public names, so the whole module is the
+declaration:
+
+```ts
+import * as subscriptions from "@antelopejs/interface-subscriptions";
+import { ImplementInterface } from "@antelopejs/interface-core";
+
+export function construct(): void {
+  ImplementInterface(subscriptions, {
+    CreateSubscription,
+    GetSubscription,
+    ListSubscriptions,
+    CancelSubscription,
+    UpdateSubscriptionPaymentMethod,
+    SubscriptionEvents: { register, unregister },
+  });
+}
+```
+
+`SubscriptionEvents` is a registering proxy: its implementation is a `register`
+and `unregister` pair that keep the handlers your module delivers to.
+
+List the interface in `antelopeJs.implements`, and the payment interface in
+`dependencies`.
+
+## `ValidateSubscriptionRequest`
+
+`ValidateSubscriptionRequest(request: SubscriptionRequest, now?: number): void`
+checks the portable request rules synchronously. Supply `now` to also check
+that trial and billing dates are in the future. It is Unix epoch
+**milliseconds**, such as `Date.now()`, not seconds. Pass your injected clock
+in tests or in an implementation that controls time.
+
+```ts docs-check
+import {
+  ValidateSubscriptionRequest,
+  type SubscriptionRequest,
+} from "@antelopejs/interface-subscriptions";
+
+export function validateBeforeCreation(request: SubscriptionRequest): void {
+  ValidateSubscriptionRequest(request, Date.now());
+}
+```
+
+The function returns `undefined` on success and throws
+`InvalidSubscriptionRequestError` with a message naming the first failed rule:
+
+- `reference`, `customer` and `paymentMethod` must be non-empty.
+- `amount.value` must be a positive integer of minor units; `amount.currency`
+  must contain exactly three uppercase letters. The helper checks the format,
+  not membership in an ISO currency registry.
+- `interval` must be `day`, `week`, `month` or `year`; an explicit
+  `intervalCount` must be a positive integer.
+- `trialEnd` and `billingAnchor` are mutually exclusive. Each, if supplied,
+  must be finite. When `now` is supplied, each must also be strictly greater
+  than `now` (equality is invalid).
+
+An implementation may omit `now` only when its provider validates future dates
+after resolving idempotent replays. Stripe uses this form: a retry with the
+original key and parameters can return the saved subscription after its trial
+or billing anchor has passed. A new request with a past date still fails at
+the provider. Implementations that own their idempotency storage must resolve
+replays before applying relative date validation themselves.
+
+This helper does not contact a provider, verify customer or saved-method
+existence, or enforce provider-specific maximum periods. Implementations must
+perform those checks separately and also report invalid requests with
+`InvalidSubscriptionRequestError`.
+
+## The conformance suite
+
+`dist/tests/*.test.js` ships in the package. `ajs module test` runs it
+automatically against any module that lists this interface in
+`antelopeJs.implements`.
+
+It is weaker than the payment interface's suite, and the reason matters before
+anyone reads a green run as a promise: **a test cannot wait a month.** Stripe has
+test clocks, but Mollie and PayPal do not, so a portable suite cannot pin a
+renewal, a trial ending, a failed retry or a period end. What it covers:
+
+- creating a subscription that charges at once, a trial, a billing anchor;
+- the first charge's shape and its metadata marker;
+- idempotent replay of creation and cancellation;
+- reading back, listing newest first and per customer;
+- cancelling now and at period end, and refusing to change one that has ended;
+- switching the payment method;
+- unknown identifiers and every invalid request;
+- a declined first period, when the provider can supply a method that saves and
+  then declines;
+- events, when they can reach the test process.
+
+Everything time-driven is pinned instead by the generic fallback's own suite,
+which drives an injected clock. That suite is the executable specification a
+native implementation's renewal behaviour is checked against by eye.
+
+| Variable                                            | Purpose                                                                     |
+| --------------------------------------------------- | --------------------------------------------------------------------------- |
+| `ANTELOPE_PAYMENT_TEST_METHOD`                      | A token that saves on-session and charges off-session.                      |
+| `ANTELOPE_SUBSCRIPTIONS_TEST_METHOD_DECLINES_LATER` | A token that saves on-session and is declined off-session.                  |
+| `ANTELOPE_SUBSCRIPTIONS_TEST_EVENTS`                | Set when the implementation's events reach the test process during the run. |
+| `ANTELOPE_PAYMENT_TEST_CURRENCY`                    | ISO-4217 code to run against. Defaults to `EUR`.                            |
+
+With nothing implementing the interface, the calls queue and the suite times
+out; it cannot report green by accident.

package/docs/5.provider-capability-matrix.md

@@ -0,0 +1,61 @@
+# Provider capability matrix
+
+Which providers fire renewals themselves decides which implementation a
+deployment needs. Checked against each provider's documentation on 2026-09-18;
+Stripe and PayPal were not re-checked then, both having first-class subscription
+objects that bill on their own schedule.
+
+| Provider     | Who fires renewals | Implementation                                                |
+| ------------ | ------------------ | ------------------------------------------------------------- |
+| Stripe       | Provider           | Native, in `@antelopejs/stripe`                               |
+| PayPal       | Provider           | Native                                                        |
+| Mollie       | Provider           | Native                                                        |
+| Adyen        | Merchant           | `@antelopejs/payment-subscriptions`                           |
+| Checkout.com | Merchant           | `@antelopejs/payment-subscriptions`                           |
+| Mangopay     | Merchant           | `@antelopejs/payment-subscriptions`, with a provider schedule |
+
+- **Mollie**: _"When using this API, we automatically create recurring payments
+  for you at the interval you specified."_
+- **Adyen**: subscriptions are _"recurring transactions you initiate at regular
+  intervals"_, against a stored token and `shopperReference`.
+- **Checkout.com**: no subscription or billing-plan resource at all. Recurring
+  is a stored instrument plus `payment_type: Recurring` and
+  `merchant_initiated: true` on an ordinary payment.
+- **Mangopay**: the Recurring PayIn Registration stores frequency, dates and
+  amounts, and handles the authentication chain between charges, but _"the
+  platform can initiate payments"_ — Mangopay does not fire them. The fallback
+  owns the clock and can record the schedule with Mangopay through its provider
+  schedule seam.
+
+Implemented: the generic fallback, and Stripe natively in `@antelopejs/stripe`,
+which passes the conformance suite against live Stripe and is further tested on
+Stripe test clocks — renewal, trial end, `past_due` and cancellation at period
+end — which the portable suite cannot pin. PayPal and Mollie are plans.
+
+Times are kept at each provider's precision, which the contract only promises
+to the second: Stripe stores seconds. Mollie's subscription `startDate` is a
+calendar date, so on Mollie a trial end or billing anchor lands on a day rather
+than an instant — a native Mollie implementation has to say so, or charge the
+first period itself. Unverified against Mollie.
+
+## Where native and fallback differ, and the contract allows it
+
+| Behaviour                     | Native                                                                               | Fallback                                                  |
+| ----------------------------- | ------------------------------------------------------------------------------------ | --------------------------------------------------------- |
+| What happens after `past_due` | The provider's configured retry schedule                                             | Three retries, one, three and seven days apart, then ends |
+| When a renewal is charged     | The provider's scheduler, near the time                                              | At the time with Redis wired; within one poll otherwise   |
+| `vendorData`                  | What the provider said                                                               | Absent                                                    |
+| Events                        | From the provider's webhooks                                                         | From its own clock, recorded with each change             |
+| An event's subscription       | Stripe invoice events: read back at delivery, so a redelivery may show a later state | As it was when the event happened                         |
+
+## Out of scope, and why
+
+| Feature                        | Why it is out                                                                        |
+| ------------------------------ | ------------------------------------------------------------------------------------ |
+| Proration                      | Arithmetic every provider does differently, and the fallback would have to invent it |
+| Dunning schedules              | Native providers configure retries in their dashboard; only the status is portable   |
+| Tax                            | A tax engine is a product of its own                                                 |
+| Coupons and discounts          | Provider objects with provider semantics                                             |
+| Metered and usage billing      | Needs usage reporting the fallback has no source for                                 |
+| Several items per subscription | Needs proration to change any one of them                                            |
+| Write-through `vendorData`     | Compiles everywhere, works on one provider: invisible coupling                       |

package/docs/tsconfig.json

@@ -0,0 +1,14 @@
+{
+  "extends": "../tsconfig.json",
+  "compilerOptions": {
+    "noEmit": true,
+    "composite": false,
+    "incremental": false,
+    "rootDir": "..",
+    "baseUrl": "..",
+    "paths": {
+      "@antelopejs/interface-subscriptions": ["src/index.ts"]
+    }
+  },
+  "include": ["../src", "./**/*.ts"]
+}

package/package.json

@@ -1,6 +1,82 @@
 {
   "name": "@antelopejs/interface-subscriptions",
-  "version": "0.0.0-stage",
-  "stub": true,
-  "description": "Temporary package placeholder for staged publishing"
-}
+  "version": "0.0.2",
+  "description": "Provider-agnostic AntelopeJS subscriptions interface: recurring billing of a saved payment method, with trials, cancellation and normalised lifecycle events",
+  "keywords": [
+    "antelopejs",
+    "billing",
+    "interface",
+    "recurring",
+    "subscription"
+  ],
+  "homepage": "https://github.com/AntelopeJS/interface-subscriptions/tree/main/docs",
+  "bugs": {
+    "url": "https://github.com/AntelopeJS/interface-subscriptions/issues"
+  },
+  "license": "Apache-2.0",
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/AntelopeJS/interface-subscriptions.git"
+  },
+  "files": [
+    "dist",
+    "docs",
+    "skills"
+  ],
+  "main": "dist/index.js",
+  "types": "dist/index.d.ts",
+  "exports": {
+    ".": {
+      "types": "./dist/index.d.ts",
+      "default": "./dist/index.js"
+    },
+    "./tests/*": {
+      "types": "./dist/tests/*.d.ts",
+      "default": "./dist/tests/*.js"
+    },
+    "./package.json": "./package.json"
+  },
+  "publishConfig": {
+    "access": "public",
+    "provenance": true
+  },
+  "scripts": {
+    "build": "rimraf dist && tsc",
+    "test": "pnpm build && ajs module test .",
+    "format": "oxfmt .",
+    "lint:fix": "oxlint --fix",
+    "lint": "oxlint",
+    "prepack": "pnpm run build",
+    "release": "pnpm run lint && pnpm run prepack && release-it",
+    "format:check": "oxfmt --check .",
+    "knip": "knip"
+  },
+  "devDependencies": {
+    "@antelopejs/core": "1.16.0",
+    "@antelopejs/interface-core": ">=0.0.5 <1.0.0",
+    "@antelopejs/interface-payment": ">=0.0.2 <1.0.0",
+    "@antelopejs/tooling-configs": "^0.0.8",
+    "@types/mocha": "^10.0.10",
+    "@types/node": "^22.19.15",
+    "eslint-plugin-perfectionist": "^5.11.0",
+    "knip": "^6.34.0",
+    "oxfmt": "^0.66.0",
+    "oxlint": "1.81.0",
+    "oxlint-tsgolint": "^7.0.2001",
+    "release-it": "^19.2.4",
+    "release-it-changelogen": "^0.1.0",
+    "rimraf": "^6.1.3",
+    "typescript": "^5.9.3"
+  },
+  "peerDependencies": {
+    "@antelopejs/interface-core": ">=0.0.5 <1.0.0",
+    "@antelopejs/interface-payment": ">=0.0.2 <1.0.0"
+  },
+  "packageManager": "pnpm@10.6.5",
+  "antelopeJs": {
+    "test": "src/antelope.test.ts",
+    "skills": [
+      "./skills"
+    ]
+  }
+}