@primer-io/primer-js 1.4.2 → 1.5.0

package/CHANGELOG.md

@@ -1,5 +1,42 @@
 # Changelog
 
+## 1.5.0
+
+### Minor Changes
+
+- 47378b6: feat: re-evaluate payment methods after `refreshClientSession`
+
+  After `primer.refreshSession()`, payment methods filtered out by Checkout
+  Builder visibility rules now disappear from the rendered list instead of
+  staying visible. `refreshClientSession` diffs the new configuration against
+  the in-memory payment methods, reconciles the shared list in place, and fires
+  a new `onAvailablePaymentMethodsRefresh` callback. `refreshSession()` is a
+  no-op (with a `[PRIMER]` warning) while a payment is in progress so methods
+  can't be yanked out from under the user mid-flow.
+
+### Patch Changes
+
+- 8971d41: fix: stop firing false `primer:payment-failure` events for settled payments
+
+  Three contract fixes for the false-failure class behind the Easol duplicate
+  charges (ESC-980). Resume (`POST /payments/{id}/resume`) can answer HTTP 202
+  `NoActionsToHandle` while the processor authorisation is still in flight; the
+  SDK misread that as an inconsistent state and fired a payment-failure ~2s
+  before the AUTHORIZED webhook landed. `resumePaymentUntilSettled` now re-polls
+  the unconsumed resume token (2s interval, 30s window) until the payment
+  settles, and on window exhaustion fails honestly with the payment id instead
+  of claiming failure. `processPayment` no longer drops the created payment's
+  `id` when the resume response is leaner, and failure events now surface the
+  request `X-Request-Id` as `diagnosticsId` (including for errors deserialized
+  across the hosted-pages `postMessage` boundary) so failures are reconcilable
+  with backend logs.
+
+## 1.4.3
+
+### Patch Changes
+
+- 931337d: fix(primer-js): block concurrent card form submissions
+
 ## 1.4.2
 
 ### Patch Changes

package/README.md

@@ -101,6 +101,33 @@ checkout.addEventListener('primer:state-change', (event) => {
 });
 ```
 
+### `primer:payment-approval-required` (MANUAL approval flow)
+
+Emitted in the MANUAL approval flow when the payment is awaiting the merchant's
+explicit approval. Send `clientSessionId` and `paymentAttemptId` to your
+backend (which calls `/approve` or `/abort`), then call `continueFlow()` to let
+the SDK fetch the session and resolve the result.
+
+```javascript
+checkout.addEventListener('primer:payment-approval-required', async (event) => {
+  const {
+    clientSessionId,
+    paymentAttemptId,
+    paymentMethodToken,
+    continueFlow,
+  } = event.detail;
+
+  const response = await fetch('/my-backend/handle-payment-approval', {
+    method: 'POST',
+    body: JSON.stringify({ clientSessionId, paymentAttemptId }),
+  });
+
+  if (response.ok) {
+    await continueFlow();
+  }
+});
+```
+
 ## Support
 
 - **Documentation**: [Web Components Documentation](https://primer.io/docs/sdk/primer-checkout-web/sdk-reference-overview)