@delopay/sdk 0.103.0 → 0.105.0

package/dist/index.cjs

@@ -56,6 +56,7 @@ __export(index_exports, {
   NATIVE_PANE_ICON_KEYS: () => NATIVE_PANE_ICON_KEYS,
   OperationLimits: () => OperationLimits,
   Regions: () => Regions,
+  Risk: () => Risk,
   STRIPE_NATIVE_PANE_METHODS: () => STRIPE_NATIVE_PANE_METHODS,
   Search: () => Search,
   Settlement: () => Settlement,
@@ -538,12 +539,37 @@ var Connectors = class {
       body: params
     });
   }
+  /**
+   * One connector account.
+   *
+   * The credential-bearing fields come back `null` here, whatever is stored:
+   * `connector_webhook_details`, `connector_wallets_details`,
+   * `pm_auth_config` and `additional_merchant_data`. They are dropped rather
+   * than masked, because an editor that prefills from this response and
+   * PATCHes the field back would otherwise save a mask over a live signing
+   * secret. Send those fields only when the operator has typed a new value,
+   * and omit them entirely otherwise — an omitted field leaves the stored one
+   * alone.
+   *
+   * This is the retrieve path alone. `create` and `update` echo back what the
+   * caller sent, and `clone` returns the *copied* secrets — see that method.
+   *
+   * `GET /account/{accountId}/connectors/{connectorId}`
+   */
   async retrieve(accountId, connectorId) {
     return this.request(
       "GET",
       `/account/${encodeURIComponent(accountId)}/connectors/${encodeURIComponent(connectorId)}`
     );
   }
+  /**
+   * The merchant's connector accounts.
+   *
+   * Never wider than the caller: an API key pinned to one shop lists that
+   * shop's connectors only, not every sibling shop's.
+   *
+   * `GET /account/{accountId}/connectors`
+   */
   async list(accountId) {
     return this.request("GET", `/account/${encodeURIComponent(accountId)}/connectors`);
   }
@@ -589,6 +615,15 @@ var Connectors = class {
       }
     );
   }
+  /**
+   * Remove a connector account.
+   *
+   * A shop-scoped role may remove a connector of its own shop — the shop is
+   * re-checked server-side — so creating processors and removing them are the
+   * same rung of access rather than two.
+   *
+   * `DELETE /account/{accountId}/connectors/{connectorId}`
+   */
   async delete(accountId, connectorId) {
     return this.request(
       "DELETE",
@@ -600,9 +635,15 @@ var Connectors = class {
    * merchant. `POST /account/{accountId}/connectors/{connectorId}/clone`
    *
    * Credentials are copied server-side, re-encrypted under the same merchant
-   * key — the caller never handles them (list/retrieve mask credentials, so a
-   * client-side copy is impossible). Returns the newly created connector in
-   * the target shop.
+   * key, so the caller never has to *supply* them — `retrieve` returns `null`
+   * for the credential fields, which is what makes a client-side copy
+   * impossible in the first place.
+   *
+   * The response, however, is the unredacted connector: `connector_account_details`
+   * is masked, but `connector_webhook_details`, `connector_wallets_details`,
+   * `pm_auth_config` and `additional_merchant_data` come back with the copied
+   * secrets in them — values this caller never sent. Do not log or echo the
+   * response; read `merchant_connector_id` and discard the rest.
    */
   async clone(accountId, connectorId, params) {
     return this.request(
@@ -1471,6 +1512,13 @@ var Payments = class {
    *   test_mode: process.env.NODE_ENV !== 'production',
    * });
    * ```
+   *
+   * A payment that pins one connector through `routing` (the `single` form)
+   * is now checked against `test_mode` here rather than at confirm: if that
+   * connector has no credentials for the environment asked for, create fails
+   * instead of handing back a payment whose checkout the buyer cannot
+   * complete. `priority` and `volume_split` name several accounts and are
+   * still resolved at confirm.
    */
   async create(params, options) {
     return this.request("POST", "/payments", { body: params, ...options });
@@ -2111,6 +2159,14 @@ var Refunds = class {
   /**
    * Create a refund for a payment.
    *
+   * Dashboard-initiated refunds are subject to the caller's operation-limit
+   * rule, resolved against the role the request authenticated with. An
+   * over-limit refund either fails with `DE_01` (the rule blocks) or with
+   * HTTP 409 `DE_06` — the rule requires approval, and `DelopayError.data`
+   * carries `PendingApprovalErrorDetails`. No refund exists in either case;
+   * `DE_06` names one that a second approver can still let through, via
+   * `operationLimits.approve()`.
+   *
    * @param params - Refund parameters, including the required `payment_id` and optional amount.
    * @returns The created refund.
    *
@@ -2315,6 +2371,55 @@ var Routing = class {
   async update(algorithmId, params) {
     return this.request("PUT", `/routing/${encodeURIComponent(algorithmId)}`, { body: params });
   }
+  /**
+   * Every content window a routing configuration has had, oldest first.
+   *
+   * A configuration's rule can be edited in place, so this is what makes "which
+   * rule decided this payment" answerable after the fact. Each entry is the rule
+   * as it stood between `valid_from` and `valid_until`; the windows of one
+   * config abut exactly, with no gap.
+   *
+   * Paging covers the whole timeline including the live window, so a page never
+   * holds more than `limit` entries and the live one — the only entry without a
+   * `valid_until` — comes back on exactly one page. Advance `offset` by `limit`;
+   * a page past the end is empty, and `total_count` says where that end is
+   * without probing for it.
+   *
+   * `GET /routing/{algorithmId}/history`
+   *
+   * @param algorithmId - The routing algorithm to read the history of.
+   * @param params - Optional paging.
+   */
+  async history(algorithmId, params = {}) {
+    return this.request("GET", `/routing/${encodeURIComponent(algorithmId)}/history`, {
+      query: params
+    });
+  }
+  /**
+   * A shop's lifetime per-connector payment caps, each with how much of it is
+   * already spent.
+   *
+   * `GET /routing/connector-caps/{profileId}`
+   */
+  async connectorCaps(profileId) {
+    return this.request("GET", `/routing/connector-caps/${encodeURIComponent(profileId)}`);
+  }
+  /**
+   * Replace a shop's per-connector payment caps.
+   *
+   * Whole-set replacement, not a patch: the list sent becomes the complete set
+   * of capped connectors, and an empty list clears them all — which is how
+   * acquirer onboarding finishes, the new account ceasing to be a special case.
+   *
+   * Every account named must belong to this shop; one that does not is refused.
+   *
+   * `PUT /routing/connector-caps/{profileId}`
+   */
+  async setConnectorCaps(profileId, params) {
+    return this.request("PUT", `/routing/connector-caps/${encodeURIComponent(profileId)}`, {
+      body: params
+    });
+  }
   /**
    * List all routing algorithms for the current merchant.
    *
@@ -3201,7 +3306,15 @@ var Users = class {
   async selectAuth(params) {
     return this.request("POST", "/user/auth/select", { body: params });
   }
-  /** List users in lineage. `GET /user/employees/list` */
+  /**
+   * List users in lineage.
+   *
+   * Needs the Users *view* grant now — the response carries colleagues' email
+   * addresses, so a role without it is refused rather than handed a roster.
+   * A shop-scoped role keeps reading its own shop's members.
+   *
+   * `GET /user/employees/list`
+   */
   async listUsersInLineage(params) {
     return this.request("GET", "/user/employees/list", {
       query: params
@@ -3481,6 +3594,44 @@ var Analytics = class {
       query: params
     });
   }
+  /**
+   * Subscription analytics over `subscription` and `invoice`: estimated
+   * recurring volume, the invoice funnel, movement (new / expansion /
+   * contraction / churn), both processor axes, plan mix and the breakdown one
+   * level below the scope. Pinned server-side to your own merchant and
+   * drillable via `project_id` / `shop_id` exactly like `scope`.
+   *
+   * Half the figures are **stocks** — a snapshot at the window's end rather
+   * than a sum over it — so `est_monthly_volume_usd` and `active` can match
+   * across a 7-day and a 30-day window while `billed_volume_usd` does not.
+   * Day granularity only. `GET /analytics/subscriptions`
+   */
+  async subscriptions(params) {
+    return this.request("GET", "/analytics/subscriptions", {
+      query: params
+    });
+  }
+  /**
+   * The billing cycles behind one clicked element of the subscription
+   * dashboard: an invoice outcome, a processor slice on either axis, a plan
+   * row, a subscription status, a movement component, a series bucket or a
+   * breakdown row. Same window/scope/filter contract as `subscriptions`; 50
+   * rows per page (`offset` for the next), newest first, with the full match
+   * count alongside.
+   *
+   * A cycle that never reached a payment is listed too — that is what "still
+   * unpaid" means — and carries its invoice id as `payment_id` with
+   * `invoice_id` set to the same value, so you can always tell which you got.
+   * `GET /analytics/subscriptions/list`
+   */
+  async subscriptionsList(params) {
+    return this.request("GET", "/analytics/subscriptions/list", {
+      // A discriminated union carries no index signature, so the widening
+      // goes via `unknown` — the union is the point, and the query builder
+      // only ever reads own enumerable keys.
+      query: params
+    });
+  }
   /** Global search. `POST /analytics/search` */
   async search(params) {
     return this.request("POST", "/analytics/search", { body: params });
@@ -3992,6 +4143,12 @@ var Settlement = class {
   /**
    * Record payout progress on a statement (`unpaid` / `partial` / `paid`).
    *
+   * Subject to the caller's `settlement_payout` operation limit, which can
+   * only be a per-operation ceiling: an over-limit call fails with `DE_01`
+   * and nothing is recorded. There is no approval route out of it — four-eyes
+   * needs an executor that can run the operation once somebody says yes, and
+   * only refunds have one, so a settlement rule can only block.
+   *
    * `POST /settlement/statements/{statementId}/payout`
    */
   async updateStatementPayout(statementId, params, options) {
@@ -4092,6 +4249,11 @@ var Settlement = class {
    * Add a manual adjustment to a statement. Positive `amount_usd` charges
    * the shop (reducing their payout); negative credits them.
    *
+   * Subject to the caller's `settlement_adjustment` operation limit (amount
+   * dimensions only): an over-limit call fails with `DE_01` and no adjustment
+   * is added. A settlement rule can only block — approval is refund-only, for
+   * the reason given on `updateStatementPayout()`.
+   *
    * `POST /settlement/statements/{statementId}/adjustments`
    */
   async createStatementAdjustment(statementId, params, options) {
@@ -4165,6 +4327,84 @@ var OperationLimits = class {
   async updateSettings(params, options) {
     return this.request("PUT", "/operation-limits/settings", { body: params, ...options });
   }
+  /**
+   * The approvals inbox: over-limit operations waiting on a second person.
+   *
+   * Both filters default rather than widen. With no `status` the list holds
+   * **pending requests only** — approved, rejected and expired ones are
+   * reachable only by asking for that status, so a history view must pass one
+   * per status. With no `operation` it lists **refunds only**; the list is one
+   * operation at a time. `limit` defaults to 100 and is clamped to 1–500.
+   *
+   * Requests past their `expires_at` are expired before the list is read, so
+   * nothing here is shown as actionable when it is not.
+   *
+   * `GET /operation-limits/approvals`
+   */
+  async listApprovals(params, options) {
+    return this.request("GET", "/operation-limits/approvals", {
+      query: {
+        operation: params?.operation,
+        status: params?.status,
+        limit: params?.limit
+      },
+      ...options
+    });
+  }
+  /**
+   * Approve a parked operation and execute it.
+   *
+   * Refused for the user who requested it, and for an approver whose own
+   * limit would not have covered the operation — the permission is necessary
+   * and not sufficient.
+   *
+   * Approval and execution are two facts. A request that was approved but
+   * whose operation then failed comes back `approved` with `execution_error`
+   * set and no `result_entity_id`; that is a real outcome, not a partial read.
+   *
+   * `POST /operation-limits/approvals/{id}/approve`
+   */
+  async approve(id, params = {}, options) {
+    return this.request("POST", `/operation-limits/approvals/${encodeURIComponent(id)}/approve`, {
+      body: params,
+      ...options
+    });
+  }
+  /**
+   * Reject a parked operation. Nothing is executed and the request is closed.
+   *
+   * `POST /operation-limits/approvals/{id}/reject`
+   */
+  async reject(id, params = {}, options) {
+    return this.request("POST", `/operation-limits/approvals/${encodeURIComponent(id)}/reject`, {
+      body: params,
+      ...options
+    });
+  }
+};
+
+// src/resources/risk.ts
+var Risk = class {
+  constructor(request) {
+    this.request = request;
+  }
+  /**
+   * Every shop's stored risk for the caller's merchant, with the worst band
+   * across them.
+   *
+   * `GET /risk`
+   */
+  async retrieve(options) {
+    return this.request("GET", "/risk", options);
+  }
+  /**
+   * One shop's stored risk index per connector.
+   *
+   * `GET /risk/shops/{profileId}`
+   */
+  async retrieveShop(profileId, options) {
+    return this.request("GET", `/risk/shops/${encodeURIComponent(profileId)}`, options);
+  }
 };
 
 // src/client.ts
@@ -4296,6 +4536,7 @@ var Delopay = class {
     this.threeDsRules = new ThreeDsRules(request);
     this.settlement = new Settlement(request);
     this.operationLimits = new OperationLimits(request);
+    this.risk = new Risk(request);
     this.subscriptions = new Subscriptions(request);
     this.files = new Files(request);
     this.export = new Export(request);
@@ -6337,6 +6578,7 @@ var CHECKOUT_EVENT_KINDS = [
   NATIVE_PANE_ICON_KEYS,
   OperationLimits,
   Regions,
+  Risk,
   STRIPE_NATIVE_PANE_METHODS,
   Search,
   Settlement,