@delopay/sdk 0.186.0 → 0.188.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.
package/dist/index.js CHANGED
@@ -216,7 +216,7 @@ import {
216
216
  validatePanes,
217
217
  verticalGapValue,
218
218
  visibleCustomFields
219
- } from "./chunk-FRMLBRHG.js";
219
+ } from "./chunk-7M6HDH2Q.js";
220
220
  export {
221
221
  AIRWALLEX_AUTOFILL_TREATMENTS,
222
222
  AIRWALLEX_CARD_LAYOUTS,
package/dist/internal.cjs CHANGED
@@ -4144,9 +4144,19 @@ var Users = class {
4144
4144
  * Mints a session token **as** the given member, so the dashboard renders
4145
4145
  * exactly what they see (useful for support and role verification). The
4146
4146
  * caller needs the *Impersonation* permission, and the member's role must
4147
- * rank **strictly below** the caller's (`Profile < Merchant < Organization`);
4148
- * the server rejects self-impersonation, cross-merchant targets, and
4149
- * equal/higher roles.
4147
+ * either rank **strictly below** the caller's
4148
+ * (`Profile < Merchant < Organization`), or sit at the caller's own
4149
+ * merchant-or-higher level and be **strictly narrower** than the caller's
4150
+ * role (grant nothing the caller's role does not, and less in total). The
4151
+ * server rejects self-impersonation and cross-merchant targets.
4152
+ * `MinimalRoleInfo.can_impersonate` in `listUsersInLineage` answers the same rule
4153
+ * per binding, so a UI can offer the action only where it will succeed.
4154
+ *
4155
+ * A role refusal is a `UR_33` error whose `data.reason` names the rule:
4156
+ * `impersonation_target_not_narrower` (the member's role is above, equal to,
4157
+ * or not contained in the caller's), or `act_as_token_cannot_impersonate`
4158
+ * (the caller is itself signed in as another member — start from your own
4159
+ * session).
4150
4160
  *
4151
4161
  * The returned token is tab-scoped by design: open it in a fresh tab (e.g.
4152
4162
  * `/auth/impersonate?token=…`) rather than replacing the caller's own
@@ -5322,6 +5332,20 @@ var Products = class {
5322
5332
  ...this.scoped(profileId, options)
5323
5333
  });
5324
5334
  }
5335
+ /**
5336
+ * Delete an archived product, then carry out the chosen action at each
5337
+ * connected account it is tied to. An account not named in
5338
+ * `provider_actions` is kept as it is. A failed provider action does not
5339
+ * undo the delete: it is listed by {@link providerCleanups} and retried
5340
+ * with {@link providerArchive}.
5341
+ * `POST /products/{product_id}/delete`
5342
+ */
5343
+ async deleteWithProviders(productId, request, profileId, options) {
5344
+ return this.request("POST", `/products/${encodeURIComponent(productId)}/delete`, {
5345
+ body: request,
5346
+ ...this.scoped(profileId, options)
5347
+ });
5348
+ }
5325
5349
  /**
5326
5350
  * Add a price to an existing product.
5327
5351
  * `POST /products/{product_id}/prices`
@@ -5563,9 +5587,12 @@ var Products = class {
5563
5587
  }
5564
5588
  /**
5565
5589
  * Create a product for every new item and add the new prices of every
5566
- * changed one, tied to the provider's ids. Nothing is edited or removed, and
5567
- * nothing is written to the provider. A failed item is reported with its
5568
- * reason and can be retried by naming it in `connector_product_ids`.
5590
+ * changed one, tied to the provider's ids. Nothing else is edited or
5591
+ * removed, except that `options.archived: 'archive'` archives the catalog
5592
+ * product of every item the provider no longer offers (by default it is
5593
+ * left as it is). Nothing is written to the provider. A failed item is
5594
+ * reported with its reason and can be retried by naming it in
5595
+ * `connector_product_ids`.
5569
5596
  * `POST /products/import/apply`
5570
5597
  */
5571
5598
  async importApply(request, profileId, options) {
@@ -5622,6 +5649,53 @@ var Products = class {
5622
5649
  ...this.scoped(profileId, options)
5623
5650
  });
5624
5651
  }
5652
+ // --- provider lifecycle -----------------------------------------
5653
+ /**
5654
+ * The shop's connected accounts the catalog works with, and what each can
5655
+ * do: read, create, push, and how a delete can clean up there.
5656
+ * `GET /products/provider-accounts`
5657
+ */
5658
+ async providerAccounts(profileId, options) {
5659
+ return this.request("GET", "/products/provider-accounts", {
5660
+ ...this.scoped(profileId, options)
5661
+ });
5662
+ }
5663
+ /**
5664
+ * Provider clean-ups still to be carried out: deletes whose action at a
5665
+ * provider failed, or was recorded and never reached.
5666
+ * `GET /products/provider-cleanups`
5667
+ */
5668
+ async providerCleanups(profileId, options) {
5669
+ return this.request("GET", "/products/provider-cleanups", {
5670
+ ...this.scoped(profileId, options)
5671
+ });
5672
+ }
5673
+ /**
5674
+ * Create the product at a connected account it is not at yet. Without
5675
+ * `confirmed` nothing is written and the answer holds the plan to review;
5676
+ * send the plan's `fingerprint` back as `confirmed` to carry it out. When
5677
+ * the plan changed since, nothing is written and the answer carries
5678
+ * `confirmation_outdated: true` with the current plan.
5679
+ * `POST /products/{product_id}/provider-sync/create`
5680
+ */
5681
+ async providerCreate(productId, request, profileId, options) {
5682
+ return this.request("POST", `/products/${encodeURIComponent(productId)}/provider-sync/create`, {
5683
+ body: request,
5684
+ ...this.scoped(profileId, options)
5685
+ });
5686
+ }
5687
+ /**
5688
+ * Archive the product at one connected account, or retry a clean-up that
5689
+ * failed after the product was deleted. Existing subscriptions there keep
5690
+ * billing; the catalog is not changed.
5691
+ * `POST /products/{product_id}/provider-archive`
5692
+ */
5693
+ async providerArchive(productId, request, profileId, options) {
5694
+ return this.request("POST", `/products/${encodeURIComponent(productId)}/provider-archive`, {
5695
+ body: request,
5696
+ ...this.scoped(profileId, options)
5697
+ });
5698
+ }
5625
5699
  };
5626
5700
 
5627
5701
  // src/resources/processorCosts.ts
@@ -6517,6 +6591,23 @@ var OperationLimits = class {
6517
6591
  async retrieveSettings(options) {
6518
6592
  return this.request("GET", "/operation-limits/settings", options);
6519
6593
  }
6594
+ /**
6595
+ * The caller's own usage against the limit on one operation: the rule that
6596
+ * applies to them, what they have used in the current window and what
6597
+ * remains.
6598
+ *
6599
+ * Refund usage needs merchant-wide refund read and is refused to a role
6600
+ * restricted to some connectors: the totals span every shop and connector,
6601
+ * as the budget does. Settlement usage needs merchant settlement read.
6602
+ *
6603
+ * `GET /operation-limits/usage`
6604
+ */
6605
+ async retrieveUsage(params, options) {
6606
+ return this.request("GET", "/operation-limits/usage", {
6607
+ query: { operation: params.operation },
6608
+ ...options
6609
+ });
6610
+ }
6520
6611
  /**
6521
6612
  * Update the enforcement settings. Only provided fields change.
6522
6613
  *
@@ -6554,7 +6645,10 @@ var OperationLimits = class {
6554
6645
  *
6555
6646
  * Refused for the user who requested it, and for an approver whose own
6556
6647
  * limit would not have covered the operation — the permission is necessary
6557
- * and not sufficient.
6648
+ * and not sufficient. The requester stays refused while signed in as
6649
+ * another team member: that is a `DE_12` error (`approval_decision_refused`)
6650
+ * whose `data.reason` is `requester_acting_as_another_member`, and
6651
+ * {@link reject} refuses the same way.
6558
6652
  *
6559
6653
  * Approval and execution are two facts. A request that was approved but
6560
6654
  * whose operation then failed comes back `approved` with `execution_error`
@@ -10104,19 +10198,26 @@ var CheckoutSession = class {
10104
10198
  * is what a recorder should do: every ordinary slice compresses, and the last
10105
10199
  * one is sent the way that actually arrives.
10106
10200
  *
10201
+ * For a precompressed event array, pass `compressed_events` and `gzipBody`.
10202
+ * The latter receives the complete JSON request (including the session's
10203
+ * client secret) and must return gzip bytes synchronously. Fetch then starts
10204
+ * before this method yields, including on a page-navigation slice. A
10205
+ * keepalive request is used only when that prepared body is at most 60 KiB.
10206
+ *
10107
10207
  * `POST /payments/{paymentId}/replay/slice` (publishable key)
10108
10208
  */
10109
10209
  async storeReplaySlice(params, options) {
10110
- const { keepalive, compress, ...extras } = options ?? {};
10210
+ const { keepalive, compress, gzipBody, ...extras } = options ?? {};
10111
10211
  const body = { ...params, client_secret: this.requireClientSecret() };
10112
10212
  const headers = this.pkHeaders(extras.headers);
10113
- const gzipped = compress === true && keepalive !== true ? await gzipJson(body) : null;
10213
+ const encoded = gzipBody?.(new TextEncoder().encode(JSON.stringify(body)));
10214
+ const gzipped = encoded ? Uint8Array.from(encoded).buffer : compress === true && keepalive !== true ? await gzipJson(body) : null;
10114
10215
  return this.client.request(
10115
10216
  "POST",
10116
10217
  `/payments/${encodeURIComponent(this.paymentId)}/replay/slice`,
10117
10218
  {
10118
10219
  body: gzipped ?? body,
10119
- ...keepalive !== void 0 ? { keepalive } : {},
10220
+ ...keepalive !== void 0 ? { keepalive: encoded ? keepalive && encoded.byteLength <= 60 * 1024 : keepalive } : {},
10120
10221
  ...extras,
10121
10222
  // `Content-Type` has to be stated for the compressed body: the client
10122
10223
  // only sets it for a body it serialises itself, and the bytes are
@@ -10317,6 +10418,27 @@ var CheckoutSession = class {
10317
10418
  headers: this.bearerHeaders(options?.headers)
10318
10419
  });
10319
10420
  }
10421
+ /**
10422
+ * Make the buyer's add-on choice while the checkout data answers
10423
+ * `type: 'addon_choice'`.
10424
+ *
10425
+ * Only price ids and quantities are sent; the router prices them from the
10426
+ * catalog and judges every selection group's bounds. The payment's lines and
10427
+ * amount change together, once: the choice is final afterwards, the same
10428
+ * choice sent again answers the same result, and another is refused with
10429
+ * `IR_16` — as is a choice once anything could have been charged at the
10430
+ * previous amount. Fetch the checkout data again afterwards for the payment
10431
+ * methods at the final amount.
10432
+ *
10433
+ * `POST /payment-link/{merchantId}/{paymentId}/addons`
10434
+ */
10435
+ async chooseAddons(params, options) {
10436
+ return this.client.request("POST", `${this.linkBase}/addons`, {
10437
+ body: params,
10438
+ ...options,
10439
+ headers: this.bearerHeaders(options?.headers)
10440
+ });
10441
+ }
10320
10442
  /**
10321
10443
  * Ask whether NomuPay's COPYandPAY widget may submit a card, from the
10322
10444
  * form's pre-submit hook.