@autobusal/order-process 1.3.8 → 1.5.0

package/BKT/Bkt.tsx

@@ -17,7 +17,7 @@ const Bkt = ({ hash, t }: Props): JSX.Element => {
 
   const ref = useRef<HTMLFormElement>(null);
 
-  const { data, isLoading, isSuccess, isError } = useMakeBkt(String(hash));
+  const { data, isLoading, isSuccess, isError, error } = useMakeBkt(String(hash));
 
   const navigate = useNavigate();
 
@@ -37,11 +37,20 @@ const Bkt = ({ hash, t }: Props): JSX.Element => {
   // loading text forever with no way out. Fix: navigate back so they can
   // retry. Same fix as Raiffeisen/Stripe/Mollie/Nexi (see Raiffeisen.tsx for
   // the full explanation, including why there's no toast() call here).
+  /*
+   * See Raiffeisen for the reasoning - a refused payment goes to the
+   * booking's own payment-not-completed page, not back to a checkout form
+   * whose contents this navigation has already destroyed.
+   */
   useEffect(() => {
     if (isError) {
-      navigate(-1);
+      const message = (error as { response?: { data?: { message?: string } } })?.response?.data?.message;
+
+      const reason = message ?? t('order_process.error', { ns: 'common', defaultValue: 'We could not complete your payment. Please try again.' });
+
+      navigate(hash ? `/orders/cancelled/${ hash }?msg=${ encodeURIComponent(reason) }` : '/', { replace: true });
     }
-  }, [isError, navigate]);
+  }, [isError, error, hash, navigate, t]);
 
   if (isLoading) {
     return (

package/Mollie/Mollie.tsx

@@ -11,7 +11,7 @@ interface Props {
 }
 
 const Mollie = ({ hash, t }: Props): JSX.Element => {
-  const { data, isSuccess, isError } = useMakeMollie(String(hash));
+  const { data, isSuccess, isError, error } = useMakeMollie(String(hash));
 
   const navigate = useNavigate();
 
@@ -21,18 +21,35 @@ const Mollie = ({ hash, t }: Props): JSX.Element => {
     }
   }, [data, isSuccess]);
 
-  // Edited: Ferjolt Ozuni - Date: 2026-07-18
-  // Bug: this only ever checked isSuccess - a failed payment-initiation
-  // request left the user staring at "Preparing to take you to the payment
-  // portal..." forever with no feedback at all. Fix: navigate back so they
-  // can retry. Same fix applied identically to Raiffeisen/Stripe/Nexi/Bkt
-  // (see Raiffeisen.tsx for the full explanation, including why there's no
-  // toast() call here).
+  /*
+   * A REFUSED CARD PAYMENT IS NOT A "GO BACK".
+   *
+   * Claude - 2026-08-31, reported by Ferjolt: "when I click on Pay button, it
+   * just refreshes and shows me a toaster error ... The toaster error is very
+   * easy to be missed and the visitor does not understand anything what
+   * happened."
+   *
+   * That is exactly what navigate(-1) looked like. It returned to the
+   * checkout URL, but the checkout's CONTENTS - the coach, the passengers,
+   * the seats - live in the wizard's React state, which navigating away had
+   * already destroyed. So the buyer landed back on an empty form, with the
+   * only explanation in a toast that fades.
+   *
+   * The order EXISTS at this point and its seats are still held; what failed
+   * is the settlement. So this goes where the funds path has gone since
+   * BOOK-11-b: the booking's own payment-not-completed page, which says the
+   * reservation is still theirs, carries the reason, and offers a retry.
+   * `replace`, because a failed attempt is not a step to press Back into.
+   */
   useEffect(() => {
     if (isError) {
-      navigate(-1);
+      const message = (error as { response?: { data?: { message?: string } } })?.response?.data?.message;
+
+      const reason = message ?? t('order_process.error', { ns: 'common', defaultValue: 'We could not complete your payment. Please try again.' });
+
+      navigate(hash ? `/orders/cancelled/${ hash }?msg=${ encodeURIComponent(reason) }` : '/', { replace: true });
     }
-  }, [isError, navigate]);
+  }, [isError, error, hash, navigate, t]);
 
   return (
     <Container>

package/Nexi/Nexi.tsx

@@ -11,7 +11,7 @@ interface Props {
 }
 
 const Nexi = ({ hash, t }: Props): JSX.Element => {
-  const { data, isSuccess, isError } = useMakeNexi(String(hash));
+  const { data, isSuccess, isError, error } = useMakeNexi(String(hash));
 
   const navigate = useNavigate();
 
@@ -21,18 +21,35 @@ const Nexi = ({ hash, t }: Props): JSX.Element => {
     }
   }, [data, isSuccess]);
 
-  // Edited: Ferjolt Ozuni - Date: 2026-07-18
-  // Bug: this only ever checked isSuccess - a failed payment-initiation
-  // request left the user staring at "Preparing to take you to the payment
-  // portal..." forever with no feedback at all. Fix: navigate back so they
-  // can retry. Same fix applied identically to Raiffeisen/Stripe/Mollie/Bkt
-  // (see Raiffeisen.tsx for the full explanation, including why there's no
-  // toast() call here).
+  /*
+   * A REFUSED CARD PAYMENT IS NOT A "GO BACK".
+   *
+   * Claude - 2026-08-31, reported by Ferjolt: "when I click on Pay button, it
+   * just refreshes and shows me a toaster error ... The toaster error is very
+   * easy to be missed and the visitor does not understand anything what
+   * happened."
+   *
+   * That is exactly what navigate(-1) looked like. It returned to the
+   * checkout URL, but the checkout's CONTENTS - the coach, the passengers,
+   * the seats - live in the wizard's React state, which navigating away had
+   * already destroyed. So the buyer landed back on an empty form, with the
+   * only explanation in a toast that fades.
+   *
+   * The order EXISTS at this point and its seats are still held; what failed
+   * is the settlement. So this goes where the funds path has gone since
+   * BOOK-11-b: the booking's own payment-not-completed page, which says the
+   * reservation is still theirs, carries the reason, and offers a retry.
+   * `replace`, because a failed attempt is not a step to press Back into.
+   */
   useEffect(() => {
     if (isError) {
-      navigate(-1);
+      const message = (error as { response?: { data?: { message?: string } } })?.response?.data?.message;
+
+      const reason = message ?? t('order_process.error', { ns: 'common', defaultValue: 'We could not complete your payment. Please try again.' });
+
+      navigate(hash ? `/orders/cancelled/${ hash }?msg=${ encodeURIComponent(reason) }` : '/', { replace: true });
     }
-  }, [isError, navigate]);
+  }, [isError, error, hash, navigate, t]);
 
   return (
     <Container>

package/Reiffeisen/Raiffeisen.tsx

@@ -11,7 +11,7 @@ interface Props {
 }
 
 const Raiffeisen = ({ hash, t }: Props): JSX.Element => {
-  const { data, isSuccess, isError } = useMakeRaiffeisen(String(hash));
+  const { data, isSuccess, isError, error } = useMakeRaiffeisen(String(hash));
 
   const navigate = useNavigate();
 
@@ -21,21 +21,35 @@ const Raiffeisen = ({ hash, t }: Props): JSX.Element => {
     }
   }, [data, isSuccess]);
 
-  // Edited: Ferjolt Ozuni - Date: 2026-07-18
-  // Bug: this only ever checked isSuccess - a failed payment-initiation
-  // request (gateway auth failure, no funds, etc) left the user staring
-  // at "Preparing to take you to the payment portal..." forever with no
-  // feedback at all and no way out except leaving the page. Fix: navigate
-  // them back so they can retry. No toast() call here - apiClient's Axios
-  // response interceptor (@autobusal/providers/Queries/apiClient.ts)
-  // already shows one for every 422/500, and calling error() again here
-  // stacked a second, duplicate toast on top of it (caught in browser
-  // testing against the Raiffeisen sandbox).
+  /*
+   * A REFUSED CARD PAYMENT IS NOT A "GO BACK".
+   *
+   * Claude - 2026-08-31, reported by Ferjolt: "when I click on Pay button, it
+   * just refreshes and shows me a toaster error ... The toaster error is very
+   * easy to be missed and the visitor does not understand anything what
+   * happened."
+   *
+   * That is exactly what navigate(-1) looked like. It returned to the
+   * checkout URL, but the checkout's CONTENTS - the coach, the passengers,
+   * the seats - live in the wizard's React state, which navigating away had
+   * already destroyed. So the buyer landed back on an empty form, with the
+   * only explanation in a toast that fades.
+   *
+   * The order EXISTS at this point and its seats are still held; what failed
+   * is the settlement. So this goes where the funds path has gone since
+   * BOOK-11-b: the booking's own payment-not-completed page, which says the
+   * reservation is still theirs, carries the reason, and offers a retry.
+   * `replace`, because a failed attempt is not a step to press Back into.
+   */
   useEffect(() => {
     if (isError) {
-      navigate(-1);
+      const message = (error as { response?: { data?: { message?: string } } })?.response?.data?.message;
+
+      const reason = message ?? t('order_process.error', { ns: 'common', defaultValue: 'We could not complete your payment. Please try again.' });
+
+      navigate(hash ? `/orders/cancelled/${ hash }?msg=${ encodeURIComponent(reason) }` : '/', { replace: true });
     }
-  }, [isError, navigate]);
+  }, [isError, error, hash, navigate, t]);
 
   return (
     <Container>

package/Stripe/Stripe.tsx

@@ -11,7 +11,7 @@ interface Props {
 }
 
 const Stripe = ({ hash, t }: Props): JSX.Element => {
-  const { data, isSuccess, isError } = useMakeStripe(String(hash));
+  const { data, isSuccess, isError, error } = useMakeStripe(String(hash));
 
   const navigate = useNavigate();
 
@@ -21,18 +21,35 @@ const Stripe = ({ hash, t }: Props): JSX.Element => {
     }
   }, [data, isSuccess]);
 
-  // Edited: Ferjolt Ozuni - Date: 2026-07-18
-  // Bug: this only ever checked isSuccess - a failed payment-initiation
-  // request left the user staring at "Preparing to take you to the payment
-  // portal..." forever with no feedback at all. Fix: navigate back so they
-  // can retry. Same fix applied identically to Raiffeisen/Mollie/Nexi/Bkt
-  // (see Raiffeisen.tsx for the full explanation, including why there's no
-  // toast() call here).
+  /*
+   * A REFUSED CARD PAYMENT IS NOT A "GO BACK".
+   *
+   * Claude - 2026-08-31, reported by Ferjolt: "when I click on Pay button, it
+   * just refreshes and shows me a toaster error ... The toaster error is very
+   * easy to be missed and the visitor does not understand anything what
+   * happened."
+   *
+   * That is exactly what navigate(-1) looked like. It returned to the
+   * checkout URL, but the checkout's CONTENTS - the coach, the passengers,
+   * the seats - live in the wizard's React state, which navigating away had
+   * already destroyed. So the buyer landed back on an empty form, with the
+   * only explanation in a toast that fades.
+   *
+   * The order EXISTS at this point and its seats are still held; what failed
+   * is the settlement. So this goes where the funds path has gone since
+   * BOOK-11-b: the booking's own payment-not-completed page, which says the
+   * reservation is still theirs, carries the reason, and offers a retry.
+   * `replace`, because a failed attempt is not a step to press Back into.
+   */
   useEffect(() => {
     if (isError) {
-      navigate(-1);
+      const message = (error as { response?: { data?: { message?: string } } })?.response?.data?.message;
+
+      const reason = message ?? t('order_process.error', { ns: 'common', defaultValue: 'We could not complete your payment. Please try again.' });
+
+      navigate(hash ? `/orders/cancelled/${ hash }?msg=${ encodeURIComponent(reason) }` : '/', { replace: true });
     }
-  }, [isError, navigate]);
+  }, [isError, error, hash, navigate, t]);
 
   return (
     <Container>

package/package.json

@@ -1,7 +1,10 @@
 {
   "name": "@autobusal/order-process",
-  "version": "1.3.8",
+  "version": "1.5.0",
   "author": "Ferjolt Ozuni",
   "type": "module",
-  "main": "index.ts"
+  "main": "index.ts",
+  "publishConfig": {
+    "access": "public"
+  }
 }

package/services.ts

@@ -2,9 +2,39 @@ import { useQuery, UseQueryResult } from '@tanstack/react-query';
 import { apiClient } from '@autobusal/providers';
 import { BKTData, StripeData, MollieData, RaiffeisenData, NexiData } from './types';
 
+/**
+ * Starting a payment must happen EXACTLY ONCE per attempt.
+ *
+ * Claude - 2026-08-31, after Ferjolt hit "Too Many Attempts" retrying a
+ * card payment.
+ *
+ * These are useQuery, and react-query's defaults are built for reads: it
+ * retries a failure three times, and refetches on window focus, on reconnect
+ * and on mount. So ONE failed payment fired four POSTs, and alt-tabbing away
+ * and back fired more.
+ *
+ * Two things wrong with that, and the rate limit is the milder one. Each
+ * call creates an ORDER ENTRY at the gateway, and RaiAccept requires
+ * merchantOrderReference to be unique per attempt - it rejects a repeat as
+ * error 1007 - so the silent retries were manufacturing duplicate gateway
+ * orders for a single click, and the visible failure could be the retry
+ * being refused rather than the original problem.
+ *
+ * A payment is not a read. It fires once, when the component mounts, and a
+ * failure is reported rather than quietly attempted again.
+ */
+const ONCE = {
+  retry: false,
+  refetchOnWindowFocus: false,
+  refetchOnReconnect: false,
+  refetchOnMount: false,
+  staleTime: Infinity
+} as const;
+
 export const useMakeStandard = (type: string, hash: string): UseQueryResult<string> => (
   useQuery({
     queryKey: ['process-payment-standard', { type, hash }],
+    ...ONCE,
     queryFn: async () => (
       await apiClient
         .post('/api/payment/make', {
@@ -21,6 +51,7 @@ export const useMakeStandard = (type: string, hash: string): UseQueryResult<stri
 export const useMakeBkt = (hash: string): UseQueryResult<BKTData> => (
   useQuery({
     queryKey: ['process-payment-bkt', { hash }],
+    ...ONCE,
     queryFn: async () => (
       await apiClient
         .post('/api/payment/bkt', { hash })
@@ -34,6 +65,7 @@ export const useMakeBkt = (hash: string): UseQueryResult<BKTData> => (
 export const useMakeStripe = (hash: string): UseQueryResult<StripeData> => (
   useQuery({
     queryKey: ['process-payment-stripe', { hash }],
+    ...ONCE,
     queryFn: async () => (
       await apiClient
         .post('/api/payment/stripe', { hash })
@@ -47,6 +79,7 @@ export const useMakeStripe = (hash: string): UseQueryResult<StripeData> => (
 export const useMakeMollie = (hash: string): UseQueryResult<MollieData> => (
   useQuery({
     queryKey: ['process-payment-mollie', { hash }],
+    ...ONCE,
     queryFn: async () => (
       await apiClient
         .post('/api/payment/mollie', { hash })
@@ -60,6 +93,7 @@ export const useMakeMollie = (hash: string): UseQueryResult<MollieData> => (
 export const useMakeRaiffeisen = (hash: string): UseQueryResult<RaiffeisenData> => (
   useQuery({
     queryKey: ['process-payment-raiffeisen', { hash }],
+    ...ONCE,
     queryFn: async () => (
       await apiClient
         .post('/api/payment/raiffeisen', { hash })
@@ -73,6 +107,7 @@ export const useMakeRaiffeisen = (hash: string): UseQueryResult<RaiffeisenData>
 export const useMakeNexi = (hash: string): UseQueryResult<NexiData> => (
   useQuery({
     queryKey: ['process-payment-nexi', { hash }],
+    ...ONCE,
     queryFn: async () => (
       await apiClient
         .post('/api/payment/nexi', { hash })

package/CHANGELOG.md

@@ -1,61 +0,0 @@
-# Changelog
-
-## 1.3.8 - 2026-08-29
-
-- A refused funds/cash settlement lands on the booking's own payment-not-completed page instead of navigate(-1) (audit A9-39). Back returned to the checkout URL while the checkout's contents lived in wizard state the navigation had destroyed, so the seller arrived at a bare results page with their held reservation findable only through Browse Orders.
-
-## 1.3.6
-
-### Fixed
-
-- **A 200 with an empty body no longer navigates to the homepage** while the order sits reserved - the confirmation path is only followed when the API actually named one. (Audit BOOK-04-b.)
-
-## 1.3.5
-
-### Fixed
-
-- **A refused funds payment spun forever.** The standard (funds/reserve) processor had only a success branch, so an agent's "not enough funds" left the page on "Processing your order" with no message and the order stuck reserved. It now surfaces the API's own message and returns the buyer so they can try again. (Platform audit BOOK-05-c.)
-
-All notable changes to `@autobusal/order-process` are documented here. This
-project adheres to [Keep a Changelog](https://keepachangelog.com/en/1.1.0/) and
-[Semantic Versioning](https://semver.org/spec/v2.0.0.html).
-
-## [1.3.4] - 2026-07-30
-
-### Fixed
-
-- **`noIndex` never used on the order processing page (`OrderProcess.tsx`).**
-  Same rationale as order-confirm - a transient, hash-gated page with no
-  search value, previously indexable by default.
-
-## [1.3.3] - 2026-07-24
-
-### Fixed
-
-- **`BKT/Bkt.tsx` was submitting a nearly-blank form to the bank.** The component reads camelCase fields (`clientId`, `orderId`, `fullName`, `postalCode`, etc.) matching the `BKTData` type, but `BKTController::make()` on the backend was returning a differently-shaped payload (raw bank field names like `clientid`, `ObtBktId`, `ShippingNameSurname`) with none of the expected keys present — every hidden input except `amount`/`description`/`rnd`/`hash`/`refreshtime` was silently `undefined`. Fixed on the obtapi side (`Prepare::$data` is now what's returned); no change needed here beyond adding the new `url` field.
-- The gateway URL was hardcoded (`https://pgw.bkt.com.al/fim/est3Dgate`) instead of read from the label's own configured BKT credentials. Now reads `data.url`, which the admin GUI already has an editable field for.
-
-## [1.3.2] - 2026-07-19
-
-### Fixed
-
-- **Payment-initiation failures no longer strand the user on a spinner.** The
-  five gateway components — `Reiffeisen/Raiffeisen.tsx`, `Stripe/Stripe.tsx`,
-  `Mollie/Mollie.tsx`, `Nexi/Nexi.tsx`, and `BKT/Bkt.tsx` — previously only
-  reacted to `isSuccess`. When the `useMake*` payment-initiation request
-  failed (gateway auth failure, no funds, etc.), the component sat on
-  "Preparing to take you to the payment portal…" indefinitely with no feedback
-  and no way out except leaving the page. Each now also consumes `isError`
-  from its query and, in an effect, calls `navigate(-1)` to return the user so
-  they can retry. No local `toast()`/`error()` is raised on purpose: the
-  `@autobusal/providers` Axios response interceptor already surfaces one toast
-  per 422/500, and adding another here stacked a duplicate.
-- **BKT loading state could never resolve on failure (`BKT/Bkt.tsx`).** Unlike
-  the other four gateways, BKT never reached an `isSuccess` state on failure —
-  `isLoading` simply stayed `true` — so it was stuck on the loading text
-  forever. The new `isError` → `navigate(-1)` handling gives it the same exit
-  path as the others.
-
-Authored by Ferjolt Ozuni. Consolidated from the magus and alvavel whitelabel
-patch sets into canonical @autobusal source (eliminates per-repo patch-package
-divergence).