@delopay/sdk 0.100.2 → 0.101.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -3703,6 +3703,53 @@ var Subscriptions = class {
3703
3703
  async lookupPayments(params, options) {
3704
3704
  return this.request("POST", "/subscriptions/payments/lookup", { body: params, ...options });
3705
3705
  }
3706
+ /**
3707
+ * One subscription's billing history, newest cycle first.
3708
+ * `GET /subscriptions/{subscriptionId}/invoices`
3709
+ *
3710
+ * {@link retrieve} carries only the *latest* invoice, which is the current
3711
+ * cycle — a subscription that has renewed monthly for a year has one of those
3712
+ * and twelve of these. Use this wherever a merchant needs to see what a
3713
+ * subscription has actually billed, in particular on self-charging processors
3714
+ * (Creem, PayPal) where each renewal is charged by the processor and mirrored
3715
+ * here rather than raised as a DeloPay payment.
3716
+ *
3717
+ * Two things to render honestly, both decided rather than incidental:
3718
+ *
3719
+ * - `amount` is **gross** and `refunded_amount` sits beside it. Do not net
3720
+ * them: the difference between the two is not a smaller charge.
3721
+ * - A `refunded_amount` of `null` is "not reported" and must not render as
3722
+ * `0`. Likewise a processor-hosted origination records a bootstrap invoice
3723
+ * at `0` before the buyer has paid anything, so a zero amount on such a
3724
+ * subscription is a placeholder rather than a free cycle.
3725
+ *
3726
+ * Profile-scoped like every other subscription route.
3727
+ */
3728
+ async listInvoices(subscriptionId, params, options) {
3729
+ return this.request("GET", `/subscriptions/${encodeURIComponent(subscriptionId)}/invoices`, {
3730
+ query: params,
3731
+ ...options
3732
+ });
3733
+ }
3734
+ /**
3735
+ * Which billing processor this shop's subscriptions run on.
3736
+ * `GET /subscriptions/billing_processor`
3737
+ *
3738
+ * The same mapping is derivable from the connector inventory
3739
+ * (`GET /account/{merchant_id}/connectors`), but that route is gated by a
3740
+ * connector-read permission granted independently of subscriptions — so a
3741
+ * role authorised to create subscriptions could be unable to learn which
3742
+ * processor it was creating them on. This answers under the same
3743
+ * authorization as the rest of the subscription API.
3744
+ *
3745
+ * Reach for it when the client must branch on the processor *before* calling
3746
+ * — origination differs by processor, and guessing is destructive. Resolve
3747
+ * the shop's `billing_processor_id` first: a shop that runs no subscriptions
3748
+ * has none assigned, and this route has no identity to report for it.
3749
+ */
3750
+ async getBillingProcessor(options) {
3751
+ return this.request("GET", "/subscriptions/billing_processor", { ...options });
3752
+ }
3706
3753
  };
3707
3754
 
3708
3755
  // src/resources/settlement.ts
@@ -6174,4 +6221,4 @@ export {
6174
6221
  focusedCheckoutUrl,
6175
6222
  CHECKOUT_EVENT_KINDS
6176
6223
  };
6177
- //# sourceMappingURL=chunk-6ULG3SLG.js.map
6224
+ //# sourceMappingURL=chunk-NLUEZQZF.js.map