@delopay/sdk 0.100.0 → 0.101.0

package/dist/{chunk-HK4S2SQB.js → chunk-NLUEZQZF.js}

@@ -105,8 +105,7 @@ var ApiKeys = class {
   // JWT-authenticated routes under `/account/{merchantId}/profile/api-keys`.
   // The caller's shop (business profile) comes from the JWT, never from the
   // request, so a shop-scoped user can only mint/list/manage keys pinned to
-  // their own shop. Requires a backend with profile-scoped API key support
-  // (DeloPay-net/delopay-backend#344).
+  // their own shop. Requires a backend with profile-scoped API key support.
   /**
    * Create a new API key pinned to the caller's shop (business profile).
    * `POST /account/{merchantId}/profile/api-keys`
@@ -3704,6 +3703,53 @@ var Subscriptions = class {
   async lookupPayments(params, options) {
     return this.request("POST", "/subscriptions/payments/lookup", { body: params, ...options });
   }
+  /**
+   * One subscription's billing history, newest cycle first.
+   * `GET /subscriptions/{subscriptionId}/invoices`
+   *
+   * {@link retrieve} carries only the *latest* invoice, which is the current
+   * cycle — a subscription that has renewed monthly for a year has one of those
+   * and twelve of these. Use this wherever a merchant needs to see what a
+   * subscription has actually billed, in particular on self-charging processors
+   * (Creem, PayPal) where each renewal is charged by the processor and mirrored
+   * here rather than raised as a DeloPay payment.
+   *
+   * Two things to render honestly, both decided rather than incidental:
+   *
+   * - `amount` is **gross** and `refunded_amount` sits beside it. Do not net
+   *   them: the difference between the two is not a smaller charge.
+   * - A `refunded_amount` of `null` is "not reported" and must not render as
+   *   `0`. Likewise a processor-hosted origination records a bootstrap invoice
+   *   at `0` before the buyer has paid anything, so a zero amount on such a
+   *   subscription is a placeholder rather than a free cycle.
+   *
+   * Profile-scoped like every other subscription route.
+   */
+  async listInvoices(subscriptionId, params, options) {
+    return this.request("GET", `/subscriptions/${encodeURIComponent(subscriptionId)}/invoices`, {
+      query: params,
+      ...options
+    });
+  }
+  /**
+   * Which billing processor this shop's subscriptions run on.
+   * `GET /subscriptions/billing_processor`
+   *
+   * The same mapping is derivable from the connector inventory
+   * (`GET /account/{merchant_id}/connectors`), but that route is gated by a
+   * connector-read permission granted independently of subscriptions — so a
+   * role authorised to create subscriptions could be unable to learn which
+   * processor it was creating them on. This answers under the same
+   * authorization as the rest of the subscription API.
+   *
+   * Reach for it when the client must branch on the processor *before* calling
+   * — origination differs by processor, and guessing is destructive. Resolve
+   * the shop's `billing_processor_id` first: a shop that runs no subscriptions
+   * has none assigned, and this route has no identity to report for it.
+   */
+  async getBillingProcessor(options) {
+    return this.request("GET", "/subscriptions/billing_processor", { ...options });
+  }
 };
 
 // src/resources/settlement.ts
@@ -5611,7 +5657,7 @@ var CheckoutSession = class {
    * own types and runtime gates — hence the loose return type.
    *
    * `theme` is the route's one declared query parameter (a named checkout
-   * variant, backend#793). `locale` travels as `Accept-Language` — the only
+   * variant). `locale` travels as `Accept-Language` — the only
    * channel the backend's locale resolution reads; a `?locale=` query is
    * silently ignored by this route.
    *
@@ -5766,10 +5812,17 @@ var CheckoutSession = class {
   /**
    * A short-lived VGS Collect session for browser-side card capture.
    *
-   * A 404 — or a 400 carrying the "shop has no vault" code — means the shop
-   * has no vault configured; other errors must NOT be treated that way (a
-   * refused vault falling back to an unprotected card pane is exactly the
-   * bug this endpoint's error contract exists to prevent).
+   * **Exactly one refusal means "this shop has no vault": a 400 carrying
+   * `IR_19`.** Every other refusal means a vault exists and could not be used,
+   * and answering it by falling back to the processor's own card pane sends an
+   * unprotected card number to the very processor the shop pays to hide it
+   * from — the bug this endpoint's error contract exists to prevent.
+   *
+   * A **404 is not benign.** The router answers it when the shop's vault
+   * account cannot be found — the state a shop is left in when its vault
+   * connector is deleted while the profile keeps naming the id: it still
+   * reports the vault as enabled and still expects its cards cloaked. The same
+   * status also covers a payment that does not exist.
    *
    * `GET /payment-link/{merchantId}/{paymentId}/vault/collect-session`
    */
@@ -6168,4 +6221,4 @@ export {
   focusedCheckoutUrl,
   CHECKOUT_EVENT_KINDS
 };
-//# sourceMappingURL=chunk-HK4S2SQB.js.map
+//# sourceMappingURL=chunk-NLUEZQZF.js.map