@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.
@@ -3199,6 +3199,19 @@ var Users = class {
3199
3199
  async acceptInvitation(params) {
3200
3200
  return this.request("POST", "/user/employees/invite/accept", { body: params });
3201
3201
  }
3202
+ /**
3203
+ * Accept invitations before a session exists.
3204
+ *
3205
+ * Sign-in issues a `token_type: "accept_invite"` step token instead of a
3206
+ * session when the caller has no active role yet — every role is still an
3207
+ * unaccepted invitation. With that token set via `setJwtToken`, pass the
3208
+ * entities from `listInvitations` here; the response is the next step of
3209
+ * the sign-in flow (`user_info` for the session, or `force_set_password`
3210
+ * first). Rejected when none of the entities carries a pending invitation.
3211
+ */
3212
+ async acceptInvitationsPreAuth(params) {
3213
+ return this.request("POST", "/user/employees/invite/accept/pre-auth", { body: params });
3214
+ }
3202
3215
  /**
3203
3216
  * Accept an invitation via the email-link flow.
3204
3217
  *
@@ -3293,7 +3306,12 @@ var Users = class {
3293
3306
  async transferKey(params) {
3294
3307
  return this.request("POST", "/user/key/transfer", { body: params });
3295
3308
  }
3296
- /** List invitations. `GET /user/list/invitation` */
3309
+ /**
3310
+ * Invitations still waiting on the caller. `GET /user/list/invitation`
3311
+ *
3312
+ * Accepts an `accept_invite` step token as well as a session JWT, so it
3313
+ * can feed `acceptInvitationsPreAuth` during sign-in.
3314
+ */
3297
3315
  async listInvitations() {
3298
3316
  return this.request("GET", "/user/list/invitation");
3299
3317
  }
@@ -7015,6 +7033,30 @@ var CheckoutSession = class {
7015
7033
  headers: this.pkHeaders(options?.headers)
7016
7034
  });
7017
7035
  }
7036
+ /**
7037
+ * Mint the processor-side session a browser SDK completes — the PayPal
7038
+ * order that PayPal's buttons or Card Fields attach the buyer's choice to.
7039
+ * The client secret is attached automatically.
7040
+ *
7041
+ * For PayPal Card Fields (be#1387) pass `payment_method: 'card'` and the
7042
+ * `merchant_connector_id` the checkout was rendered with; the order id comes
7043
+ * back in `next_action.next_action_data.order_id` and is what the SDK's
7044
+ * `createOrder` returns. The confirm that captures it sends the same order
7045
+ * and account as `payment_method_data.card_reference`.
7046
+ *
7047
+ * `POST /payments/{paymentId}/post-session-tokens` (publishable key)
7048
+ */
7049
+ async postSessionTokens(params, options) {
7050
+ return this.client.request(
7051
+ "POST",
7052
+ `/payments/${encodeURIComponent(this.paymentId)}/post-session-tokens`,
7053
+ {
7054
+ body: { ...params, client_secret: this.requireClientSecret() },
7055
+ ...options,
7056
+ headers: this.pkHeaders(options?.headers)
7057
+ }
7058
+ );
7059
+ }
7018
7060
  /**
7019
7061
  * Abandon the attempt the buyer left open on a connector's hosted page
7020
7062
  * (the payment sits in `requires_customer_action`) and open a fresh attempt
@@ -7583,4 +7625,4 @@ export {
7583
7625
  decodeNativePanes,
7584
7626
  encodeNativePanes
7585
7627
  };
7586
- //# sourceMappingURL=chunk-D44FJRXS.js.map
7628
+ //# sourceMappingURL=chunk-IWGBRSUJ.js.map