@code-collective/booking-widget 1.0.12 → 1.0.14

package/src/lib/PaymentPage.svelte

@@ -1,191 +1,208 @@
-<script lang="ts">
-  import { onMount, onDestroy } from 'svelte';
-  import { loadPeachSdk, loadedPeachSdkUrl } from './peach-sdk';
-  import CountdownTimer from './CountdownTimer.svelte';
-
-  interface Props {
-    checkoutId: string;
-    entityId: string;
-    onPaymentComplete: (result: { status: string }) => void;
-    // The cart's remaining life, shown in this dialog's own header so the shopper can see it over Peach's
-    // form - CheckoutModal's own cart timer is behind this overlay. Optional so callers that predate it need
-    // not pass one. CartExpiryGuard.svelte is what actually warns and acts as this counts down to zero - it
-    // renders above this overlay too, so there is nothing else for this dialog to do near the deadline.
-    expiresAt?: Date;
-  }
-  let { checkoutId, entityId, onPaymentComplete, expiresAt }: Props = $props();
-
-  let failed = $state(false);
-  let errorMessage = $state('');
-
-  let peachInstance: any = null;
-
-  onMount(() => {
-    (async () => {
-      try {
-        await loadPeachSdk();
-
-        const Checkout = (window as any).Checkout;
-        if (!Checkout) {
-          failed = true;
-          errorMessage = 'Payment SDK not loaded';
-          return;
-        }
-
-        peachInstance = Checkout.initiate({
-          checkoutId,
-          // Peach's own "key" field, not our checkoutKey/entityId naming - without it Checkout.initiate()
-          // throws (Cannot read properties of undefined (reading 'trim')) before ever rendering anything,
-          // since the embedded widget authenticates to Peach directly with this rather than through us.
-          key: entityId,
-          customisations: {
-            card: { submitButtonText: 'Pay Now' },
-            theme: { brand: { primary: '#E30613' } },
-            // Peach's own Cancel (method-selection screen) and Back (card-entry screen) are the only
-            // back/exit controls in this dialog - we don't render one of our own alongside them, so there's
-            // exactly one way out per screen instead of ours and Peach's competing for the same job.
-          },
-          eventHandlers: {
-            onCompleted: () => { cleanup(); onPaymentComplete({ status: 'completed' }); },
-            onCancelled: () => { cleanup(); onPaymentComplete({ status: 'cancelled' }); },
-            onExpired: () => { cleanup(); onPaymentComplete({ status: 'expired' }); },
-            onError: () => { reportPeachFailure('Peach reported an error rendering the card form'); cleanup(); onPaymentComplete({ status: 'error' }); },
-          },
-        });
-
-        peachInstance.render('#peach-container');
-      } catch (e) {
-        reportPeachFailure(String(e));
-        failed = true;
-        errorMessage = String(e);
-      }
-    })();
-  });
-
-  // Peach renders its own "an unrecoverable error has occurred" card inside its iframe, which tells a
-  // developer nothing about why. By far the most common cause is an SDK from one environment against a
-  // checkoutId created in another - the checkout API makes the checkout, so the two have to agree - and
-  // that is invisible unless the URL actually loaded is named.
-  function reportPeachFailure(reason: string) {
-    console.error(
-      `[booking-widget] Peach checkout did not render: ${reason}. ` +
-        `SDK loaded from ${loadedPeachSdkUrl() ?? 'an already-present window.Checkout'} for checkoutId ` +
-        `${checkoutId}. If that environment does not match the checkout API this cart came from, set ` +
-        `peachEnv on createBookingHost (or window.BW_CHECKOUT_PEACH_SDK_URL).`,
-    );
-  }
-
-  function cleanup() {
-    if (peachInstance) {
-      peachInstance.unmount();
-      peachInstance = null;
-    }
-  }
-
-  onDestroy(cleanup);
-</script>
-
-<!-- Peach's own card form renders inside a cross-origin iframe with its own Cancel/Back controls we have no
-     way to hide or reach (no SDK option, no CSS/JS access across origins) - see Checkout.initiate()'s
-     customisations doc comment above. Presenting it as its own nested dialog over the checkout modal, rather
-     than as just another view swapped into that modal's own body, means Peach's own Cancel/Back read as
-     belonging to Peach's own layer instead of visually competing with a second, separate Back of ours - so
-     this dialog has no back/exit control of its own at all; onCancelled below routes back to contact. -->
-<div class="payment-overlay">
-  <!-- svelte-ignore a11y_click_events_have_key_events a11y_no_static_element_interactions -->
-  <div class="payment-dialog" onclick={(e) => e.stopPropagation()}>
-    <div class="page-header">
-      <h2>Payment</h2>
-      {#if expiresAt}
-        <span class="spacer"></span>
-        <CountdownTimer {expiresAt} />
-      {/if}
-    </div>
-
-    <div class="body">
-      {#if failed}
-        <div class="error-state">
-          <div class="error-icon">!</div>
-          <p class="error-title">Unable to load payment form</p>
-          <p class="error-msg">{errorMessage || 'The checkout session may have expired.'}</p>
-          <!-- Peach's own Cancel/Back never rendered, so this dialog needs one exit of its own here. Reported
-               as an error rather than a cancel: nothing was charged, and CheckoutModal's error path abandons
-               the attempt so a retry mints a fresh Peach checkout instead of reopening this one - which is the
-               only sensible outcome for a checkout that would not even render (e.g. one resumed after a reload
-               that Peach has since expired). -->
-          <button class="btn btn-primary" onclick={() => onPaymentComplete({ status: 'error' })}>Start over</button>
-        </div>
-      {:else}
-        <div id="peach-container"></div>
-      {/if}
-    </div>
-  </div>
-</div>
-
-<style>
-  .payment-overlay {
-    position: fixed;
-    inset: 0;
-    /* Above bw-checkout's own .bw-modal-overlay (z-index 10000) so this reads as a second dialog opening
-       on top of the checkout modal, not content living inside it. */
-    z-index: 10001;
-    background: rgba(0, 0, 0, 0.5);
-    display: flex;
-    align-items: center;
-    justify-content: center;
-    padding: 16px;
-  }
-  .payment-dialog {
-    display: flex;
-    flex-direction: column;
-    width: 100%;
-    max-width: 480px;
-    height: min(700px, 90vh);
-    background: var(--bw-color-bg);
-    border-radius: var(--bw-radius-lg);
-    box-shadow: var(--bw-shadow-3);
-    overflow: hidden;
-  }
-  .body {
-    flex: 1;
-    /* A definite height (not just flex:1 alone) so #peach-container's own height:100% below has something
-       real to resolve against, and so this scrolls as a single region if content overflows - Peach's own
-       root is `height: inherit`, so without that it collapses to its 360px fallback regardless of how tall
-       the card form actually gets (e.g. once billing address fields are showing), and its submit button
-       ends up overlapping the fields above it. */
-    min-height: 0;
-    overflow-y: auto;
-    padding: 16px;
-  }
-  #peach-container {
-    height: 100%;
-  }
-  .error-state {
-    text-align: center;
-    padding: 32px 16px;
-  }
-  .error-icon {
-    width: 48px;
-    height: 48px;
-    border-radius: 50%;
-    border: 2px solid var(--bw-color-border);
-    display: flex;
-    align-items: center;
-    justify-content: center;
-    font-size: 24px;
-    color: var(--bw-color-text-secondary);
-    margin: 0 auto 16px;
-  }
-  .error-title {
-    font-size: 16px;
-    font-weight: 600;
-    margin-bottom: 8px;
-  }
-  .error-msg {
-    font-size: 14px;
-    color: var(--bw-color-text-secondary);
-  }
-  .error-state .btn {
-    margin-top: 16px;
-  }
-</style>
+<script lang="ts">
+  import { onMount, onDestroy } from 'svelte';
+  import { loadPeachSdk, loadedPeachSdkUrl } from './peach-sdk';
+  import CountdownTimer from './CountdownTimer.svelte';
+  import type { PaymentSdkResult } from './client-types';
+
+  interface Props {
+    checkoutId: string;
+    entityId: string;
+    onPaymentComplete: (result: PaymentSdkResult) => void;
+    // The cart's remaining life, shown in this dialog's own header so the shopper can see it over Peach's
+    // form - CheckoutModal's own cart timer is behind this overlay. Optional so callers that predate it need
+    // not pass one. CartExpiryGuard.svelte is what actually warns and acts as this counts down to zero - it
+    // renders above this overlay too, so there is nothing else for this dialog to do near the deadline.
+    expiresAt?: Date;
+  }
+  let { checkoutId, entityId, onPaymentComplete, expiresAt }: Props = $props();
+
+  // Peach does not document a stable shape for what its eventHandlers receive, and it differs between the
+  // callbacks. Anything we cannot find is simply omitted - the failure is still worth reporting without a
+  // code, and guessing one would be worse than sending none.
+  function resultOf(status: PaymentSdkResult['status'], payload: any): PaymentSdkResult {
+    const result = payload?.result ?? payload;
+    return {
+      status,
+      resultCode: result?.code ?? result?.resultCode ?? payload?.errorCode ?? undefined,
+      description: result?.description ?? payload?.message ?? undefined,
+    };
+  }
+
+  let failed = $state(false);
+  let errorMessage = $state('');
+
+  let peachInstance: any = null;
+
+  onMount(() => {
+    (async () => {
+      try {
+        await loadPeachSdk();
+
+        const Checkout = (window as any).Checkout;
+        if (!Checkout) {
+          failed = true;
+          errorMessage = 'Payment SDK not loaded';
+          return;
+        }
+
+        peachInstance = Checkout.initiate({
+          checkoutId,
+          // Peach's own "key" field, not our checkoutKey/entityId naming - without it Checkout.initiate()
+          // throws (Cannot read properties of undefined (reading 'trim')) before ever rendering anything,
+          // since the embedded widget authenticates to Peach directly with this rather than through us.
+          key: entityId,
+          customisations: {
+            card: { submitButtonText: 'Pay Now' },
+            theme: { brand: { primary: '#E30613' } },
+            // Peach's own Cancel (method-selection screen) and Back (card-entry screen) are the only
+            // back/exit controls in this dialog - we don't render one of our own alongside them, so there's
+            // exactly one way out per screen instead of ours and Peach's competing for the same job.
+          },
+          eventHandlers: {
+            onCompleted: (e: any) => { cleanup(); onPaymentComplete(resultOf('completed', e)); },
+            onCancelled: (e: any) => { cleanup(); onPaymentComplete(resultOf('cancelled', e)); },
+            onExpired: (e: any) => { cleanup(); onPaymentComplete(resultOf('expired', e)); },
+            onError: (e: any) => {
+              reportPeachFailure('Peach reported an error rendering the card form');
+              cleanup();
+              onPaymentComplete(resultOf('error', e));
+            },
+          },
+        });
+
+        peachInstance.render('#peach-container');
+      } catch (e) {
+        reportPeachFailure(String(e));
+        failed = true;
+        errorMessage = String(e);
+      }
+    })();
+  });
+
+  // Peach renders its own "an unrecoverable error has occurred" card inside its iframe, which tells a
+  // developer nothing about why. By far the most common cause is an SDK from one environment against a
+  // checkoutId created in another - the checkout API makes the checkout, so the two have to agree - and
+  // that is invisible unless the URL actually loaded is named.
+  function reportPeachFailure(reason: string) {
+    console.error(
+      `[booking-widget] Peach checkout did not render: ${reason}. ` +
+        `SDK loaded from ${loadedPeachSdkUrl() ?? 'an already-present window.Checkout'} for checkoutId ` +
+        `${checkoutId}. If that environment does not match the checkout API this cart came from, set ` +
+        `peachEnv on createBookingHost (or window.BW_CHECKOUT_PEACH_SDK_URL).`,
+    );
+  }
+
+  function cleanup() {
+    if (peachInstance) {
+      peachInstance.unmount();
+      peachInstance = null;
+    }
+  }
+
+  onDestroy(cleanup);
+</script>
+
+<!-- Peach's own card form renders inside a cross-origin iframe with its own Cancel/Back controls we have no
+     way to hide or reach (no SDK option, no CSS/JS access across origins) - see Checkout.initiate()'s
+     customisations doc comment above. Presenting it as its own nested dialog over the checkout modal, rather
+     than as just another view swapped into that modal's own body, means Peach's own Cancel/Back read as
+     belonging to Peach's own layer instead of visually competing with a second, separate Back of ours - so
+     this dialog has no back/exit control of its own at all; onCancelled below routes back to contact. -->
+<div class="payment-overlay">
+  <!-- svelte-ignore a11y_click_events_have_key_events a11y_no_static_element_interactions -->
+  <div class="payment-dialog" onclick={(e) => e.stopPropagation()}>
+    <div class="page-header">
+      <h2>Payment</h2>
+      {#if expiresAt}
+        <span class="spacer"></span>
+        <CountdownTimer {expiresAt} />
+      {/if}
+    </div>
+
+    <div class="body">
+      {#if failed}
+        <div class="error-state">
+          <div class="error-icon">!</div>
+          <p class="error-title">Unable to load payment form</p>
+          <p class="error-msg">{errorMessage || 'The checkout session may have expired.'}</p>
+          <!-- Peach's own Cancel/Back never rendered, so this dialog needs one exit of its own here. Reported
+               as an error rather than a cancel: nothing was charged, and CheckoutModal's error path abandons
+               the attempt so a retry mints a fresh Peach checkout instead of reopening this one - which is the
+               only sensible outcome for a checkout that would not even render (e.g. one resumed after a reload
+               that Peach has since expired). -->
+          <button class="btn btn-primary" onclick={() => onPaymentComplete({ status: 'error' })}>Start over</button>
+        </div>
+      {:else}
+        <div id="peach-container"></div>
+      {/if}
+    </div>
+  </div>
+</div>
+
+<style>
+  .payment-overlay {
+    position: fixed;
+    inset: 0;
+    /* Above bw-checkout's own .bw-modal-overlay (z-index 10000) so this reads as a second dialog opening
+       on top of the checkout modal, not content living inside it. */
+    z-index: 10001;
+    background: rgba(0, 0, 0, 0.5);
+    display: flex;
+    align-items: center;
+    justify-content: center;
+    padding: 16px;
+  }
+  .payment-dialog {
+    display: flex;
+    flex-direction: column;
+    width: 100%;
+    max-width: 480px;
+    height: min(700px, 90vh);
+    background: var(--bw-color-bg);
+    border-radius: var(--bw-radius-lg);
+    box-shadow: var(--bw-shadow-3);
+    overflow: hidden;
+  }
+  .body {
+    flex: 1;
+    /* A definite height (not just flex:1 alone) so #peach-container's own height:100% below has something
+       real to resolve against, and so this scrolls as a single region if content overflows - Peach's own
+       root is `height: inherit`, so without that it collapses to its 360px fallback regardless of how tall
+       the card form actually gets (e.g. once billing address fields are showing), and its submit button
+       ends up overlapping the fields above it. */
+    min-height: 0;
+    overflow-y: auto;
+    padding: 16px;
+  }
+  #peach-container {
+    height: 100%;
+  }
+  .error-state {
+    text-align: center;
+    padding: 32px 16px;
+  }
+  .error-icon {
+    width: 48px;
+    height: 48px;
+    border-radius: 50%;
+    border: 2px solid var(--bw-color-border);
+    display: flex;
+    align-items: center;
+    justify-content: center;
+    font-size: 24px;
+    color: var(--bw-color-text-secondary);
+    margin: 0 auto 16px;
+  }
+  .error-title {
+    font-size: 16px;
+    font-weight: 600;
+    margin-bottom: 8px;
+  }
+  .error-msg {
+    font-size: 14px;
+    color: var(--bw-color-text-secondary);
+  }
+  .error-state .btn {
+    margin-top: 16px;
+  }
+</style>

package/src/lib/ResultView.svelte

@@ -14,6 +14,10 @@
 
   let success = $derived(status?.outcome === 'successful');
   let pending = $derived(status?.outcome === 'pending');
+  // Paid, but this gateway could not confirm every item - so it gets its own branch below rather than falling
+  // into the failure one. The shopper's card was charged; telling them "Payment Failed" over an explanation
+  // that opens "Your payment succeeded" is how someone ends up paying twice or charging back a good payment.
+  let partial = $derived(status?.outcome === 'partial');
   // A 'failed' outcome covers two genuinely different situations - see CheckoutModal's own remarks on
   // confirmOutcome. Only one of them is safe to offer "Try Again" for: the payment itself never went
   // through (declined, expired, SDK error), so re-opening the card form charges the shopper once, not
@@ -27,12 +31,18 @@
   {#if verifying}
     <div class="spinner"></div>
     <p class="hint">Verifying payment...</p>
+  <!-- 'pending' is reached whenever this gateway could not get a final answer: the webhook still in flight
+       behind a real charge, but also a confirm that gave up after ~15s, a server error, or a cart the server
+       no longer has. Peach fires onCompleted for a declined card too, and a decline the server could not read
+       back (its own status endpoint unreachable) lands here as readily as a charge does - so this screen must
+       not claim a payment was received. It says what is actually known, which is nothing yet, and still asks
+       the shopper not to pay again, which is right either way round (PR 8447 review). -->
   {:else if pending}
     <div class="icon pending">&hellip;</div>
-    <h2>Payment Received</h2>
+    <h2>Still Checking Your Payment</h2>
     <p class="desc">
       {status?.resultDescription ??
-        "We're still confirming your booking - this can take a minute. Please don't try to pay again; we'll email your confirmation as soon as it's ready."}
+        "We couldn't confirm this payment yet. Please don't try to pay again for now - we'll email you as soon as we know where it stands."}
     </p>
     <div class="actions">
       {#if onCheckAgain}
@@ -40,6 +50,14 @@
       {/if}
       <button class="btn btn-outline" onclick={onDone}>Close</button>
     </div>
+  {:else if partial}
+    <div class="icon partial">!</div>
+    <h2>Booking Incomplete</h2>
+    <p class="desc">
+      {status?.resultDescription ??
+        "Your payment succeeded, but we couldn't confirm every item in your booking. Please contact us with your order details."}
+    </p>
+    <button class="btn btn-outline" onclick={onDone}>Close</button>
   {:else}
     <div class="icon" class:success class:failure={!success}>
       {success ? '✓' : '!'}
@@ -96,8 +114,10 @@
     background: var(--bw-color-primary-light);
   }
   /* Deliberately its own amber, not success green or failure red - payment succeeded (so red reads as an
-     alarming false alarm) but nothing is confirmed yet (so green would be premature). */
-  .icon.pending {
+     alarming false alarm) but the booking is not fully confirmed (so green would be premature). The same is
+     true either way round: 'pending' is not confirmed yet, 'partial' will not be for some of its items. */
+  .icon.pending,
+  .icon.partial {
     border: 2px solid #B8860B;
     color: #B8860B;
     background: rgba(184, 134, 11, 0.08);