@delopay/sdk 0.157.0 → 0.159.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.
@@ -8270,6 +8270,65 @@ var CheckoutSession = class {
8270
8270
  headers: this.bearerHeaders(options?.headers)
8271
8271
  });
8272
8272
  }
8273
+ /**
8274
+ * Confirm the Stripe card form's PaymentIntent through the router, for a
8275
+ * checkout payload with `card_connector_server_confirm: true`. Stripe refuses
8276
+ * a Stripe.js confirm of such an intent.
8277
+ *
8278
+ * Send the PaymentMethod `stripe.createPaymentMethod` produced from the
8279
+ * Payment Element (or Express Checkout Element), which needs
8280
+ * `paymentMethodCreation: 'manual'` on the Elements instance. A
8281
+ * ConfirmationToken is refused with `400`: Stripe will not confirm such an
8282
+ * intent with one.
8283
+ *
8284
+ * The router judges the card's issuing country and the buyer's IP country
8285
+ * against the shop's sell-to restrictions before Stripe authorises, and a
8286
+ * refusal throws a `DelopayError` with code `DE_10`. When the answer's
8287
+ * `status` is `requires_action`, run `stripe.handleNextAction` with its
8288
+ * `client_secret` — safe, because the intent is `confirmation_method=manual`
8289
+ * and that secret confirms nothing without the secret key — then call this
8290
+ * again without a payment method to finalize.
8291
+ *
8292
+ * A PaymentMethod rules out what `stripe.createPaymentMethod` cannot
8293
+ * produce: Stripe names Amazon Pay and Klarna in the Express Checkout
8294
+ * Element, which need `stripe.createConfirmationToken` instead. Neither can
8295
+ * be paid through this route, so a caller must not offer them on a
8296
+ * server-confirmed intent — mount the Express Checkout Element with those
8297
+ * methods `'never'`, as DeloPay's own checkout does. The router drops only
8298
+ * the methods its server-side confirm cannot finish at all (BLIK and ACSS
8299
+ * pre-authorized debits) from the card form's mount, so the rest of the
8300
+ * selection still reaches the element and is the caller's to constrain.
8301
+ *
8302
+ * `POST /payment-link/{merchantId}/{paymentId}/stripe-confirm`
8303
+ */
8304
+ async confirmStripeCardForm(params, options) {
8305
+ return this.client.request("POST", `${this.linkBase}/stripe-confirm`, {
8306
+ body: params,
8307
+ ...options,
8308
+ headers: this.bearerHeaders(options?.headers)
8309
+ });
8310
+ }
8311
+ /**
8312
+ * Ask whether NomuPay's COPYandPAY widget may submit a card, from the
8313
+ * form's pre-submit hook.
8314
+ *
8315
+ * Only for a checkout stamped `NomupayOppwaCheckoutData.submit_grant`: the
8316
+ * card form sits beside always-shown wallet buttons of another account, and
8317
+ * this answer closes those buttons before it allows the card. `authorized`
8318
+ * is `false` when the payment no longer waits for a payment method, or when
8319
+ * this is not the attempt's live card-form checkout; when a wallet beside it
8320
+ * is already being paid, the route answers an error instead. Submit the
8321
+ * widget only on `true`.
8322
+ *
8323
+ * `POST /payment-link/{merchantId}/{paymentId}/nomupay-card-authorization`
8324
+ */
8325
+ async nomupayCardAuthorization(params, options) {
8326
+ return this.client.request("POST", `${this.linkBase}/nomupay-card-authorization`, {
8327
+ body: params,
8328
+ ...options,
8329
+ headers: this.bearerHeaders(options?.headers)
8330
+ });
8331
+ }
8273
8332
  /**
8274
8333
  * The payment's current state — status polling for redirect/popup rails.
8275
8334
  *
@@ -8978,4 +9037,4 @@ export {
8978
9037
  decodeNativePanes,
8979
9038
  encodeNativePanes
8980
9039
  };
8981
- //# sourceMappingURL=chunk-JZZZG5VD.js.map
9040
+ //# sourceMappingURL=chunk-NQJP5VBB.js.map