@12-apps/payments-frontend 2.1.0 → 3.0.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@12-apps/payments-frontend",
-  "version": "2.1.0",
+  "version": "3.0.0",
   "type": "module",
   "description": "Browser half of the vendor-agnostic payments platform: plug-and-play MUI components for the per-provider settings page (credential form from each provider's schema, masked hints, verify/enable) and the checkout page (PIX QR + polling, card tokenization, hosted-checkout redirect), plus the headless hooks and fetch clients they build on. Talks only to the host's payments HTTP surface — never to a provider directly. Microfrontend-ready: no app coupling, host injects theme and auth.",
   "exports": {
@@ -17,7 +17,7 @@
     "storybook:build": "storybook build"
   },
   "dependencies": {
-    "@12-apps/payments-backend": "^3.1.0",
+    "@12-apps/payments-backend": "^4.0.0",
     "react-qr-code": "^2.2.0"
   },
   "peerDependencies": {

package/src/components/checkout/hosted-return.ts

@@ -31,19 +31,6 @@ import type { CheckoutOrder } from "./types";
  */
 export const HOSTED_ORDER_STORAGE_KEY = "payments.checkout.hostedOrder";
 
-/**
- * The key before the rename, READ ONLY.
- *
- * A buyer who left for the provider's page on the old bundle comes back to the
- * new one with their order parked under the old name. Without this they land on
- * the plain return screen — the order still settles, because the webhook does
- * that and never depended on any of this, but the confirmation they were
- * promised is missing for a reason they could not possibly understand.
- *
- * Delete once no session can still be mid-redirect across that deploy.
- */
-const LEGACY_KEY = "futurepay.checkout.hostedOrder";
-
 /**
  * What a hosted provider appends to the return URL. InfinitePay sends the
  * first three; Stripe's redirect-based 3-D Secure appends `payment_intent`
@@ -87,25 +74,21 @@ export function rememberHostedOrder(order: CheckoutOrder): void {
  * resumed view belongs to exactly one return.
  */
 /**
- * The raw parked payload under either key, cleared as it is read.
+ * The raw parked payload, cleared as it is read.
  *
  * Split out from {@link takeHostedOrder} so the storage handling and the
- * parsing stay separately readable — reading two keys and clearing both put the
- * combined function over the complexity gate, and the two halves fail for
- * unrelated reasons anyway (storage disabled vs. a value that is not an order).
+ * parsing stay separately readable — the two halves fail for unrelated reasons
+ * anyway (storage disabled vs. a value that is not an order).
  *
- * BOTH keys are cleared whichever one answered: this is read-and-clear, and a
- * legacy entry left behind would let a later return trip resume an order that
- * was already consumed.
+ * (This once also read a pre-rename legacy key, kept only for sessions that
+ * were mid-redirect across the deploy that renamed the storage key. A hosted
+ * round trip lasts minutes, so that window is long closed and the shim is
+ * gone.)
  */
 function takeParkedPayload(): string | null {
   try {
-    const raw =
-      window.sessionStorage?.getItem(HOSTED_ORDER_STORAGE_KEY) ??
-      window.sessionStorage?.getItem(LEGACY_KEY) ??
-      null;
+    const raw = window.sessionStorage?.getItem(HOSTED_ORDER_STORAGE_KEY) ?? null;
     window.sessionStorage?.removeItem(HOSTED_ORDER_STORAGE_KEY);
-    window.sessionStorage?.removeItem(LEGACY_KEY);
     return raw;
   } catch {
     // Storage disabled or unavailable — the same "no parked order" as an empty