@delopay/sdk 0.127.0 → 0.129.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.cjs CHANGED
@@ -3373,6 +3373,19 @@ var Users = class {
3373
3373
  async acceptInvitation(params) {
3374
3374
  return this.request("POST", "/user/employees/invite/accept", { body: params });
3375
3375
  }
3376
+ /**
3377
+ * Accept invitations before a session exists.
3378
+ *
3379
+ * Sign-in issues a `token_type: "accept_invite"` step token instead of a
3380
+ * session when the caller has no active role yet — every role is still an
3381
+ * unaccepted invitation. With that token set via `setJwtToken`, pass the
3382
+ * entities from `listInvitations` here; the response is the next step of
3383
+ * the sign-in flow (`user_info` for the session, or `force_set_password`
3384
+ * first). Rejected when none of the entities carries a pending invitation.
3385
+ */
3386
+ async acceptInvitationsPreAuth(params) {
3387
+ return this.request("POST", "/user/employees/invite/accept/pre-auth", { body: params });
3388
+ }
3376
3389
  /**
3377
3390
  * Accept an invitation via the email-link flow.
3378
3391
  *
@@ -3467,7 +3480,12 @@ var Users = class {
3467
3480
  async transferKey(params) {
3468
3481
  return this.request("POST", "/user/key/transfer", { body: params });
3469
3482
  }
3470
- /** List invitations. `GET /user/list/invitation` */
3483
+ /**
3484
+ * Invitations still waiting on the caller. `GET /user/list/invitation`
3485
+ *
3486
+ * Accepts an `accept_invite` step token as well as a session JWT, so it
3487
+ * can feed `acceptInvitationsPreAuth` during sign-in.
3488
+ */
3471
3489
  async listInvitations() {
3472
3490
  return this.request("GET", "/user/list/invitation");
3473
3491
  }
@@ -7189,6 +7207,30 @@ var CheckoutSession = class {
7189
7207
  headers: this.pkHeaders(options?.headers)
7190
7208
  });
7191
7209
  }
7210
+ /**
7211
+ * Mint the processor-side session a browser SDK completes — the PayPal
7212
+ * order that PayPal's buttons or Card Fields attach the buyer's choice to.
7213
+ * The client secret is attached automatically.
7214
+ *
7215
+ * For PayPal Card Fields (be#1387) pass `payment_method: 'card'` and the
7216
+ * `merchant_connector_id` the checkout was rendered with; the order id comes
7217
+ * back in `next_action.next_action_data.order_id` and is what the SDK's
7218
+ * `createOrder` returns. The confirm that captures it sends the same order
7219
+ * and account as `payment_method_data.card_reference`.
7220
+ *
7221
+ * `POST /payments/{paymentId}/post-session-tokens` (publishable key)
7222
+ */
7223
+ async postSessionTokens(params, options) {
7224
+ return this.client.request(
7225
+ "POST",
7226
+ `/payments/${encodeURIComponent(this.paymentId)}/post-session-tokens`,
7227
+ {
7228
+ body: { ...params, client_secret: this.requireClientSecret() },
7229
+ ...options,
7230
+ headers: this.pkHeaders(options?.headers)
7231
+ }
7232
+ );
7233
+ }
7192
7234
  /**
7193
7235
  * Abandon the attempt the buyer left open on a connector's hosted page
7194
7236
  * (the payment sits in `requires_customer_action`) and open a fresh attempt