@jskit-ai/payments-core 0.1.1

package/docs/conformance.md

@@ -0,0 +1,91 @@
+# Portable payment examples and conformance
+
+`contracts/conformance.json` is ordinary JSON, also exported as
+`@jskit-ai/payments-core/conformance.json`. Read the file as data; no Node process,
+JSKIT import, editor service or Genesis command is necessary to interpret it.
+It accompanies the draft-07 configuration schema and the semantic contract.
+These are test examples, not a production workflow interpreter.
+
+## Configuration examples
+
+Each `configurationCases` entry supplies a complete payment-relevant document
+and two expected booleans:
+
+- `schemaValid`: validate `document.extensions.payments` against
+  `configuration.schema.json` using a draft-07 validator, without coercing values,
+  injecting defaults or removing unknown properties.
+- `configurationValid`: after that validation, apply the connection references
+  below. This does not replace full integration-document validation.
+
+For each named payment environment:
+
+1. Resolve `integrationId` from `document.integrations`; absence fails.
+2. Require provider `stripe` or `paddle`, `accountMode` equal to `shared`, and
+   `authentication.method` equal to `api-key`.
+3. Require `authentication.secretRef` to match `env:[A-Z_][A-Z0-9_]*` in its
+   entirety. This describes a reference; never read or copy a real secret into
+   the test fixture or source configuration.
+4. For Paddle, require the integration's `settings.environment` to equal the
+   payment environment, and require `taxCategory` and `publicClientTokenRef` in
+   the payment binding. Their values already passed the payment schema.
+
+The examples distinguish malformed prices/credits/features and inline secrets
+from structurally valid but unresolved or mismatched merchant connections.
+The fixture credentials are references only. Passing validation does not prove
+that an Env value exists, that a merchant owns a key, or that it can take payments.
+Resolve and verify those resources separately at application setup.
+
+## Account behavior sequence
+
+`accountScenario` supplies the payment-relevant configuration, merchant and
+subject scope, initial UTC clock in milliseconds, and a provider customer to
+bind to that subject. Start with a fresh transactional fixture database. Process
+`steps` in order without contacting a provider:
+
+- `clock` replaces the test clock for that and later steps.
+- `subjectId` selects another subject for that step only. Otherwise use the
+  scenario's subject. This models trusted app composition, not a public request.
+- `operation` names the semantic operation in the contract. Map it explicitly
+  to the framework's service in the test; do not expose dynamic method invocation
+  as an app endpoint.
+- `input` is the operation input. For `reconcileEvent`, `facts` is the current
+  provider snapshot returned by the controlled loader after customer binding.
+  Raw webhook authentication is tested separately; these facts are not an
+  unsigned webhook payload to accept in production.
+- `expect` asserts every listed field recursively. Arrays and primitive values
+  must match exactly. Unlisted result fields are permitted; extra array entries
+  are not. `error` instead requires that semantic error code and a rolled-back
+  operation, preserving state for later steps.
+
+The sequence covers initial paid renewal, duplicate delivery, another delivery
+for the same invoice, stable debit references, mismatched retry input, isolation
+from another tenant, expiry exactly at period end, expired refunds, promotional
+credits and rejection of overspending. Credit expiry and feature access are
+separate assertions. An expired allowance never becomes a fresh grant on retry.
+
+## Framework and CLI ownership
+
+A Laravel application uses its own JSON parser/validator, policies, models,
+transactions and test tools to implement these cases. An assistant can translate
+the sequence into that app's PHPUnit/Pest tests without installing this JavaScript
+runtime. The application selects its billable model and schema; the fixture does
+not prescribe table names or copy JSKIT's storage internals into another framework.
+
+A Node CLI consumer can run the same semantic calls against its installed JSKIT
+services. Genesis may describe the project's test command, but these fixtures do
+not require Genesis to execute it. Vibe64 configuration must preserve these same
+values rather than inventing a different hosted payment format.
+
+## Evidence boundaries
+
+The package's `test/conformance.test.js` checks all configuration examples and
+the full account sequence against the actual JSKIT service and SQLite storage.
+An independent Python draft-07 validator plus the explicit reference rules also
+checked the 11 configuration examples without importing Node or JSKIT. This
+establishes independent interpretation of configuration, not a PHP payment engine.
+
+Native Laravel execution, cross-process MySQL/PostgreSQL transactions, raw webhook
+delivery and real provider checkout are separate evidence. These examples do not
+certify them. The editor management-command conformance also remains a separate
+consumer contract; portable account tests cannot substitute for its authorization,
+review, source/release and environment checks.

package/docs/contract.md

@@ -0,0 +1,126 @@
+# Portable payment contract v1
+
+The application owns this contract and its runtime data. A UI and a CLI edit the
+same `integrations.json` declaration at `extensions.payments`. Its normative
+structural definition is `../contracts/configuration.schema.json`, shipped as
+`@jskit-ai/payments-core/configuration.schema.json`. Any JSON Schema draft-07
+validator can consume it. Cross-reference constraints below supplement it.
+
+Example extension (inside the ordinary integrations document):
+
+```json
+{
+  "payments": {
+    "version": 1,
+    "environments": {
+      "sandbox": {
+        "integrationId": "billing",
+        "providerAccountId": "acct_replace_with_your_account",
+        "webhookSecretRef": "env:PAYMENT_WEBHOOK_SECRET",
+        "returnUrlRef": "env:PAYMENT_RETURN_URL"
+      }
+    },
+    "plans": {
+      "pro": {
+        "name": "Pro",
+        "amount": 1200,
+        "currency": "USD",
+        "interval": "month",
+        "features": ["export"],
+        "renewalCredits": 100
+      }
+    }
+  }
+}
+```
+
+Each integration reference must select a shared Stripe/Paddle API-key slot
+using an Env reference. Paddle's connector environment must equal the payment
+environment. Paddle also requires `taxCategory` and `publicClientTokenRef`
+(an Env reference to its public frontend token). Each environment has its own merchant, signing secret and price
+bindings. The same source declaration can name both environments, but callers
+cannot select live operations merely by submitting `environment: live`.
+The server owns environment selection and supplies the matching Env projection.
+
+An amount is an integer in the currency's smallest unit. ISO-looking currency
+syntax is not evidence the provider accepts that currency. Initial plans are
+one recurring item, quantity one, monthly or yearly. Logical plan IDs are source
+identities; external product and price IDs are environment/account-bound runtime
+mappings. Publishing those mappings must preserve historical prices referenced
+by existing subscriptions. Never infer a mapping from display names or assign
+a browser-supplied provider price to a plan.
+
+## Access and credits
+
+A subscription grants its plan's named features only while its current fetched
+status is `active` and its period end is in the future. Trials, past-due, unpaid,
+paused, incomplete, expired and canceled subscriptions grant no features in v1.
+Cancel-at-period-end remains active until the provider ends the subscription.
+The app may deliberately add its own trial/free-feature policy outside this
+paid entitlement check; it must not silently reinterpret these states.
+
+An initial paid subscription period or ordinary paid renewal grants the plan's
+`renewalCredits` once, keyed by the provider invoice/transaction, not delivery
+ID. Zero means no grant. Proration/update events do not grant a fresh allowance.
+Renewal credits expire at the paid period end and never roll over. Late delivery
+may record already-expired credits; it must not give a new period accidentally.
+Cancellation removes feature access but does not revoke an existing credit lot
+before its recorded expiry. Monetary refunds/chargebacks do not yet implement
+automatic credit clawback: that remains explicit application reconciliation.
+
+A trusted app can grant top-up or promotional usage units with `grantCredits`:
+positive integer `units`, stable business `reference`, and either an explicit
+millisecond expiry or `null` for no expiry. This call does not collect money or
+prove payment. Only call it after the app's own verified funding/business event.
+
+Debits consume the soonest-expiring valid lot first and cannot create a negative
+balance. A stable reference denotes one business action. Reusing it with a
+different quantity fails. Full debit refunds happen once per debit, return
+units only to still-valid lots, and report the amount already expired. Partial
+refunds, monetary balances and transferable credits are outside v1 semantics.
+
+Provider event receipts, subscription changes and allowance grants commit in
+one transaction. Customer binding is unique within application, integration,
+merchant and environment. Different delivery IDs for the same paid invoice
+cannot produce another grant. Reconciliation loads current provider state;
+provider event timestamps alone are insufficient ordering evidence.
+
+## Framework implementation contract
+
+Laravel uses its own authentication, policies, ORM/migrations, transaction and
+row-locking APIs, provider PHP SDKs, routes and browser components. No PHP belongs
+in this JavaScript package and no Node sidecar is required. A framework adapter
+must preserve these observable behaviors:
+
+| Operation | Required authority and outcome |
+|---|---|
+| Inspect account | Authenticated access to the billable subject; balance, features, subscriptions; no remote mutation |
+| Billing history | Explicit billing-read policy for the subject; app-resolved customer, one filtered provider page, bounded display fields; no grant or mutation |
+| Checkout | Billing-management policy, configured logical plan, trusted contact email and stable request ID; provider URL |
+| Portal | Billing-management policy, server-bound customer; provider URL |
+| Verify webhook | Raw bytes and signing secret for the exact environment; no reliance on a browser session |
+| Reconcile event | Verified event, server customer binding, fresh provider facts and atomic receipt/state/grant |
+| Debit/refund | Authorized app business action, stable reference and atomic balance change |
+| Resolve uncertain operation | Explicit administrator policy and provider evidence; never blind retry |
+
+Persistence must serialize mutations to the same scoped account and uniquely
+index business receipts. A missing/failed transaction cannot fall back to
+unlocked writes. Store customer mappings and catalogue bindings in the app's
+database, not editor state. Retain an operation intent across crashes before
+performing remote creation; refuse duplicates until reconciliation resolves it.
+
+When integrating Laravel, give its assistant this document, the JSON schema and
+[portable conformance fixtures](conformance.md),
+the application's chosen database and billable identity, and its configured
+provider. Ask it to use the installed framework/provider APIs to implement this
+contract and test the fixture scenarios in the package tests. Those scenarios
+are evidence requirements, not permission to import JavaScript into PHP or a
+claim that a Laravel implementation already exists. The static fixtures require
+no JavaScript execution. The application's editor-command implementation must
+add the invoking host's operation contract separately; this package does not
+parse Stack files or implement editor authorization.
+
+Configuration failures use `payment_configuration_invalid` (422). Field errors
+identify `extensions.payments/...` paths, including cross-reference failures at
+`environments/<environment>/integrationId` and missing Paddle token/tax-category
+fields. Messages explain the repair without echoing credential values.

package/docs/standalone.md

@@ -0,0 +1,259 @@
+# Set up payments without an editor
+
+A hand-written JSKIT application uses exactly the same payment declaration as an
+application configured through an editor. The application reads the file; the
+library receives the parsed configuration. There is no editor discovery, remote
+configuration lookup, or dependency on an editor session.
+
+Install `@jskit-ai/payments-core` and `@jskit-ai/connectors-core` alongside the
+application's existing Knex integration and selected database driver. These
+packages are currently worktree implementations: registry installation must wait
+for the coordinated release. Run the payment package migrations through the
+application's normal migration discovery before starting billing routes.
+
+## Prepare provider access
+
+Create an application-owned merchant account and key using the
+[Stripe setup guide](../../connectors-catalog/docs/stripe.md) or
+[Paddle setup guide](../../connectors-catalog/docs/paddle.md). The basic connector
+check reads only balances or products; it does not verify billing permissions.
+
+For the current Stripe payment adapter, the key must allow account and balance
+reads, invoice and subscription reads, customer/product/price writes, and Checkout
+and customer portal session creation. These correspond to the SDK calls in
+`src/server/stripe.js`; grant only the resource permissions used by the app.
+Stripe's [restricted-key guide](https://docs.stripe.com/keys/restricted-api-keys)
+explains how to create/edit a key and inspect failed request logs. Connected-account
+permissions are unnecessary for this app-owned merchant flow. Configure the
+customer portal in Stripe's Billing settings separately.
+
+For Paddle, enable `product.read`, `product.write`, `price.read`, `price.write`,
+`customer.write`, `transaction.read`, `transaction.write`, `subscription.read`
+and `customer_portal_session.write` for the current complete billing composition.
+See the [permission reference](https://developer.paddle.com/api-reference/about/permissions/).
+Notification destination editing additionally requires `notification_setting.write`;
+domain approval lookup requires `checkout_domain.read`. Those connector operations
+are separate from receiving and verifying webhooks.
+
+For each environment, create a webhook destination pointing at the app's own
+receiver and save its signing secret in the configured Env reference. Use the
+[event selection instructions](../README.md#webhook-event-selection). A provider
+API key is not a webhook signing secret. Keep sandbox and live credentials,
+destinations and catalogue mappings separate. No live permission check or merchant
+approval is inferred from the package's controlled tests.
+
+## Declare the application's plans
+
+Add this payment extension to the application's integration document. `billing`
+refers to a shared Stripe integration whose API key is an Env reference. The
+merchant account ID below is illustrative; replace it with the actual account.
+Keep the complete integration document valid under the connector schema too.
+
+```json
+{
+  "version": 1,
+  "environments": {
+    "sandbox": {
+      "integrationId": "billing",
+      "providerAccountId": "acct_replace_me",
+      "webhookSecretRef": "env:STRIPE_WEBHOOK_SECRET",
+      "returnUrlRef": "env:BILLING_RETURN_URL"
+    }
+  },
+  "plans": {
+    "pro": {
+      "name": "Pro",
+      "amount": 1200,
+      "currency": "USD",
+      "interval": "month",
+      "features": ["export"],
+      "renewalCredits": 100
+    }
+  }
+}
+```
+
+Save that object at `extensions.payments` in `integrations.json`. Keep the
+provider API key in the environment named by
+`integrations.billing.authentication.secretRef`. Set the signing secret and
+return URL through the application's normal environment mechanism. Missing
+values, including the placeholder `MISSING`, must fail setup visibly.
+
+## Compose the server libraries
+
+This is application startup code. `knex`, `authorizeBilling`, `applicationId`,
+`environment` and `configurationUrl` are supplied by the application's existing
+server composition. Select them on the server. `applicationId` is a durable
+application identity, not its current domain. The environment is explicitly
+`sandbox` or `live`; do not silently fall back between them.
+
+```js
+import { readFile } from 'node:fs/promises';
+import { createEnvironmentReferenceResolver } from '@jskit-ai/connectors-core/server';
+import { validatePaymentConfiguration } from '@jskit-ai/payments-core/shared';
+import { createKnexPaymentStore } from '@jskit-ai/payments-core/server/storage';
+import { createPaymentService } from '@jskit-ai/payments-core/server';
+import { createStripePaymentAdapter } from '@jskit-ai/payments-core/server/stripe';
+import { createPaymentCheckoutService } from '@jskit-ai/payments-core/server/checkout';
+import { createPaymentCatalogue } from '@jskit-ai/payments-core/server/catalogue';
+
+const document = JSON.parse(await readFile(configurationUrl, 'utf8'));
+// Also run the application's complete connector validation with its provider list.
+const configuration = validatePaymentConfiguration(document);
+if (!Object.hasOwn(configuration.environments, environment)) {
+  throw new Error('Configure the selected payment environment first.');
+}
+const binding = configuration.environments[environment];
+const integration = document.integrations[binding.integrationId];
+if (integration.provider !== 'stripe') throw new Error('This composition selects Stripe.');
+const resolve = createEnvironmentReferenceResolver(process.env);
+const apiKey = await resolve(integration.authentication.secretRef);
+const webhookSecret = await resolve(binding.webhookSecretRef);
+const returnUrl = await resolve(binding.returnUrlRef);
+const merchantScope = {
+  applicationId, integrationId: binding.integrationId,
+  providerAccountId: binding.providerAccountId, environment
+};
+const store = createKnexPaymentStore({ knex });
+const payments = createPaymentService({ store, configuration });
+const published = await store.inspectCatalogue(merchantScope);
+const priceBindings = Object.fromEntries(Object.entries(published.plans)
+  .filter(([planId, plan]) => Object.hasOwn(configuration.plans, planId) && plan.priceId)
+  .map(([planId, plan]) => [planId, plan.priceId]));
+const historicalPriceBindings = Object.fromEntries(published.history
+  .map((plan) => [plan.priceId, plan.planId]));
+const adapter = createStripePaymentAdapter({
+  apiKey, webhookSecret, environment, providerAccountId: binding.providerAccountId,
+  priceBindings, historicalPriceBindings
+});
+const catalogue = createPaymentCatalogue({ store, adapter, scope: merchantScope, configuration });
+const checkout = createPaymentCheckoutService({
+  adapter, store, payments, merchantScope, returnUrl, authorize: authorizeBilling
+});
+```
+
+The returned objects stay inside the backend. Never serialize the environment,
+adapter or secret-bearing startup variables to the client. `authorizeBilling`
+must return exactly `true` only for an actor allowed to manage the requested
+billable subject and action. A subject can be a workspace or user; the app owns
+that decision and obtains its ID from authenticated membership, not request
+claims alone.
+
+An authorized administrator first calls `catalogue.preview()`, reviews its
+changes and calls `catalogue.publish({reviewId})`. An ordinary application CLI
+can do this. Configuration reads never publish anything. After successful
+publication, rebuild this composition from the current bindings (or restart the
+app) before accepting checkout requests. An empty catalogue cannot sell a plan.
+
+Map authenticated checkout and portal routes to the corresponding `checkout`
+methods. Map the webhook route to `checkout.webhook({rawBody, signature})`,
+preserving the unmodified request Buffer. Enforce features using
+`payments.requireFeature({...merchantScope, subjectId}, 'export')`; debit credits
+using a stable business-operation reference. A successful checkout redirect is
+not proof of payment: verified provider reconciliation updates access and credits.
+
+## Paddle composition
+
+Use `createPaddlePaymentAdapter` from `@jskit-ai/payments-core/server/paddle`
+with the same store, services and mappings, plus the binding's explicit
+`taxCategory`. The selected Paddle integration's environment must match the
+payment environment. Resolve `publicClientTokenRef` separately and supply only
+that public client token to the app's Paddle.js checkout page. Never supply its
+API key or signing secret to the browser. The return URL must be the approved
+application checkout page described in the package README. Merchant approval
+and checkout-domain approval remain provider setup steps.
+
+## Changes and portability
+
+Editing the JSON file manually changes the same configuration the editor would
+change. Restart/reload the application composition deliberately after validation;
+the library does not watch files. Price changes need a reviewed catalogue publish.
+Keep old plans available until existing subscribers have an explicit migration
+policy; removing a plan does not cancel subscriptions or invent replacement access.
+
+Move the source, environment bindings and application database together when
+changing hosts. Back up customer mappings, publication mappings and credit
+entries with the rest of the database. Domain changes require the app's return
+URL and provider webhook/checkout settings to be updated; they do not change
+its application identity or move ownership to an editor.
+
+This guide describes explicit composition, not a completed automatic installer.
+HTTP framework wiring and native PostgreSQL/MySQL deployment verification remain
+application responsibilities; focused package tests use controlled fixtures.
+
+## Customer-facing billing page
+
+The optional `@jskit-ai/payments-web` package owns the reusable Vue/Vuetify
+`PaymentAccount` view. Its README specifies the props, emitted actions and
+existing JSKIT HTTP-hook composition. Node-only consumers do not install Vue.
+`checkout.account({actor, subjectId})` authorizes action `account`, then returns
+balance, features, subscriptions and a `hasCustomer` flag without provider customer
+IDs or credentials. The application adds safe display plans and permission hints.
+Checkout and portal calls still authorize their own actions independently.
+
+## Provider billing history from an app or CLI
+
+The same checkout service exposes `history({actor, subjectId, collection, after})`.
+Authorize action `history` using the application's billing-read policy. An editor
+owner is not automatically authorized to read a tenant's records. The service
+resolves the provider customer from the scoped application database; callers
+cannot select a provider customer, merchant or environment.
+
+```js
+// actor and subjectId come from the app's authenticated route or CLI policy.
+const page = await checkout.history({
+  actor, subjectId, collection: 'transactions', after: null
+});
+// Display this page; load another only on an explicit request, using nextCursor.
+```
+
+Collections are `subscriptions` and `transactions`. Each call fetches at most 20
+records and returns `{collection, items, nextCursor}`. A missing customer returns
+an empty page without creating one. Items expose only provider ID, kind, status,
+and ISO creation time. Financial records also expose currency, `totalMinor` and
+`paidMinor` as integer strings or `null` when unknown; preserve these strings
+when using native decimal/money facilities. Do not convert large amounts to a
+JavaScript Number.
+
+Stripe financial history contains **invoices**, not every charge, refund or
+payment attempt. Paddle contains **transactions**; its total is not a paid
+amount, so `paidMinor` stays null. Draft Paddle totals may also be null. Preserve
+the `kind` and status in the UI rather than labelling every row a successful
+payment. Subscription history includes canceled subscriptions and is a provider
+view, not the source of application entitlements. A read never grants credits.
+
+Laravel can use its native policies and stored customer relation to call
+[Stripe subscription lists](https://docs.stripe.com/api/subscriptions/list) and
+[invoice lists](https://docs.stripe.com/api/invoices/list), or
+[Paddle subscription lists](https://developer.paddle.com/api-reference/subscriptions/list-subscriptions/)
+and [transaction lists](https://developer.paddle.com/api-reference/transactions/list-transactions/).
+Apply the customer filter on every page, retain provider status, and project only
+these display fields. Do not pass arbitrary pagination URLs or SDK objects to
+the client. JSKIT's provider adapters are trusted server primitives; UI/CLI
+entry points use the authorized service above.
+
+This is an app/CLI library capability. The editor history command and history
+screens remain separate integration work; this method does not add them by itself.
+
+## Read-only readiness inspection
+
+Compose `createPaymentReadiness` from
+`@jskit-ai/payments-core/server/readiness` with `{adapter, catalogue,
+scope: merchantScope}`. Its `inspect()` reports separate credential, account,
+charges, payouts, catalogue, webhook, checkout, site and deployment checks. No
+provider writes occur. Scope mismatches fail, provider exceptions are replaced
+with safe diagnostics, and unknown/manual checks remain explicit.
+
+An optional app-owned `inspectApplication` callback may supply `webhook`,
+`checkout`, `site` and `deployment` evidence as `{status, detail}` records. Use
+`passed`, `failed`, `unknown` or `manual` and a safe explanation of at most 500
+characters. Record only observed checks. Never turn an unavailable check into
+success or claim provider approval from a fixture. This callback is a normal app
+function, not a Vibe64 API. Authorize any route/CLI wrapper exposing the service.
+
+Catalogue recovery requires a fresh `catalogue.preview()` and its `reviewId`:
+`catalogue.recover({reviewId, providerId})`. The adapter reads the candidate object;
+its ID and pending operation must match, and a recovered price must be active.
+A stale review is rejected. Trusted administrator code may instead supply
+`confirmedNotCreated: true` with that review only after actual provider inspection
+establishes absence. Do not expose that assertion as an ordinary browser flag.

package/migrations/payments_core_initial.cjs

@@ -0,0 +1,26 @@
+exports.up = async function up(knex) {
+  await knex.schema.createTable("payment_catalogues", (table) => {
+    table.string("catalogue_key", 64).primary();
+    table.text("payload", "mediumtext").notNullable();
+  });
+  await knex.schema.createTable("payment_accounts", (table) => {
+    table.string("account_key", 64).primary();
+    table.text("payload", "mediumtext").notNullable();
+  });
+  await knex.schema.createTable("payment_entries", (table) => {
+    table.string("entry_key", 64).primary();
+    table.string("account_key", 64).notNullable().references("account_key").inTable("payment_accounts");
+    table.text("payload", "mediumtext").notNullable();
+  });
+  await knex.schema.createTable("payment_customers", (table) => {
+    table.string("customer_key", 64).primary();
+    table.string("subject_id", 200).notNullable();
+  });
+};
+
+exports.down = async function down(knex) {
+  await knex.schema.dropTable("payment_customers");
+  await knex.schema.dropTable("payment_entries");
+  await knex.schema.dropTable("payment_accounts");
+  await knex.schema.dropTable("payment_catalogues");
+};

package/package.json

@@ -0,0 +1,68 @@
+{
+  "name": "@jskit-ai/payments-core",
+  "version": "0.1.1",
+  "type": "module",
+  "description": "Application-owned payment configuration, subscription access and transactional usage credits.",
+  "exports": {
+    "./shared": "./src/shared/configuration.js",
+    "./configuration.schema.json": "./contracts/configuration.schema.json",
+    "./conformance.json": "./contracts/conformance.json",
+    "./docs/contract.md": "./docs/contract.md",
+    "./docs/conformance.md": "./docs/conformance.md",
+    "./server": "./src/server/service.js",
+    "./server/storage": "./src/server/knexStore.js",
+    "./server/checkout": "./src/server/checkout.js",
+    "./server/stripe": "./src/server/stripe.js",
+    "./server/paddle": "./src/server/paddle.js",
+    "./server/catalogue": "./src/server/catalogue.js",
+    "./server/readiness": "./src/server/readiness.js"
+  },
+  "scripts": {
+    "test": "node --test --test-concurrency=1"
+  },
+  "dependencies": {
+    "@paddle/paddle-node-sdk": "3.10.0",
+    "ajv": "8.20.0",
+    "stripe": "22.6.2"
+  },
+  "jskit": {
+    "kind": "runtime",
+    "migrations": {
+      "directories": [
+        "migrations"
+      ]
+    },
+    "metadata": {
+      "jskit": {
+        "tableOwnership": {
+          "tables": [
+            {
+              "tableName": "payment_accounts"
+            },
+            {
+              "tableName": "payment_entries"
+            },
+            {
+              "tableName": "payment_customers"
+            },
+            {
+              "tableName": "payment_catalogues"
+            }
+          ]
+        }
+      }
+    },
+    "capabilities": {
+      "provides": [],
+      "requires": []
+    },
+    "runtime": {
+      "server": {
+        "providers": []
+      },
+      "client": {
+        "providers": []
+      }
+    }
+  }
+}