@code-collective/booking-widget 1.0.15 → 1.0.17

package/src/lib/PaymentPage.svelte

@@ -62,10 +62,20 @@
             onCompleted: (e: any) => { cleanup(); onPaymentComplete(resultOf('completed', e)); },
             onCancelled: (e: any) => { cleanup(); onPaymentComplete(resultOf('cancelled', e)); },
             onExpired: (e: any) => { cleanup(); onPaymentComplete(resultOf('expired', e)); },
+            // Deliberately left alone: WIDGET-ARCHITECTURE.md documents that while Peach still has attempts
+            // left, it re-prompts inside this same iframe and shows its own decline UI ("4 of 5 card attempts
+            // remaining") without ending the checkout - and observed behaviour is that Peach fires onError for
+            // that case too, not only for a genuinely broken render. Unmounting and handing off to our own
+            // "Payment Failed" screen here would tear that UI down mid-retry, for a checkout Peach has not
+            // actually given up on - so this does not cleanup() or call onPaymentComplete at all. Peach's own
+            // iframe is left to do whatever it was going to do next; the only way out of a truly dead render is
+            // still the `failed` state above (SDK never loaded) and its own Start Over button.
             onError: (e: any) => {
-              reportPeachFailure('Peach reported an error rendering the card form');
-              cleanup();
-              onPaymentComplete(resultOf('error', e));
+              console.error(
+                `[booking-widget] Peach reported onError for checkoutId ${checkoutId} - left untouched, ` +
+                  'Peach owns retries. Payload:',
+                e,
+              );
             },
           },
         });

package/src/lib/api.ts

@@ -117,25 +117,16 @@ export interface BookingApi {
   // after paying, so the widget only ever reads the outcome, it never produces one.
   getCartStatus(): Promise<CheckoutCartStatusDto>;
 
-  // Asks the server to find out what actually happened to the current attempt. Called once when Peach's form
-  // reports the checkout complete - "complete" covers a declined card as much as a charged one, and Peach
-  // sends no webhook for a decline - and then getCartStatus is polled for the answer. Best effort: the server
-  // answers 204 whatever it found, and the sweep reconciles anything it could not.
-  resolvePayment(): Promise<void>;
   // Slides the cart's idle window out to a full window from now, clamped at its absolute ceiling, and
   // re-extends the OCTO holds behind it. There is no refusal to handle: a cart already at its ceiling comes
   // back with the deadline it already had (see isAtExpiryCeiling). Returns the cart with its new expiry so the
   // countdown resumes from the server's numbers rather than a local guess.
   extendCart(): Promise<CheckoutCartDetailDto>;
-  // Reports a specific Peach attempt dead without an outcome so the server reopens the cart for a new one -
+  // Reports a specific Peach checkout dead so the server reopens the cart for a new one -
   // used by CheckoutModal itself, which knows the checkoutId Peach's own callback fired for. See
   // isPaymentSettled for the one refusal that changes what the caller does next.
   abandonPayment(checkoutId: string): Promise<void>;
 
-  // The SDK-failure counterpart to abandonPayment, carrying whatever reason Peach gave. Same guard and same
-  // refusals server-side - the difference is that the attempt is recorded as failed with its code rather than
-  // simply abandoned, which for a card declined inside the checkout is the only place that code ever exists.
-  reportPaymentFailure(checkoutId: string, resultCode?: string, description?: string): Promise<void>;
 }
 
 export class ApiClient implements BookingApi {
@@ -294,30 +285,12 @@ export class ApiClient implements BookingApi {
     return this.unwrap(await this.client.GET('/v1/checkout/cart/status'));
   }
 
-  async resolvePayment(): Promise<void> {
-    const result = await this.client.POST('/v1/checkout/cart/resolve-payment');
-    if (result.response.status >= 400) {
-      throw new ApiError(result.response.status, result.error);
-    }
-  }
-
   async extendCart(): Promise<CheckoutCartDetailDto> {
     return this.unwrap(
       await this.client.POST('/v1/checkout/cart/extend'),
     );
   }
 
-  async reportPaymentFailure(checkoutId: string, resultCode?: string, description?: string): Promise<void> {
-    const result = await this.client.POST('/v1/checkout/cart/payment-failure', {
-      body: { checkoutId, resultCode, description },
-    });
-    // Same shape as abandonPayment below, including keeping the error body: the 409s carry a code the caller
-    // branches on (see isPaymentSettled).
-    if (result.response.status >= 400) {
-      throw new ApiError(result.response.status, result.error);
-    }
-  }
-
   async abandonPayment(checkoutId: string): Promise<void> {
     const result = await this.client.POST('/v1/checkout/cart/abandon-payment', {
       body: { checkoutId },

package/src/lib/checkout-payment-flow.svelte.ts

@@ -1,7 +1,7 @@
 // The state of one shopper's current Peach payment attempt, from minting it through to a settled outcome -
 // split out of CheckoutModal.svelte because this was the single largest, most tangled concern in that file
 // (roughly a third of it): initiating a payment, resuming one after a reload, releasing/reporting a dead or
-// declined attempt, and polling the cart's status until it settles. None of it needs the cart's own item list,
+// spent checkout, and polling the cart's status until it settles. None of it needs the cart's own item list,
 // the contact form, or the wizard's cart/edit views - only the current payment attempt and where it stands.
 
 import type { BookingApi } from './api';
@@ -18,6 +18,22 @@ import { cartDeadline } from './cart-expiry';
 import { postMessage } from './messages';
 import { forgetPaymentAttempt, recallPaymentAttempt, rememberPaymentAttempt } from './payment-attempt';
 
+// Peach reports a finished checkout through onCompleted whether the transaction was charged or rejected, and
+// the only place that distinction exists client-side is the result code in its payload. Mirrors the server's
+// own PeachPaymentOutcome.Classify (Connect.Logic/Checkout/Payments) - the two must agree, so if Peach ever
+// publishes a code family that one treats differently, change both.
+//
+// Deliberately conservative: a completed result whose code is missing or unrecognised is treated as a possible
+// charge and goes to the poll, because showing "Payment Failed" over a card that was actually charged is the
+// one outcome worth avoiding entirely. Only a code this recognises as a genuine failure takes the fail path.
+const PeachSuccessCode = /^(000\.000\.|000\.100\.1|000\.[36]|000\.400\.1[12]0|000\.400\.0[^3]|000\.400\.100)/;
+const PeachPendingCode = /^(000\.200|800\.400\.5|100\.400\.500)/;
+
+function isFailureCode(resultCode: string | undefined): boolean {
+  if (!resultCode) return false;
+  return !PeachSuccessCode.test(resultCode) && !PeachPendingCode.test(resultCode);
+}
+
 // Peach's webhook is typically near-instant, but is a genuinely separate async delivery from the card charge
 // itself, and confirming the bookings behind it means a call per item to a supplier. 90s at 1.5s intervals
 // covers both without making a shopper whose payment already succeeded wait an unreasonable time to see it.
@@ -89,19 +105,18 @@ export function createCheckoutPaymentFlow(deps: CheckoutPaymentFlowDeps): Checko
   // A reload mid-payment: the server still holds this cart in AwaitingPaymentConfirmation for the Peach
   // checkout recorded before the reload, and will refuse every edit and a second payCart until that attempt
   // is settled or abandoned. Where to land depends on how far the shopper got before the reload, and only the
-  // server knows: Peach's form may have completed a moment earlier - a charge, or a decline the server reads
-  // straight back from Peach's status endpoint, since Peach sends no webhook for one - so it is asked once
-  // first, and a recorded outcome is shown exactly as it would have been without the reload. Only "not paid"
-  // puts the shopper back on that same card form, whose Peach handlers then route as they do without a
-  // reload: a completed charge confirms, a cancel/expiry/error abandons the attempt and reopens the cart.
+  // server knows: the charge may have landed a moment earlier, so the cart is read once first and a settled
+  // outcome is shown exactly as it would have been without the reload. Anything short of that puts the shopper
+  // back on the same card form, whose Peach handlers then route as they do without a reload: a completed
+  // charge confirms, a cancel/expiry/error releases the checkout and reopens the cart. A card declined in
+  // between changes nothing here - it never ended Peach's checkout, so the form is still the right place.
   // Same resume as payNow's own paymentResult short-cut.
   async function resumeInterruptedPayment(): Promise<void> {
     const interruptedAttempt = recallPaymentAttempt(deps.getApi().cartToken);
     if (!interruptedAttempt) return;
     paymentResult = interruptedAttempt;
-    // Posted before the answer is known, as payNow does: CartExpiryGuard must treat the attempt as in flight
-    // whichever screen it ends up on, and a decline's own payment:ended (releaseDeclinedAttempt) then reads the
-    // same as it does without a reload.
+    // Posted before the answer is known, as payNow does: CartExpiryGuard must treat the payment as in flight
+    // whichever screen it ends up on.
     postMessage({ type: 'payment:started' });
     if (await resumeOntoRecordedOutcome()) return;
     deps.setView('payment');
@@ -111,14 +126,13 @@ export function createCheckoutPaymentFlow(deps: CheckoutPaymentFlowDeps): Checko
     if (cartDeadline(deps.getCart()).getTime() <= Date.now()) void onPaymentTimedOut();
   }
 
-  // Where a reload lands. One status read decides it: a settled attempt (a charge, a supplier-side partial
-  // failure, or a decline) goes straight to the result screen; a confirmation in flight joins the ordinary
-  // poll to read its outcome; a cart the server no longer has closes the modal, as a 401 does everywhere else
-  // here. Anything still genuinely unresolved - a shopper who never submitted the card, or one who reloaded
-  // mid-3-D Secure, which cannot be told apart from here (PR 8447 review) - goes back to the card form, since
-  // that is Peach's own form for this same checkoutId rather than a fresh charge. An unreachable server is
-  // treated the same way, rather than parking them on a screen telling them not to pay again for a card they
-  // may never have submitted.
+  // Where a reload lands. One status read decides it: a confirmed cart goes straight to the result screen; a
+  // confirmation in flight joins the ordinary poll to read its outcome; a cart the server no longer has closes
+  // the modal, as a 401 does everywhere else here. Anything still unresolved - a shopper who never submitted
+  // the card, one who reloaded mid-3-D Secure, or one still working through declines on Peach's own form,
+  // none of which can be told apart from here - goes back to the card form, since that is Peach's own form for
+  // this same checkoutId rather than a fresh charge. An unreachable server is treated the same way, rather
+  // than parking them on a screen telling them not to pay again for a card they may never have submitted.
   async function resumeOntoRecordedOutcome(): Promise<boolean> {
     isConfirming = true;
     deps.setView('result');
@@ -141,9 +155,13 @@ export function createCheckoutPaymentFlow(deps: CheckoutPaymentFlowDeps): Checko
       return true;
     }
 
-    if (status.paymentOutcome === 'failed' || status.paymentOutcome === 'abandoned') {
+    // Expired while the tab was away - the sweep found a cart nobody came back to. There is no card form to
+    // return to, so this owns where the shopper lands rather than falling through to one.
+    if (status.cartStatus === 'expired') {
       confirmOutcome = 'notCharged';
-      await releaseDeclinedAttempt();
+      forgetPaymentAttempt();
+      paymentResult = null;
+      postMessage({ type: 'payment:ended' });
       isConfirming = false;
       return true;
     }
@@ -158,24 +176,20 @@ export function createCheckoutPaymentFlow(deps: CheckoutPaymentFlowDeps): Checko
     return false;
   }
 
-  // Tells the server this attempt is over so a fresh payCart will be accepted - without it the cart stays
-  // AwaitingPaymentConfirmation, no webhook ever comes for a checkout nobody submitted, and the only thing a
-  // retry could do is reopen a Peach session that is already dead. 'settled' means Peach has this attempt as
-  // paid, or still in flight (PAYMENT_PENDING) - either way the cart must not be reopened, and the confirm loop
+  // Tells the server this checkout is over so a fresh payCart will be accepted - without it the cart stays
+  // AwaitingPaymentConfirmation, no webhook ever comes for a checkout nobody paid, and the only thing a retry
+  // could do is reopen a Peach session that is already dead. 'settled' means Peach has this checkout as paid,
+  // or still in flight (PAYMENT_PENDING) - either way the cart must not be reopened, and the confirm loop
   // already handles "not paid yet" by landing on the pending screen, so both take the same path here; 'failed'
   // means the server could not be reached or refused for another reason, in which case paymentResult is kept
-  // so payNow falls back to resuming the same still-open attempt.
-  // Two endpoints, one guard behind them: a shopper backing out or a clock running out is an abandon, while
-  // Peach's own SDK reporting a failure carries a reason worth recording against the attempt - and for a card
-  // declined inside the checkout, where Peach sends no webhook, that payload is the only place its code exists.
-  async function abandonPaymentAttempt(checkoutId: string, failure?: PaymentSdkResult):
-    Promise<'abandoned' | 'settled' | 'failed'> {
+  // so payNow falls back to resuming the same still-open checkout.
+  // One endpoint for every way out: a shopper backing out, a clock running out, and Peach's own SDK reporting
+  // the checkout unusable are all the same thing to this gateway - a checkout nothing was charged on. A
+  // declined card is not among them: Peach keeps the shopper on its own form to try again, and none of that
+  // ever reaches here.
+  async function abandonPaymentAttempt(checkoutId: string): Promise<'abandoned' | 'settled' | 'failed'> {
     try {
-      if (failure) {
-        await deps.getApi().reportPaymentFailure(checkoutId, failure.resultCode, failure.description);
-      } else {
-        await deps.getApi().abandonPayment(checkoutId);
-      }
+      await deps.getApi().abandonPayment(checkoutId);
       return 'abandoned';
     } catch (e) {
       return isPaymentSettled(e) || isPaymentPending(e) ? 'settled' : 'failed';
@@ -250,19 +264,13 @@ export function createCheckoutPaymentFlow(deps: CheckoutPaymentFlowDeps): Checko
   }
 
   async function onPaymentComplete(result: PaymentSdkResult): Promise<void> {
-    // Neither cancelled, expired nor error ever reached a real charge - Peach's own SDK is reporting that the
-    // checkout itself didn't go through (the shopper backed out, session timeout, a declined card, a 3DS
-    // failure, a client-side error), not that a successful charge's confirmation is in question. That
-    // distinction matters: the confirm path at the bottom is only reachable once onCompleted has fired, which
-    // Peach does for a settled outcome of either kind - a charge, or a decline (the server reads that back from
-    // Peach's status endpoint, since Peach sends no webhook for one, and answers PAYMENT_FAILED). So "try again"
-    // there is only ever offered once the server itself has said nothing was charged. Here nothing was charged,
-    // so the attempt is abandoned server-side (a retry then starts a genuinely new Peach checkout instead of
-    // reopening this dead one) and re-opening the card form is exactly correct.
-    if (result.status === 'cancelled' || result.status === 'expired' || result.status === 'error') {
-      // Only the two genuine failures carry Peach's own reason; a shopper backing out has none to give.
-      const failure = result.status === 'cancelled' ? undefined : result;
-      if (!(await releaseAbandonedAttempt(failure))) return;
+    // Cancelled and expired are genuinely terminal on Peach's side: the shopper backed out, or the session
+    // timed out. error never reaches here from Peach's own iframe any more (PaymentPage's onError is left
+    // untouched - Peach owns retries and shows its own "4 of 5 attempts remaining" UI without ending the
+    // checkout) - the only source left is the `failed` state's Start Over button, for a checkout that never
+    // even rendered. That is handled below, mirrored on the isFailureCode branch, rather than released here.
+    if (result.status === 'cancelled' || result.status === 'expired') {
+      if (!(await releaseAbandonedAttempt())) return;
     }
 
     if (result.status === 'cancelled') {
@@ -270,34 +278,53 @@ export function createCheckoutPaymentFlow(deps: CheckoutPaymentFlowDeps): Checko
       return;
     }
 
-    if (result.status === 'expired' || result.status === 'error') {
+    if (result.status === 'expired') {
       confirmOutcome = 'notCharged';
       isConfirming = false;
       deps.setView('result');
       return;
     }
 
-    // Peach's form has reported the checkout complete, which covers a declined card as much as a charged one.
-    // The server is asked once to go and find out which, because no webhook is coming for a decline; the poll
-    // below then reads whatever it established. Best effort - a failure here only means the answer arrives
-    // from the webhook or the sweep instead, which is exactly what the poll is already waiting for.
-    deps.setView('result');
-    try {
-      await deps.getApi().resolvePayment();
-    } catch {
-      // see above
+    // A completed checkout is not the same as a charged one. Peach fires onCompleted for a transaction it
+    // rejected as well as one it charged, and by the time it does so its own form has already offered the
+    // shopper every retry it was going to - so this is the end of the road, not a state to wait on. The
+    // Start-Over error case is folded in here rather than treated as its own terminal branch above: a
+    // checkout that never rendered gets the same answer as one Peach rejected - nothing was charged, and the
+    // cart is left exactly as it is either way.
+    //
+    // Nothing is asked of the server here, deliberately. Peach's checkout-level status endpoint answers
+    // "transaction pending" for a checkout whose transaction was rejected, so consulting it would turn a known
+    // failure back into a guess; it is only good for confirming a success. The cart is left exactly as it is -
+    // the next Pay Now mints a new checkout over this one (CheckoutCartService.CanInitiatePayment: a cart in
+    // AwaitingPaymentConfirmation stays payable specifically because "a decline is Peach's business"). Calling
+    // abandon-payment here instead - as this used to - only ever pre-empted that: it would either abort an
+    // attempt Peach had not actually given up on, or be flatly refused with a 409 because Peach's own status
+    // already disagreed, sending this down the exact same path anyway.
+    if (result.status === 'error' || isFailureCode(result.resultCode)) {
+      paymentResult = null;
+      forgetPaymentAttempt();
+      confirmOutcome = 'notCharged';
+      isConfirming = false;
+      deps.setView('result');
+      // CartExpiryGuard has to stop treating a payment as in flight, or it never prompts or expires again.
+      postMessage({ type: 'payment:ended' });
+      return;
     }
+
+    // A charge, or a code this cannot read. The webhook is what moves the cart to Paid; this poll only reads
+    // the cart until it says so.
+    deps.setView('result');
     await runStatusPoll();
   }
 
   // False when this flow has already taken over what happens next - the cart turned out to be paid and is
   // being confirmed, or it has expired - so the caller must not route the shopper anywhere else.
-  async function releaseAbandonedAttempt(failure?: PaymentSdkResult): Promise<boolean> {
+  async function releaseAbandonedAttempt(): Promise<boolean> {
     // Already cleared by an earlier call for this same attempt (e.g. a second Peach callback after the first
     // already abandoned it) - nothing left to tell the server about.
     if (!paymentResult) return await deps.reloadCart();
 
-    const abandoned = await abandonPaymentAttempt(paymentResult.checkoutId, failure);
+    const abandoned = await abandonPaymentAttempt(paymentResult.checkoutId);
     if (abandoned === 'settled') {
       deps.setView('result');
       await runStatusPoll();
@@ -323,49 +350,21 @@ export function createCheckoutPaymentFlow(deps: CheckoutPaymentFlowDeps): Checko
   }
 
   // Back to the contact form rather than straight to 'payment'. Every outcome that offers Try Again is one
-  // where nothing was charged, and in all but one of them the attempt has already been released (a decline
-  // here, a Peach-reported expiry or error in onPaymentComplete) - so there is no card form left to return to:
-  // Peach's SDK will not re-render a checkoutId it has unmounted, and a checkout that reached a decline is
-  // finished on Peach's side regardless. Contact is where payNow creates a genuinely new one, with the
-  // shopper's details still filled in (they live in the parent component, not in ContactForm) so paying again -
-  // on another card, if that is what the decline was about - is one click away. The exception needs no handling
-  // of its own: after an abandon the server refused, the attempt is still open and payNow's own paymentResult
-  // short-cut resumes that same one from here, which is exactly what it is there for.
+  // where nothing was charged and the checkout behind it has already been released (a Peach-reported expiry or
+  // error in onPaymentComplete) - so there is no card form left to return to: Peach's SDK will not re-render a
+  // checkoutId it has unmounted. Contact is where payNow creates a genuinely new checkout, with the shopper's
+  // details still filled in (they live in the parent component, not in ContactForm) so paying again is one
+  // click away. The one exception needs no handling of its own: after an abandon the server refused, the
+  // checkout is still open and payNow's own paymentResult short-cut resumes that same one from here, which is
+  // exactly what it is there for.
   function retry(): void {
     deps.setView('contact');
   }
 
-  // The declined counterpart to releaseAbandonedAttempt, and deliberately without its abandon call: the server
-  // has already resolved this attempt itself - a decline reached it (Peach's webhook, or its own read of Peach's
-  // status endpoint on the status poll, since Peach sends no webhook for a declined card), which is what moved
-  // the cart to Failed - so there is nothing left to report. AbandonPaymentAsync answers a Failed cart with
-  // AlreadyOpen, an explicit no-op.
-  // Clearing the attempt is what makes Try Again start a NEW Peach checkout instead of reopening the dead one:
-  // payNow resumes paymentResult when it is still set, and resumeInterruptedPayment would land a reload
-  // straight back on that same spent card form.
-  async function releaseDeclinedAttempt(): Promise<void> {
-    paymentResult = null;
-    forgetPaymentAttempt();
-    // Failed is live and still payable again - the decline leaves the cart's one clock exactly where it was -
-    // so this re-reads whatever time Try Again actually has left rather than the deadline from before the card
-    // form. A cart whose clock ran out meanwhile 401s here and closes the modal, same as anywhere else. Any
-    // other failure of the re-read must not escape: this runs inside resumeOntoRecordedOutcome's own catch,
-    // from where a throw would strand the shopper on "Verifying payment..." with no button at all, and the
-    // decline itself is already recorded - Try Again simply counts down from the older deadline (PR 8447 review).
-    try {
-      if (await deps.reloadCart()) deps.notifyCartUpdated(deps.getCart());
-    } catch {
-      // see above
-    }
-    // Without this CartExpiryGuard keeps treating a payment as in flight for the rest of the page's life, so it
-    // never prompts or expires this cart again.
-    postMessage({ type: 'payment:ended' });
-  }
-
   // One status read, interpreted - the single place that decides what a given cart state means, shared by the
-  // automatic poll and the manual on-demand recheck. 'settled' has recorded the outcome (success, a
-  // supplier-side partial failure, or a decline); 'waiting' means the backend has not finished and another
-  // read is worth making.
+  // automatic poll and the manual on-demand recheck. 'settled' has recorded the outcome (success, or a
+  // supplier-side partial failure); 'waiting' means the backend has not finished and another read is worth
+  // making.
   async function pollOnce(signal?: AbortSignal): Promise<'settled' | 'waiting'> {
     let status;
     try {
@@ -394,15 +393,12 @@ export function createCheckoutPaymentFlow(deps: CheckoutPaymentFlowDeps): Checko
       return 'settled';
     }
 
-    // A settled non-success attempt. The server has already asked Peach directly if no webhook arrived (Peach
-    // sends none for a card declined inside a checkout), so this is a real answer rather than a guess, and the
-    // cart is payable again - nothing was captured.
-    if (status.paymentOutcome === 'failed' || status.paymentOutcome === 'abandoned') {
+    // The stuck-payment sweep released this cart: nothing was charged, nothing is coming, and the holds
+    // behind it are being cancelled. Terminal - polling on would just wait out the window.
+    if (status.cartStatus === 'expired') {
       confirmOutcome = 'notCharged';
-      // Clears the spent Peach checkout so Try Again mints a new one rather than reopening a dead card form,
-      // and re-reads the cart's remaining time. The server has already resolved this attempt itself, so there
-      // is nothing left to report to it.
-      await releaseDeclinedAttempt();
+      forgetPaymentAttempt();
+      paymentResult = null;
       return 'settled';
     }
 

package/src/lib/generated-types.ts

@@ -108,23 +108,6 @@ export interface paths {
         patch?: never;
         trace?: never;
     };
-    "/v1/checkout/cart/resolve-payment": {
-        parameters: {
-            query?: never;
-            header?: never;
-            path?: never;
-            cookie?: never;
-        };
-        get?: never;
-        put?: never;
-        /** Resolve checkout cart payment */
-        post: operations["ResolveCheckoutCartPayment_v1"];
-        delete?: never;
-        options?: never;
-        head?: never;
-        patch?: never;
-        trace?: never;
-    };
     "/v1/checkout/cart/status": {
         parameters: {
             query?: never;
@@ -159,23 +142,6 @@ export interface paths {
         patch?: never;
         trace?: never;
     };
-    "/v1/checkout/cart/payment-failure": {
-        parameters: {
-            query?: never;
-            header?: never;
-            path?: never;
-            cookie?: never;
-        };
-        get?: never;
-        put?: never;
-        /** Report checkout cart payment failure */
-        post: operations["ReportCheckoutCartPaymentFailure_v1"];
-        delete?: never;
-        options?: never;
-        head?: never;
-        patch?: never;
-        trace?: never;
-    };
     "/v1/checkout/cart/abandon-payment": {
         parameters: {
             query?: never;
@@ -454,11 +420,6 @@ export interface components {
         CheckoutCartPayDto: {
             contact?: components["schemas"]["OctoContact"];
         };
-        CheckoutCartPaymentFailureDto: {
-            checkoutId?: string | null;
-            resultCode?: string | null;
-            description?: string | null;
-        };
         CheckoutCartPaymentInitiationDto: {
             checkoutId?: string | null;
             redirectUrl?: string | null;
@@ -484,9 +445,6 @@ export interface components {
         };
         CheckoutCartStatusDto: {
             cartStatus?: string | null;
-            paymentOutcome?: string | null;
-            resolvedBy?: string | null;
-            resultCode?: string | null;
             confirmResult?: components["schemas"]["CheckoutCartConfirmResultDto"];
         };
         CheckoutFaqDto: {
@@ -814,24 +772,6 @@ export interface operations {
             };
         };
     };
-    ResolveCheckoutCartPayment_v1: {
-        parameters: {
-            query?: never;
-            header?: never;
-            path?: never;
-            cookie?: never;
-        };
-        requestBody?: never;
-        responses: {
-            /** @description No Content */
-            204: {
-                headers: {
-                    [name: string]: unknown;
-                };
-                content?: never;
-            };
-        };
-    };
     GetCheckoutCartStatus_v1: {
         parameters: {
             query?: never;
@@ -872,28 +812,6 @@ export interface operations {
             };
         };
     };
-    ReportCheckoutCartPaymentFailure_v1: {
-        parameters: {
-            query?: never;
-            header?: never;
-            path?: never;
-            cookie?: never;
-        };
-        requestBody: {
-            content: {
-                "application/json": components["schemas"]["CheckoutCartPaymentFailureDto"];
-            };
-        };
-        responses: {
-            /** @description No Content */
-            204: {
-                headers: {
-                    [name: string]: unknown;
-                };
-                content?: never;
-            };
-        };
-    };
     AbandonCheckoutCartPayment_v1: {
         parameters: {
             query?: never;