fix(demos): pass the plugin explicitly when discovering gateways

[farhan-t-ottu]

Fixes the interactive Checkout SDK demo failing at the Creating session step.

Refs #159191

Root cause

CheckoutDemoInner.tsx called callPaymentMethods without a plugin, which callPaymentMethods silently defaulted to payment_request, and then created the session with type: "e_commerce". Gateways are enabled per plugin, so discovery returned gateways the session type does not accept.

Reproduced live against sandbox.ottu.net:

Payment Methods call	gateways returned
plugin: "payment_request" (what the demo sent)	14 — includes cbk-private
plugin: "e_commerce"	13 — cbk-private dropped

POST /b/checkout/v1/pymt-txn/ (type: e_commerce, 14 codes) → 400
["pg code `cbk-private` is not enabled for `e_commerce` plugin."]

With the 13-code set → 201.

Changes

• src/utils/sandbox.ts — added PaymentPlugin ("e_commerce" | "payment_request", matching the Checkout API type enum). callPaymentMethods now takes plugin as a required argument, removing the ?? "payment_request" default that hid this. CreateSessionOptions.type narrowed from string to PaymentPlugin.
• All four demos — each declares const PLUGIN once and uses it for both the Payment Methods call and the session type, so the two can no longer drift apart.
• RecurringDemo / PaymentJourney — now send the type they already displayed in their request panels. RecurringDemo was rendering type: "e_commerce" while actually sending payment_request.
• WalletDemo — dropped a || ({} as any) that widened the filter to any and would have silently defeated the new required-plugin check.

Verification

Each demo driven in the browser with a fetch recorder capturing the real request bodies:

Demo	Payment Methods	Session
CheckoutDemo	plugin: "e_commerce" → 200	201, cbk-private absent from the 13 codes
RecurringDemo	plugin: "e_commerce" → 200	201, type: "e_commerce"
PaymentJourney	plugin: "payment_request" → 200	201
WalletDemo (KSA + webhook:local)	wallet filter → 200	seed 201, session 201

npm run typecheck and npm run build both pass. Omitting plugin, a misspelled plugin, and a misspelled session type are all now compile errors.

CheckoutDemo's SDK form then shows the SDK's own "Website doesn't run on non https pages" — that is the Ottu SDK refusing plain http://localhost, raised only after both API steps succeeded. It does not occur on the deployed https site.

Note for reviewers

This will not be visible on docs.ottu.dev yet. ACTIVE_CONNECT = KSA, and that merchant has a separate failure tracked in #159192: its demo gateways span KWD/USD/SAR default currencies and Connect rejects a session mixing two foreign defaults (a missing Currency Exchange entry). This PR takes effect on main/SANDBOX, or on dev once #159192 is resolved.

🤖 Generated with Claude Code

[farhan-t-ottu]

@claude review

[claude]

Claude finished @farhan-t-ottu's task in 2m 14s —— View job

---

Claude finished reviewing this PR

• Gather context (PR body, changed files list)
• Fetch branch diff against origin/dev
• Review src/utils/sandbox.ts changes
• Review each demo component's changes (CheckoutDemo, PaymentJourney, RecurringDemo, WalletDemo)
• Post review feedback

Summary

The fix itself is sound: callPaymentMethods's plugin is now required (no more ?? "payment_request" default), each demo declares one PLUGIN/filter.plugin source of truth, and I traced every createSandboxSession/callPaymentMethods call site in CheckoutDemo, RecurringDemo, WalletDemo — all pass a type/plugin that's derived from the single constant. RecurringDemoInner.tsx's citRequest/mitRequest display objects (used for the ApiPanel preview) are also correctly wired to PLUGIN now, matching what's actually sent — the drift called out in the PR description is fixed there.

Finding

src/components/PaymentJourney/PaymentJourneyInner.tsx:554 — the Step 3 ApiPanel preview for POST /b/checkout/v1/pymt-txn/ still hardcodes type: "payment_request" instead of PLUGIN:

<ApiPanellabel="POST /b/checkout/v1/pymt-txn/"data={{type: "payment_request",// ← should be `type: PLUGIN`pg_codes: state.pgCodes,
...

The actual request at line 349 correctly sends type: PLUGIN, and the Step 1 panel at line 523 was updated to plugin: PLUGIN, but this one spot was missed. It's harmless today only because PLUGIN = "payment_request" for this file, but it's exactly the class of bug this PR is fixing — the displayed request silently drifting from what's actually sent if PLUGIN is ever changed here. Worth a one-line fix for consistency: `Fix this →

Minor observation (non-blocking)

CreateSessionOptions.type in src/utils/sandbox.ts is still optional with a silent fallback (options.type ?? "payment_request" at sandbox.ts:92), while callPaymentMethods's plugin was deliberately made required to prevent exactly this kind of silent-default bug. Every current call site does pass type explicitly, so there's no live bug, but the same footgun that caused #159191 remains available to a future demo that forgets to pass it. Consider making type required on CreateSessionOptions too, for symmetry with plugin.

Not verified

I wasn't able to run npm run typecheck / npm run build in this sandboxed environment (command execution required approval that wasn't available). The PR description states both pass; the static review above didn't surface any type errors, but this wasn't independently confirmed.

[farhan-t-ottu]

Both points addressed in 2c56101.

Finding — PaymentJourneyInner.tsx:554. Fixed; the Step 3 panel now reads type: PLUGIN. You were right that it's the exact drift this branch removes. I swept the rest of the demos for the same pattern and this was the last hardcoded occurrence — the only remaining literals are walletDemoConfig.ts (the intended single source for WalletDemo) and the sandbox.ts fallback, which is gone as of this commit.

Verified in the browser against sandbox.ottu.net: the rendered Step 3 panel shows "type": "payment_request", identical output, now sourced from the constant.

Minor observation — CreateSessionOptions.type. Taken; type is now required and the ?? "payment_request" fallback is removed. Agreed that leaving it optional kept the exact footgun that caused #159191 available on the session side. Every call site already passed type explicitly, so it was type-level only — npm run typecheck passed without touching a single call site, and omitting type is now a compile error:

error TS2345: Argument of type '{ pg_codes: string[]; }' is not assignable to parameter of type 'CreateSessionOptions'.

npm run typecheck and npm run build both pass.

[farhan-t-ottu]

@claude review again

[claude]

Claude finished @farhan-t-ottu's task in 1m 12s —— View job

---

Re-review complete ✅

• Gather context (fetch latest diff since previous review, incl. commit 2c56101)
• Re-review sandbox.ts (now-required type)
• Re-review PaymentJourneyInner.tsx fix (Step 3 panel)
• Sweep all changed files for remaining issues
• Post final review feedback

Both items from the first pass are correctly resolved in 2c56101:

1. PaymentJourneyInner.tsx:554 — the Step 3 ApiPanel preview now reads type: PLUGIN instead of the hardcoded "payment_request". Confirmed the live call at line 349 and the displayed preview now share the same source.
2. sandbox.ts — CreateSessionOptions.type is now required (type: PaymentPlugin, no more ?: ), and createSandboxSession uses options.type directly with the ?? "payment_request" fallback removed. sandbox.ts:92 no longer has a silent default.

Additional verification this pass:

• Traced every createSandboxSession() call site in the repo (Grep) — exactly the 4 demo components + sandbox.ts itself, all passing type from a single PLUGIN/filter.plugin constant. No orphaned call site was left without an explicit type.
• Swept for remaining "payment_request"/"e_commerce" string literals — only the intended single-source declarations remain: PLUGIN const in CheckoutDemoInner.tsx, RecurringDemoInner.tsx, PaymentJourneyInner.tsx, and pgFilter.plugin in walletDemoConfig.ts. No drift.
• Re-checked RecurringDemoInner.tsx's citRequest/mitRequest (one-step and two-step) display objects against their actual request bodies — both still match, sourced from PLUGIN.
• Re-checked WalletDemoInner.tsx — no || ({} as any) reintroduced; filter.plugin from WALLET_DEMO.pgFilter is used consistently for both the Payment Methods call and the session type.

No new findings. The fix is complete and internally consistent.

Not verified (same limitation as last pass): I don't have permission to execute npm run typecheck / npm run build in this sandboxed environment (command execution requires approval that isn't available here). Static review found no type errors, and the author reported both passing after this commit, including the new compile-time enforcement (error TS2345 when type is omitted) — that wasn't independently re-run.
·

[junaidsarfrazdev]

LGTM

[farhan-t-ottu]

Fixes the interactive Checkout SDK demo failing at the Creating session step.

Refs #159191

Root cause

CheckoutDemoInner.tsx called callPaymentMethods without a plugin, which callPaymentMethods silently defaulted to payment_request, and then created the session with type: "e_commerce". Gateways are enabled per plugin, so discovery returned gateways the session type does not accept.

Reproduced live against sandbox.ottu.net:

Payment Methods call	gateways returned
plugin: "payment_request" (what the demo sent)	14 — includes cbk-private
plugin: "e_commerce"	13 — cbk-private dropped

POST /b/checkout/v1/pymt-txn/ (type: e_commerce, 14 codes) → 400
["pg code `cbk-private` is not enabled for `e_commerce` plugin."]

With the 13-code set → 201.

Changes

• src/utils/sandbox.ts — added PaymentPlugin ("e_commerce" | "payment_request", matching the Checkout API type enum). callPaymentMethods now takes plugin as a required argument, removing the ?? "payment_request" default that hid this. CreateSessionOptions.type narrowed from string to PaymentPlugin.
• All four demos — each declares const PLUGIN once and uses it for both the Payment Methods call and the session type, so the two can no longer drift apart.
• RecurringDemo / PaymentJourney — now send the type they already displayed in their request panels. RecurringDemo was rendering type: "e_commerce" while actually sending payment_request.
• WalletDemo — dropped a || ({} as any) that widened the filter to any and would have silently defeated the new required-plugin check.

Verification

Each demo driven in the browser with a fetch recorder capturing the real request bodies:

Demo	Payment Methods	Session
CheckoutDemo	plugin: "e_commerce" → 200	201, cbk-private absent from the 13 codes
RecurringDemo	plugin: "e_commerce" → 200	201, type: "e_commerce"
PaymentJourney	plugin: "payment_request" → 200	201
WalletDemo (KSA + webhook:local)	wallet filter → 200	seed 201, session 201

npm run typecheck and npm run build both pass. Omitting plugin, a misspelled plugin, and a misspelled session type are all now compile errors.

CheckoutDemo's SDK form then shows the SDK's own "Website doesn't run on non https pages" — that is the Ottu SDK refusing plain http://localhost, raised only after both API steps succeeded. It does not occur on the deployed https site.

Note for reviewers

This will not be visible on docs.ottu.dev yet. ACTIVE_CONNECT = KSA, and that merchant has a separate failure tracked in #159192: its demo gateways span KWD/USD/SAR default currencies and Connect rejects a session mixing two foreign defaults (a missing Currency Exchange entry). This PR takes effect on main/SANDBOX, or on dev once #159192 is resolved.

🤖 Generated with Claude Code

[farhan-t-ottu]

@claude review

[claude]

Claude finished @farhan-t-ottu's task in 2m 14s —— View job

---

Claude finished reviewing this PR

• Gather context (PR body, changed files list)
• Fetch branch diff against origin/dev
• Review src/utils/sandbox.ts changes
• Review each demo component's changes (CheckoutDemo, PaymentJourney, RecurringDemo, WalletDemo)
• Post review feedback

Summary

The fix itself is sound: callPaymentMethods's plugin is now required (no more ?? "payment_request" default), each demo declares one PLUGIN/filter.plugin source of truth, and I traced every createSandboxSession/callPaymentMethods call site in CheckoutDemo, RecurringDemo, WalletDemo — all pass a type/plugin that's derived from the single constant. RecurringDemoInner.tsx's citRequest/mitRequest display objects (used for the ApiPanel preview) are also correctly wired to PLUGIN now, matching what's actually sent — the drift called out in the PR description is fixed there.

Finding

src/components/PaymentJourney/PaymentJourneyInner.tsx:554 — the Step 3 ApiPanel preview for POST /b/checkout/v1/pymt-txn/ still hardcodes type: "payment_request" instead of PLUGIN:

<ApiPanellabel="POST /b/checkout/v1/pymt-txn/"data={{type: "payment_request",// ← should be `type: PLUGIN`pg_codes: state.pgCodes,
...

The actual request at line 349 correctly sends type: PLUGIN, and the Step 1 panel at line 523 was updated to plugin: PLUGIN, but this one spot was missed. It's harmless today only because PLUGIN = "payment_request" for this file, but it's exactly the class of bug this PR is fixing — the displayed request silently drifting from what's actually sent if PLUGIN is ever changed here. Worth a one-line fix for consistency: `Fix this →

Minor observation (non-blocking)

CreateSessionOptions.type in src/utils/sandbox.ts is still optional with a silent fallback (options.type ?? "payment_request" at sandbox.ts:92), while callPaymentMethods's plugin was deliberately made required to prevent exactly this kind of silent-default bug. Every current call site does pass type explicitly, so there's no live bug, but the same footgun that caused #159191 remains available to a future demo that forgets to pass it. Consider making type required on CreateSessionOptions too, for symmetry with plugin.

Not verified

I wasn't able to run npm run typecheck / npm run build in this sandboxed environment (command execution required approval that wasn't available). The PR description states both pass; the static review above didn't surface any type errors, but this wasn't independently confirmed.

[farhan-t-ottu]

Both points addressed in 2c56101.

Finding — PaymentJourneyInner.tsx:554. Fixed; the Step 3 panel now reads type: PLUGIN. You were right that it's the exact drift this branch removes. I swept the rest of the demos for the same pattern and this was the last hardcoded occurrence — the only remaining literals are walletDemoConfig.ts (the intended single source for WalletDemo) and the sandbox.ts fallback, which is gone as of this commit.

Verified in the browser against sandbox.ottu.net: the rendered Step 3 panel shows "type": "payment_request", identical output, now sourced from the constant.

Minor observation — CreateSessionOptions.type. Taken; type is now required and the ?? "payment_request" fallback is removed. Agreed that leaving it optional kept the exact footgun that caused #159191 available on the session side. Every call site already passed type explicitly, so it was type-level only — npm run typecheck passed without touching a single call site, and omitting type is now a compile error:

error TS2345: Argument of type '{ pg_codes: string[]; }' is not assignable to parameter of type 'CreateSessionOptions'.

npm run typecheck and npm run build both pass.

[farhan-t-ottu]

@claude review again

[claude]

Claude finished @farhan-t-ottu's task in 1m 12s —— View job

---

Re-review complete ✅

• Gather context (fetch latest diff since previous review, incl. commit 2c56101)
• Re-review sandbox.ts (now-required type)
• Re-review PaymentJourneyInner.tsx fix (Step 3 panel)
• Sweep all changed files for remaining issues
• Post final review feedback

Both items from the first pass are correctly resolved in 2c56101:

1. PaymentJourneyInner.tsx:554 — the Step 3 ApiPanel preview now reads type: PLUGIN instead of the hardcoded "payment_request". Confirmed the live call at line 349 and the displayed preview now share the same source.
2. sandbox.ts — CreateSessionOptions.type is now required (type: PaymentPlugin, no more ?: ), and createSandboxSession uses options.type directly with the ?? "payment_request" fallback removed. sandbox.ts:92 no longer has a silent default.

Additional verification this pass:

• Traced every createSandboxSession() call site in the repo (Grep) — exactly the 4 demo components + sandbox.ts itself, all passing type from a single PLUGIN/filter.plugin constant. No orphaned call site was left without an explicit type.
• Swept for remaining "payment_request"/"e_commerce" string literals — only the intended single-source declarations remain: PLUGIN const in CheckoutDemoInner.tsx, RecurringDemoInner.tsx, PaymentJourneyInner.tsx, and pgFilter.plugin in walletDemoConfig.ts. No drift.
• Re-checked RecurringDemoInner.tsx's citRequest/mitRequest (one-step and two-step) display objects against their actual request bodies — both still match, sourced from PLUGIN.
• Re-checked WalletDemoInner.tsx — no || ({} as any) reintroduced; filter.plugin from WALLET_DEMO.pgFilter is used consistently for both the Payment Methods call and the session type.

No new findings. The fix is complete and internally consistent.

Not verified (same limitation as last pass): I don't have permission to execute npm run typecheck / npm run build in this sandboxed environment (command execution requires approval that isn't available here). Static review found no type errors, and the author reported both passing after this commit, including the new compile-time enforcement (error TS2345 when type is omitted) — that wasn't independently re-run.
·

[junaidsarfrazdev]

LGTM

[farhan-t-ottu]

Fixes the interactive Checkout SDK demo failing at the Creating session step.

Refs #159191

Root cause

CheckoutDemoInner.tsx called callPaymentMethods without a plugin, which callPaymentMethods silently defaulted to payment_request, and then created the session with type: "e_commerce". Gateways are enabled per plugin, so discovery returned gateways the session type does not accept.

Reproduced live against sandbox.ottu.net:

Payment Methods call	gateways returned
plugin: "payment_request" (what the demo sent)	14 — includes cbk-private
plugin: "e_commerce"	13 — cbk-private dropped

POST /b/checkout/v1/pymt-txn/ (type: e_commerce, 14 codes) → 400
["pg code `cbk-private` is not enabled for `e_commerce` plugin."]

With the 13-code set → 201.

Changes

• src/utils/sandbox.ts — added PaymentPlugin ("e_commerce" | "payment_request", matching the Checkout API type enum). callPaymentMethods now takes plugin as a required argument, removing the ?? "payment_request" default that hid this. CreateSessionOptions.type narrowed from string to PaymentPlugin.
• All four demos — each declares const PLUGIN once and uses it for both the Payment Methods call and the session type, so the two can no longer drift apart.
• RecurringDemo / PaymentJourney — now send the type they already displayed in their request panels. RecurringDemo was rendering type: "e_commerce" while actually sending payment_request.
• WalletDemo — dropped a || ({} as any) that widened the filter to any and would have silently defeated the new required-plugin check.

Verification

Each demo driven in the browser with a fetch recorder capturing the real request bodies:

Demo	Payment Methods	Session
CheckoutDemo	plugin: "e_commerce" → 200	201, cbk-private absent from the 13 codes
RecurringDemo	plugin: "e_commerce" → 200	201, type: "e_commerce"
PaymentJourney	plugin: "payment_request" → 200	201
WalletDemo (KSA + webhook:local)	wallet filter → 200	seed 201, session 201

npm run typecheck and npm run build both pass. Omitting plugin, a misspelled plugin, and a misspelled session type are all now compile errors.

CheckoutDemo's SDK form then shows the SDK's own "Website doesn't run on non https pages" — that is the Ottu SDK refusing plain http://localhost, raised only after both API steps succeeded. It does not occur on the deployed https site.

Note for reviewers

This will not be visible on docs.ottu.dev yet. ACTIVE_CONNECT = KSA, and that merchant has a separate failure tracked in #159192: its demo gateways span KWD/USD/SAR default currencies and Connect rejects a session mixing two foreign defaults (a missing Currency Exchange entry). This PR takes effect on main/SANDBOX, or on dev once #159192 is resolved.

🤖 Generated with Claude Code

[farhan-t-ottu]

@claude review

[claude]

Claude finished @farhan-t-ottu's task in 2m 14s —— View job

---

Claude finished reviewing this PR

• Gather context (PR body, changed files list)
• Fetch branch diff against origin/dev
• Review src/utils/sandbox.ts changes
• Review each demo component's changes (CheckoutDemo, PaymentJourney, RecurringDemo, WalletDemo)
• Post review feedback

Summary

The fix itself is sound: callPaymentMethods's plugin is now required (no more ?? "payment_request" default), each demo declares one PLUGIN/filter.plugin source of truth, and I traced every createSandboxSession/callPaymentMethods call site in CheckoutDemo, RecurringDemo, WalletDemo — all pass a type/plugin that's derived from the single constant. RecurringDemoInner.tsx's citRequest/mitRequest display objects (used for the ApiPanel preview) are also correctly wired to PLUGIN now, matching what's actually sent — the drift called out in the PR description is fixed there.

Finding

src/components/PaymentJourney/PaymentJourneyInner.tsx:554 — the Step 3 ApiPanel preview for POST /b/checkout/v1/pymt-txn/ still hardcodes type: "payment_request" instead of PLUGIN:

<ApiPanellabel="POST /b/checkout/v1/pymt-txn/"data={{type: "payment_request",// ← should be `type: PLUGIN`pg_codes: state.pgCodes,
...

The actual request at line 349 correctly sends type: PLUGIN, and the Step 1 panel at line 523 was updated to plugin: PLUGIN, but this one spot was missed. It's harmless today only because PLUGIN = "payment_request" for this file, but it's exactly the class of bug this PR is fixing — the displayed request silently drifting from what's actually sent if PLUGIN is ever changed here. Worth a one-line fix for consistency: `Fix this →

Minor observation (non-blocking)

CreateSessionOptions.type in src/utils/sandbox.ts is still optional with a silent fallback (options.type ?? "payment_request" at sandbox.ts:92), while callPaymentMethods's plugin was deliberately made required to prevent exactly this kind of silent-default bug. Every current call site does pass type explicitly, so there's no live bug, but the same footgun that caused #159191 remains available to a future demo that forgets to pass it. Consider making type required on CreateSessionOptions too, for symmetry with plugin.

Not verified

I wasn't able to run npm run typecheck / npm run build in this sandboxed environment (command execution required approval that wasn't available). The PR description states both pass; the static review above didn't surface any type errors, but this wasn't independently confirmed.

[farhan-t-ottu]

Both points addressed in 2c56101.

Finding — PaymentJourneyInner.tsx:554. Fixed; the Step 3 panel now reads type: PLUGIN. You were right that it's the exact drift this branch removes. I swept the rest of the demos for the same pattern and this was the last hardcoded occurrence — the only remaining literals are walletDemoConfig.ts (the intended single source for WalletDemo) and the sandbox.ts fallback, which is gone as of this commit.

Verified in the browser against sandbox.ottu.net: the rendered Step 3 panel shows "type": "payment_request", identical output, now sourced from the constant.

Minor observation — CreateSessionOptions.type. Taken; type is now required and the ?? "payment_request" fallback is removed. Agreed that leaving it optional kept the exact footgun that caused #159191 available on the session side. Every call site already passed type explicitly, so it was type-level only — npm run typecheck passed without touching a single call site, and omitting type is now a compile error:

error TS2345: Argument of type '{ pg_codes: string[]; }' is not assignable to parameter of type 'CreateSessionOptions'.

npm run typecheck and npm run build both pass.

[farhan-t-ottu]

@claude review again

[claude]

Claude finished @farhan-t-ottu's task in 1m 12s —— View job

---

Re-review complete ✅

• Gather context (fetch latest diff since previous review, incl. commit 2c56101)
• Re-review sandbox.ts (now-required type)
• Re-review PaymentJourneyInner.tsx fix (Step 3 panel)
• Sweep all changed files for remaining issues
• Post final review feedback

Both items from the first pass are correctly resolved in 2c56101:

1. PaymentJourneyInner.tsx:554 — the Step 3 ApiPanel preview now reads type: PLUGIN instead of the hardcoded "payment_request". Confirmed the live call at line 349 and the displayed preview now share the same source.
2. sandbox.ts — CreateSessionOptions.type is now required (type: PaymentPlugin, no more ?: ), and createSandboxSession uses options.type directly with the ?? "payment_request" fallback removed. sandbox.ts:92 no longer has a silent default.

Additional verification this pass:

• Traced every createSandboxSession() call site in the repo (Grep) — exactly the 4 demo components + sandbox.ts itself, all passing type from a single PLUGIN/filter.plugin constant. No orphaned call site was left without an explicit type.
• Swept for remaining "payment_request"/"e_commerce" string literals — only the intended single-source declarations remain: PLUGIN const in CheckoutDemoInner.tsx, RecurringDemoInner.tsx, PaymentJourneyInner.tsx, and pgFilter.plugin in walletDemoConfig.ts. No drift.
• Re-checked RecurringDemoInner.tsx's citRequest/mitRequest (one-step and two-step) display objects against their actual request bodies — both still match, sourced from PLUGIN.
• Re-checked WalletDemoInner.tsx — no || ({} as any) reintroduced; filter.plugin from WALLET_DEMO.pgFilter is used consistently for both the Payment Methods call and the session type.

No new findings. The fix is complete and internally consistent.

Not verified (same limitation as last pass): I don't have permission to execute npm run typecheck / npm run build in this sandboxed environment (command execution requires approval that isn't available here). Static review found no type errors, and the author reported both passing after this commit, including the new compile-time enforcement (error TS2345 when type is omitted) — that wasn't independently re-run.
·

[junaidsarfrazdev]

LGTM

[farhan-t-ottu]

Fixes the interactive Checkout SDK demo failing at the Creating session step.

Refs #159191

Root cause

CheckoutDemoInner.tsx called callPaymentMethods without a plugin, which callPaymentMethods silently defaulted to payment_request, and then created the session with type: "e_commerce". Gateways are enabled per plugin, so discovery returned gateways the session type does not accept.

Reproduced live against sandbox.ottu.net:

Payment Methods call	gateways returned
plugin: "payment_request" (what the demo sent)	14 — includes cbk-private
plugin: "e_commerce"	13 — cbk-private dropped

POST /b/checkout/v1/pymt-txn/ (type: e_commerce, 14 codes) → 400
["pg code `cbk-private` is not enabled for `e_commerce` plugin."]

With the 13-code set → 201.

Changes

• src/utils/sandbox.ts — added PaymentPlugin ("e_commerce" | "payment_request", matching the Checkout API type enum). callPaymentMethods now takes plugin as a required argument, removing the ?? "payment_request" default that hid this. CreateSessionOptions.type narrowed from string to PaymentPlugin.
• All four demos — each declares const PLUGIN once and uses it for both the Payment Methods call and the session type, so the two can no longer drift apart.
• RecurringDemo / PaymentJourney — now send the type they already displayed in their request panels. RecurringDemo was rendering type: "e_commerce" while actually sending payment_request.
• WalletDemo — dropped a || ({} as any) that widened the filter to any and would have silently defeated the new required-plugin check.

Verification

Each demo driven in the browser with a fetch recorder capturing the real request bodies:

Demo	Payment Methods	Session
CheckoutDemo	plugin: "e_commerce" → 200	201, cbk-private absent from the 13 codes
RecurringDemo	plugin: "e_commerce" → 200	201, type: "e_commerce"
PaymentJourney	plugin: "payment_request" → 200	201
WalletDemo (KSA + webhook:local)	wallet filter → 200	seed 201, session 201

npm run typecheck and npm run build both pass. Omitting plugin, a misspelled plugin, and a misspelled session type are all now compile errors.

CheckoutDemo's SDK form then shows the SDK's own "Website doesn't run on non https pages" — that is the Ottu SDK refusing plain http://localhost, raised only after both API steps succeeded. It does not occur on the deployed https site.

Note for reviewers

This will not be visible on docs.ottu.dev yet. ACTIVE_CONNECT = KSA, and that merchant has a separate failure tracked in #159192: its demo gateways span KWD/USD/SAR default currencies and Connect rejects a session mixing two foreign defaults (a missing Currency Exchange entry). This PR takes effect on main/SANDBOX, or on dev once #159192 is resolved.

🤖 Generated with Claude Code

[farhan-t-ottu]

@claude review

[claude]

Claude finished @farhan-t-ottu's task in 2m 14s —— View job

---

Claude finished reviewing this PR

• Gather context (PR body, changed files list)
• Fetch branch diff against origin/dev
• Review src/utils/sandbox.ts changes
• Review each demo component's changes (CheckoutDemo, PaymentJourney, RecurringDemo, WalletDemo)
• Post review feedback

Summary

The fix itself is sound: callPaymentMethods's plugin is now required (no more ?? "payment_request" default), each demo declares one PLUGIN/filter.plugin source of truth, and I traced every createSandboxSession/callPaymentMethods call site in CheckoutDemo, RecurringDemo, WalletDemo — all pass a type/plugin that's derived from the single constant. RecurringDemoInner.tsx's citRequest/mitRequest display objects (used for the ApiPanel preview) are also correctly wired to PLUGIN now, matching what's actually sent — the drift called out in the PR description is fixed there.

Finding

src/components/PaymentJourney/PaymentJourneyInner.tsx:554 — the Step 3 ApiPanel preview for POST /b/checkout/v1/pymt-txn/ still hardcodes type: "payment_request" instead of PLUGIN:

<ApiPanellabel="POST /b/checkout/v1/pymt-txn/"data={{type: "payment_request",// ← should be `type: PLUGIN`pg_codes: state.pgCodes,
...

The actual request at line 349 correctly sends type: PLUGIN, and the Step 1 panel at line 523 was updated to plugin: PLUGIN, but this one spot was missed. It's harmless today only because PLUGIN = "payment_request" for this file, but it's exactly the class of bug this PR is fixing — the displayed request silently drifting from what's actually sent if PLUGIN is ever changed here. Worth a one-line fix for consistency: `Fix this →

Minor observation (non-blocking)

CreateSessionOptions.type in src/utils/sandbox.ts is still optional with a silent fallback (options.type ?? "payment_request" at sandbox.ts:92), while callPaymentMethods's plugin was deliberately made required to prevent exactly this kind of silent-default bug. Every current call site does pass type explicitly, so there's no live bug, but the same footgun that caused #159191 remains available to a future demo that forgets to pass it. Consider making type required on CreateSessionOptions too, for symmetry with plugin.

Not verified

I wasn't able to run npm run typecheck / npm run build in this sandboxed environment (command execution required approval that wasn't available). The PR description states both pass; the static review above didn't surface any type errors, but this wasn't independently confirmed.

[farhan-t-ottu]

Both points addressed in 2c56101.

Finding — PaymentJourneyInner.tsx:554. Fixed; the Step 3 panel now reads type: PLUGIN. You were right that it's the exact drift this branch removes. I swept the rest of the demos for the same pattern and this was the last hardcoded occurrence — the only remaining literals are walletDemoConfig.ts (the intended single source for WalletDemo) and the sandbox.ts fallback, which is gone as of this commit.

Verified in the browser against sandbox.ottu.net: the rendered Step 3 panel shows "type": "payment_request", identical output, now sourced from the constant.

Minor observation — CreateSessionOptions.type. Taken; type is now required and the ?? "payment_request" fallback is removed. Agreed that leaving it optional kept the exact footgun that caused #159191 available on the session side. Every call site already passed type explicitly, so it was type-level only — npm run typecheck passed without touching a single call site, and omitting type is now a compile error:

error TS2345: Argument of type '{ pg_codes: string[]; }' is not assignable to parameter of type 'CreateSessionOptions'.

npm run typecheck and npm run build both pass.

[farhan-t-ottu]

@claude review again

[claude]

Claude finished @farhan-t-ottu's task in 1m 12s —— View job

---

Re-review complete ✅

• Gather context (fetch latest diff since previous review, incl. commit 2c56101)
• Re-review sandbox.ts (now-required type)
• Re-review PaymentJourneyInner.tsx fix (Step 3 panel)
• Sweep all changed files for remaining issues
• Post final review feedback

Both items from the first pass are correctly resolved in 2c56101:

1. PaymentJourneyInner.tsx:554 — the Step 3 ApiPanel preview now reads type: PLUGIN instead of the hardcoded "payment_request". Confirmed the live call at line 349 and the displayed preview now share the same source.
2. sandbox.ts — CreateSessionOptions.type is now required (type: PaymentPlugin, no more ?: ), and createSandboxSession uses options.type directly with the ?? "payment_request" fallback removed. sandbox.ts:92 no longer has a silent default.

Additional verification this pass:

• Traced every createSandboxSession() call site in the repo (Grep) — exactly the 4 demo components + sandbox.ts itself, all passing type from a single PLUGIN/filter.plugin constant. No orphaned call site was left without an explicit type.
• Swept for remaining "payment_request"/"e_commerce" string literals — only the intended single-source declarations remain: PLUGIN const in CheckoutDemoInner.tsx, RecurringDemoInner.tsx, PaymentJourneyInner.tsx, and pgFilter.plugin in walletDemoConfig.ts. No drift.
• Re-checked RecurringDemoInner.tsx's citRequest/mitRequest (one-step and two-step) display objects against their actual request bodies — both still match, sourced from PLUGIN.
• Re-checked WalletDemoInner.tsx — no || ({} as any) reintroduced; filter.plugin from WALLET_DEMO.pgFilter is used consistently for both the Payment Methods call and the session type.

No new findings. The fix is complete and internally consistent.

Not verified (same limitation as last pass): I don't have permission to execute npm run typecheck / npm run build in this sandboxed environment (command execution requires approval that isn't available here). Static review found no type errors, and the author reported both passing after this commit, including the new compile-time enforcement (error TS2345 when type is omitted) — that wasn't independently re-run.
·

[junaidsarfrazdev]

LGTM

[farhan-t-ottu]

Fixes the interactive Checkout SDK demo failing at the Creating session step.

Refs #159191

Root cause

CheckoutDemoInner.tsx called callPaymentMethods without a plugin, which callPaymentMethods silently defaulted to payment_request, and then created the session with type: "e_commerce". Gateways are enabled per plugin, so discovery returned gateways the session type does not accept.

Reproduced live against sandbox.ottu.net:

Payment Methods call	gateways returned
plugin: "payment_request" (what the demo sent)	14 — includes cbk-private
plugin: "e_commerce"	13 — cbk-private dropped

POST /b/checkout/v1/pymt-txn/ (type: e_commerce, 14 codes) → 400
["pg code `cbk-private` is not enabled for `e_commerce` plugin."]

With the 13-code set → 201.

Changes

• src/utils/sandbox.ts — added PaymentPlugin ("e_commerce" | "payment_request", matching the Checkout API type enum). callPaymentMethods now takes plugin as a required argument, removing the ?? "payment_request" default that hid this. CreateSessionOptions.type narrowed from string to PaymentPlugin.
• All four demos — each declares const PLUGIN once and uses it for both the Payment Methods call and the session type, so the two can no longer drift apart.
• RecurringDemo / PaymentJourney — now send the type they already displayed in their request panels. RecurringDemo was rendering type: "e_commerce" while actually sending payment_request.
• WalletDemo — dropped a || ({} as any) that widened the filter to any and would have silently defeated the new required-plugin check.

Verification

Each demo driven in the browser with a fetch recorder capturing the real request bodies:

Demo	Payment Methods	Session
CheckoutDemo	plugin: "e_commerce" → 200	201, cbk-private absent from the 13 codes
RecurringDemo	plugin: "e_commerce" → 200	201, type: "e_commerce"
PaymentJourney	plugin: "payment_request" → 200	201
WalletDemo (KSA + webhook:local)	wallet filter → 200	seed 201, session 201

npm run typecheck and npm run build both pass. Omitting plugin, a misspelled plugin, and a misspelled session type are all now compile errors.

CheckoutDemo's SDK form then shows the SDK's own "Website doesn't run on non https pages" — that is the Ottu SDK refusing plain http://localhost, raised only after both API steps succeeded. It does not occur on the deployed https site.

Note for reviewers

This will not be visible on docs.ottu.dev yet. ACTIVE_CONNECT = KSA, and that merchant has a separate failure tracked in #159192: its demo gateways span KWD/USD/SAR default currencies and Connect rejects a session mixing two foreign defaults (a missing Currency Exchange entry). This PR takes effect on main/SANDBOX, or on dev once #159192 is resolved.

🤖 Generated with Claude Code

[farhan-t-ottu]

@claude review

[claude]

Claude finished @farhan-t-ottu's task in 2m 14s —— View job

---

Claude finished reviewing this PR

• Gather context (PR body, changed files list)
• Fetch branch diff against origin/dev
• Review src/utils/sandbox.ts changes
• Review each demo component's changes (CheckoutDemo, PaymentJourney, RecurringDemo, WalletDemo)
• Post review feedback

Summary

The fix itself is sound: callPaymentMethods's plugin is now required (no more ?? "payment_request" default), each demo declares one PLUGIN/filter.plugin source of truth, and I traced every createSandboxSession/callPaymentMethods call site in CheckoutDemo, RecurringDemo, WalletDemo — all pass a type/plugin that's derived from the single constant. RecurringDemoInner.tsx's citRequest/mitRequest display objects (used for the ApiPanel preview) are also correctly wired to PLUGIN now, matching what's actually sent — the drift called out in the PR description is fixed there.

Finding

src/components/PaymentJourney/PaymentJourneyInner.tsx:554 — the Step 3 ApiPanel preview for POST /b/checkout/v1/pymt-txn/ still hardcodes type: "payment_request" instead of PLUGIN:

<ApiPanellabel="POST /b/checkout/v1/pymt-txn/"data={{type: "payment_request",// ← should be `type: PLUGIN`pg_codes: state.pgCodes,
...

The actual request at line 349 correctly sends type: PLUGIN, and the Step 1 panel at line 523 was updated to plugin: PLUGIN, but this one spot was missed. It's harmless today only because PLUGIN = "payment_request" for this file, but it's exactly the class of bug this PR is fixing — the displayed request silently drifting from what's actually sent if PLUGIN is ever changed here. Worth a one-line fix for consistency: `Fix this →

Minor observation (non-blocking)

CreateSessionOptions.type in src/utils/sandbox.ts is still optional with a silent fallback (options.type ?? "payment_request" at sandbox.ts:92), while callPaymentMethods's plugin was deliberately made required to prevent exactly this kind of silent-default bug. Every current call site does pass type explicitly, so there's no live bug, but the same footgun that caused #159191 remains available to a future demo that forgets to pass it. Consider making type required on CreateSessionOptions too, for symmetry with plugin.

Not verified

I wasn't able to run npm run typecheck / npm run build in this sandboxed environment (command execution required approval that wasn't available). The PR description states both pass; the static review above didn't surface any type errors, but this wasn't independently confirmed.

[farhan-t-ottu]

Both points addressed in 2c56101.

Finding — PaymentJourneyInner.tsx:554. Fixed; the Step 3 panel now reads type: PLUGIN. You were right that it's the exact drift this branch removes. I swept the rest of the demos for the same pattern and this was the last hardcoded occurrence — the only remaining literals are walletDemoConfig.ts (the intended single source for WalletDemo) and the sandbox.ts fallback, which is gone as of this commit.

Verified in the browser against sandbox.ottu.net: the rendered Step 3 panel shows "type": "payment_request", identical output, now sourced from the constant.

Minor observation — CreateSessionOptions.type. Taken; type is now required and the ?? "payment_request" fallback is removed. Agreed that leaving it optional kept the exact footgun that caused #159191 available on the session side. Every call site already passed type explicitly, so it was type-level only — npm run typecheck passed without touching a single call site, and omitting type is now a compile error:

error TS2345: Argument of type '{ pg_codes: string[]; }' is not assignable to parameter of type 'CreateSessionOptions'.

npm run typecheck and npm run build both pass.

[farhan-t-ottu]

@claude review again

[claude]

Claude finished @farhan-t-ottu's task in 1m 12s —— View job

---

Re-review complete ✅

• Gather context (fetch latest diff since previous review, incl. commit 2c56101)
• Re-review sandbox.ts (now-required type)
• Re-review PaymentJourneyInner.tsx fix (Step 3 panel)
• Sweep all changed files for remaining issues
• Post final review feedback

Both items from the first pass are correctly resolved in 2c56101:

1. PaymentJourneyInner.tsx:554 — the Step 3 ApiPanel preview now reads type: PLUGIN instead of the hardcoded "payment_request". Confirmed the live call at line 349 and the displayed preview now share the same source.
2. sandbox.ts — CreateSessionOptions.type is now required (type: PaymentPlugin, no more ?: ), and createSandboxSession uses options.type directly with the ?? "payment_request" fallback removed. sandbox.ts:92 no longer has a silent default.

Additional verification this pass:

• Traced every createSandboxSession() call site in the repo (Grep) — exactly the 4 demo components + sandbox.ts itself, all passing type from a single PLUGIN/filter.plugin constant. No orphaned call site was left without an explicit type.
• Swept for remaining "payment_request"/"e_commerce" string literals — only the intended single-source declarations remain: PLUGIN const in CheckoutDemoInner.tsx, RecurringDemoInner.tsx, PaymentJourneyInner.tsx, and pgFilter.plugin in walletDemoConfig.ts. No drift.
• Re-checked RecurringDemoInner.tsx's citRequest/mitRequest (one-step and two-step) display objects against their actual request bodies — both still match, sourced from PLUGIN.
• Re-checked WalletDemoInner.tsx — no || ({} as any) reintroduced; filter.plugin from WALLET_DEMO.pgFilter is used consistently for both the Payment Methods call and the session type.

No new findings. The fix is complete and internally consistent.

Not verified (same limitation as last pass): I don't have permission to execute npm run typecheck / npm run build in this sandboxed environment (command execution requires approval that isn't available here). Static review found no type errors, and the author reported both passing after this commit, including the new compile-time enforcement (error TS2345 when type is omitted) — that wasn't independently re-run.
·

[junaidsarfrazdev]

LGTM

[farhan-t-ottu]

Fixes the interactive Checkout SDK demo failing at the Creating session step.

Refs #159191

Root cause

CheckoutDemoInner.tsx called callPaymentMethods without a plugin, which callPaymentMethods silently defaulted to payment_request, and then created the session with type: "e_commerce". Gateways are enabled per plugin, so discovery returned gateways the session type does not accept.

Reproduced live against sandbox.ottu.net:

Payment Methods call	gateways returned
plugin: "payment_request" (what the demo sent)	14 — includes cbk-private
plugin: "e_commerce"	13 — cbk-private dropped

POST /b/checkout/v1/pymt-txn/ (type: e_commerce, 14 codes) → 400
["pg code `cbk-private` is not enabled for `e_commerce` plugin."]

With the 13-code set → 201.

Changes

• src/utils/sandbox.ts — added PaymentPlugin ("e_commerce" | "payment_request", matching the Checkout API type enum). callPaymentMethods now takes plugin as a required argument, removing the ?? "payment_request" default that hid this. CreateSessionOptions.type narrowed from string to PaymentPlugin.
• All four demos — each declares const PLUGIN once and uses it for both the Payment Methods call and the session type, so the two can no longer drift apart.
• RecurringDemo / PaymentJourney — now send the type they already displayed in their request panels. RecurringDemo was rendering type: "e_commerce" while actually sending payment_request.
• WalletDemo — dropped a || ({} as any) that widened the filter to any and would have silently defeated the new required-plugin check.

Verification

Each demo driven in the browser with a fetch recorder capturing the real request bodies:

Demo	Payment Methods	Session
CheckoutDemo	plugin: "e_commerce" → 200	201, cbk-private absent from the 13 codes
RecurringDemo	plugin: "e_commerce" → 200	201, type: "e_commerce"
PaymentJourney	plugin: "payment_request" → 200	201
WalletDemo (KSA + webhook:local)	wallet filter → 200	seed 201, session 201

npm run typecheck and npm run build both pass. Omitting plugin, a misspelled plugin, and a misspelled session type are all now compile errors.

CheckoutDemo's SDK form then shows the SDK's own "Website doesn't run on non https pages" — that is the Ottu SDK refusing plain http://localhost, raised only after both API steps succeeded. It does not occur on the deployed https site.

Note for reviewers

This will not be visible on docs.ottu.dev yet. ACTIVE_CONNECT = KSA, and that merchant has a separate failure tracked in #159192: its demo gateways span KWD/USD/SAR default currencies and Connect rejects a session mixing two foreign defaults (a missing Currency Exchange entry). This PR takes effect on main/SANDBOX, or on dev once #159192 is resolved.

🤖 Generated with Claude Code

[farhan-t-ottu]

@claude review

[claude]

Claude finished @farhan-t-ottu's task in 2m 14s —— View job

---

Claude finished reviewing this PR

• Gather context (PR body, changed files list)
• Fetch branch diff against origin/dev
• Review src/utils/sandbox.ts changes
• Review each demo component's changes (CheckoutDemo, PaymentJourney, RecurringDemo, WalletDemo)
• Post review feedback

Summary

The fix itself is sound: callPaymentMethods's plugin is now required (no more ?? "payment_request" default), each demo declares one PLUGIN/filter.plugin source of truth, and I traced every createSandboxSession/callPaymentMethods call site in CheckoutDemo, RecurringDemo, WalletDemo — all pass a type/plugin that's derived from the single constant. RecurringDemoInner.tsx's citRequest/mitRequest display objects (used for the ApiPanel preview) are also correctly wired to PLUGIN now, matching what's actually sent — the drift called out in the PR description is fixed there.

Finding

src/components/PaymentJourney/PaymentJourneyInner.tsx:554 — the Step 3 ApiPanel preview for POST /b/checkout/v1/pymt-txn/ still hardcodes type: "payment_request" instead of PLUGIN:

<ApiPanellabel="POST /b/checkout/v1/pymt-txn/"data={{type: "payment_request",// ← should be `type: PLUGIN`pg_codes: state.pgCodes,
...

The actual request at line 349 correctly sends type: PLUGIN, and the Step 1 panel at line 523 was updated to plugin: PLUGIN, but this one spot was missed. It's harmless today only because PLUGIN = "payment_request" for this file, but it's exactly the class of bug this PR is fixing — the displayed request silently drifting from what's actually sent if PLUGIN is ever changed here. Worth a one-line fix for consistency: `Fix this →

Minor observation (non-blocking)

CreateSessionOptions.type in src/utils/sandbox.ts is still optional with a silent fallback (options.type ?? "payment_request" at sandbox.ts:92), while callPaymentMethods's plugin was deliberately made required to prevent exactly this kind of silent-default bug. Every current call site does pass type explicitly, so there's no live bug, but the same footgun that caused #159191 remains available to a future demo that forgets to pass it. Consider making type required on CreateSessionOptions too, for symmetry with plugin.

Not verified

I wasn't able to run npm run typecheck / npm run build in this sandboxed environment (command execution required approval that wasn't available). The PR description states both pass; the static review above didn't surface any type errors, but this wasn't independently confirmed.

[farhan-t-ottu]

Both points addressed in 2c56101.

Finding — PaymentJourneyInner.tsx:554. Fixed; the Step 3 panel now reads type: PLUGIN. You were right that it's the exact drift this branch removes. I swept the rest of the demos for the same pattern and this was the last hardcoded occurrence — the only remaining literals are walletDemoConfig.ts (the intended single source for WalletDemo) and the sandbox.ts fallback, which is gone as of this commit.

Verified in the browser against sandbox.ottu.net: the rendered Step 3 panel shows "type": "payment_request", identical output, now sourced from the constant.

Minor observation — CreateSessionOptions.type. Taken; type is now required and the ?? "payment_request" fallback is removed. Agreed that leaving it optional kept the exact footgun that caused #159191 available on the session side. Every call site already passed type explicitly, so it was type-level only — npm run typecheck passed without touching a single call site, and omitting type is now a compile error:

error TS2345: Argument of type '{ pg_codes: string[]; }' is not assignable to parameter of type 'CreateSessionOptions'.

npm run typecheck and npm run build both pass.

[farhan-t-ottu]

@claude review again

[claude]

Claude finished @farhan-t-ottu's task in 1m 12s —— View job

---

Re-review complete ✅

• Gather context (fetch latest diff since previous review, incl. commit 2c56101)
• Re-review sandbox.ts (now-required type)
• Re-review PaymentJourneyInner.tsx fix (Step 3 panel)
• Sweep all changed files for remaining issues
• Post final review feedback

Both items from the first pass are correctly resolved in 2c56101:

1. PaymentJourneyInner.tsx:554 — the Step 3 ApiPanel preview now reads type: PLUGIN instead of the hardcoded "payment_request". Confirmed the live call at line 349 and the displayed preview now share the same source.
2. sandbox.ts — CreateSessionOptions.type is now required (type: PaymentPlugin, no more ?: ), and createSandboxSession uses options.type directly with the ?? "payment_request" fallback removed. sandbox.ts:92 no longer has a silent default.

Additional verification this pass:

• Traced every createSandboxSession() call site in the repo (Grep) — exactly the 4 demo components + sandbox.ts itself, all passing type from a single PLUGIN/filter.plugin constant. No orphaned call site was left without an explicit type.
• Swept for remaining "payment_request"/"e_commerce" string literals — only the intended single-source declarations remain: PLUGIN const in CheckoutDemoInner.tsx, RecurringDemoInner.tsx, PaymentJourneyInner.tsx, and pgFilter.plugin in walletDemoConfig.ts. No drift.
• Re-checked RecurringDemoInner.tsx's citRequest/mitRequest (one-step and two-step) display objects against their actual request bodies — both still match, sourced from PLUGIN.
• Re-checked WalletDemoInner.tsx — no || ({} as any) reintroduced; filter.plugin from WALLET_DEMO.pgFilter is used consistently for both the Payment Methods call and the session type.

No new findings. The fix is complete and internally consistent.

Not verified (same limitation as last pass): I don't have permission to execute npm run typecheck / npm run build in this sandboxed environment (command execution requires approval that isn't available here). Static review found no type errors, and the author reported both passing after this commit, including the new compile-time enforcement (error TS2345 when type is omitted) — that wasn't independently re-run.
·

[junaidsarfrazdev]

LGTM

[farhan-t-ottu]

Fixes the interactive Checkout SDK demo failing at the Creating session step.

Refs #159191

Root cause

CheckoutDemoInner.tsx called callPaymentMethods without a plugin, which callPaymentMethods silently defaulted to payment_request, and then created the session with type: "e_commerce". Gateways are enabled per plugin, so discovery returned gateways the session type does not accept.

Reproduced live against sandbox.ottu.net:

Payment Methods call	gateways returned
plugin: "payment_request" (what the demo sent)	14 — includes cbk-private
plugin: "e_commerce"	13 — cbk-private dropped

POST /b/checkout/v1/pymt-txn/ (type: e_commerce, 14 codes) → 400
["pg code `cbk-private` is not enabled for `e_commerce` plugin."]

With the 13-code set → 201.

Changes

• src/utils/sandbox.ts — added PaymentPlugin ("e_commerce" | "payment_request", matching the Checkout API type enum). callPaymentMethods now takes plugin as a required argument, removing the ?? "payment_request" default that hid this. CreateSessionOptions.type narrowed from string to PaymentPlugin.
• All four demos — each declares const PLUGIN once and uses it for both the Payment Methods call and the session type, so the two can no longer drift apart.
• RecurringDemo / PaymentJourney — now send the type they already displayed in their request panels. RecurringDemo was rendering type: "e_commerce" while actually sending payment_request.
• WalletDemo — dropped a || ({} as any) that widened the filter to any and would have silently defeated the new required-plugin check.

Verification

Each demo driven in the browser with a fetch recorder capturing the real request bodies:

Demo	Payment Methods	Session
CheckoutDemo	plugin: "e_commerce" → 200	201, cbk-private absent from the 13 codes
RecurringDemo	plugin: "e_commerce" → 200	201, type: "e_commerce"
PaymentJourney	plugin: "payment_request" → 200	201
WalletDemo (KSA + webhook:local)	wallet filter → 200	seed 201, session 201

npm run typecheck and npm run build both pass. Omitting plugin, a misspelled plugin, and a misspelled session type are all now compile errors.

CheckoutDemo's SDK form then shows the SDK's own "Website doesn't run on non https pages" — that is the Ottu SDK refusing plain http://localhost, raised only after both API steps succeeded. It does not occur on the deployed https site.

Note for reviewers

This will not be visible on docs.ottu.dev yet. ACTIVE_CONNECT = KSA, and that merchant has a separate failure tracked in #159192: its demo gateways span KWD/USD/SAR default currencies and Connect rejects a session mixing two foreign defaults (a missing Currency Exchange entry). This PR takes effect on main/SANDBOX, or on dev once #159192 is resolved.

🤖 Generated with Claude Code

[farhan-t-ottu]

@claude review

[claude]

Claude finished @farhan-t-ottu's task in 2m 14s —— View job

---

Claude finished reviewing this PR

• Gather context (PR body, changed files list)
• Fetch branch diff against origin/dev
• Review src/utils/sandbox.ts changes
• Review each demo component's changes (CheckoutDemo, PaymentJourney, RecurringDemo, WalletDemo)
• Post review feedback

Summary

The fix itself is sound: callPaymentMethods's plugin is now required (no more ?? "payment_request" default), each demo declares one PLUGIN/filter.plugin source of truth, and I traced every createSandboxSession/callPaymentMethods call site in CheckoutDemo, RecurringDemo, WalletDemo — all pass a type/plugin that's derived from the single constant. RecurringDemoInner.tsx's citRequest/mitRequest display objects (used for the ApiPanel preview) are also correctly wired to PLUGIN now, matching what's actually sent — the drift called out in the PR description is fixed there.

Finding

src/components/PaymentJourney/PaymentJourneyInner.tsx:554 — the Step 3 ApiPanel preview for POST /b/checkout/v1/pymt-txn/ still hardcodes type: "payment_request" instead of PLUGIN:

<ApiPanellabel="POST /b/checkout/v1/pymt-txn/"data={{type: "payment_request",// ← should be `type: PLUGIN`pg_codes: state.pgCodes,
...

The actual request at line 349 correctly sends type: PLUGIN, and the Step 1 panel at line 523 was updated to plugin: PLUGIN, but this one spot was missed. It's harmless today only because PLUGIN = "payment_request" for this file, but it's exactly the class of bug this PR is fixing — the displayed request silently drifting from what's actually sent if PLUGIN is ever changed here. Worth a one-line fix for consistency: `Fix this →

Minor observation (non-blocking)

CreateSessionOptions.type in src/utils/sandbox.ts is still optional with a silent fallback (options.type ?? "payment_request" at sandbox.ts:92), while callPaymentMethods's plugin was deliberately made required to prevent exactly this kind of silent-default bug. Every current call site does pass type explicitly, so there's no live bug, but the same footgun that caused #159191 remains available to a future demo that forgets to pass it. Consider making type required on CreateSessionOptions too, for symmetry with plugin.

Not verified

I wasn't able to run npm run typecheck / npm run build in this sandboxed environment (command execution required approval that wasn't available). The PR description states both pass; the static review above didn't surface any type errors, but this wasn't independently confirmed.

[farhan-t-ottu]

Both points addressed in 2c56101.

Finding — PaymentJourneyInner.tsx:554. Fixed; the Step 3 panel now reads type: PLUGIN. You were right that it's the exact drift this branch removes. I swept the rest of the demos for the same pattern and this was the last hardcoded occurrence — the only remaining literals are walletDemoConfig.ts (the intended single source for WalletDemo) and the sandbox.ts fallback, which is gone as of this commit.

Verified in the browser against sandbox.ottu.net: the rendered Step 3 panel shows "type": "payment_request", identical output, now sourced from the constant.

Minor observation — CreateSessionOptions.type. Taken; type is now required and the ?? "payment_request" fallback is removed. Agreed that leaving it optional kept the exact footgun that caused #159191 available on the session side. Every call site already passed type explicitly, so it was type-level only — npm run typecheck passed without touching a single call site, and omitting type is now a compile error:

error TS2345: Argument of type '{ pg_codes: string[]; }' is not assignable to parameter of type 'CreateSessionOptions'.

npm run typecheck and npm run build both pass.

[farhan-t-ottu]

@claude review again

[claude]

Claude finished @farhan-t-ottu's task in 1m 12s —— View job

---

Re-review complete ✅

• Gather context (fetch latest diff since previous review, incl. commit 2c56101)
• Re-review sandbox.ts (now-required type)
• Re-review PaymentJourneyInner.tsx fix (Step 3 panel)
• Sweep all changed files for remaining issues
• Post final review feedback

Both items from the first pass are correctly resolved in 2c56101:

1. PaymentJourneyInner.tsx:554 — the Step 3 ApiPanel preview now reads type: PLUGIN instead of the hardcoded "payment_request". Confirmed the live call at line 349 and the displayed preview now share the same source.
2. sandbox.ts — CreateSessionOptions.type is now required (type: PaymentPlugin, no more ?: ), and createSandboxSession uses options.type directly with the ?? "payment_request" fallback removed. sandbox.ts:92 no longer has a silent default.

Additional verification this pass:

• Traced every createSandboxSession() call site in the repo (Grep) — exactly the 4 demo components + sandbox.ts itself, all passing type from a single PLUGIN/filter.plugin constant. No orphaned call site was left without an explicit type.
• Swept for remaining "payment_request"/"e_commerce" string literals — only the intended single-source declarations remain: PLUGIN const in CheckoutDemoInner.tsx, RecurringDemoInner.tsx, PaymentJourneyInner.tsx, and pgFilter.plugin in walletDemoConfig.ts. No drift.
• Re-checked RecurringDemoInner.tsx's citRequest/mitRequest (one-step and two-step) display objects against their actual request bodies — both still match, sourced from PLUGIN.
• Re-checked WalletDemoInner.tsx — no || ({} as any) reintroduced; filter.plugin from WALLET_DEMO.pgFilter is used consistently for both the Payment Methods call and the session type.

No new findings. The fix is complete and internally consistent.

Not verified (same limitation as last pass): I don't have permission to execute npm run typecheck / npm run build in this sandboxed environment (command execution requires approval that isn't available here). Static review found no type errors, and the author reported both passing after this commit, including the new compile-time enforcement (error TS2345 when type is omitted) — that wasn't independently re-run.
·

[junaidsarfrazdev]

LGTM

[farhan-t-ottu]

Fixes the interactive Checkout SDK demo failing at the Creating session step.

Refs #159191

Root cause

CheckoutDemoInner.tsx called callPaymentMethods without a plugin, which callPaymentMethods silently defaulted to payment_request, and then created the session with type: "e_commerce". Gateways are enabled per plugin, so discovery returned gateways the session type does not accept.

Reproduced live against sandbox.ottu.net:

Payment Methods call	gateways returned
plugin: "payment_request" (what the demo sent)	14 — includes cbk-private
plugin: "e_commerce"	13 — cbk-private dropped

POST /b/checkout/v1/pymt-txn/ (type: e_commerce, 14 codes) → 400
["pg code `cbk-private` is not enabled for `e_commerce` plugin."]

With the 13-code set → 201.

Changes

• src/utils/sandbox.ts — added PaymentPlugin ("e_commerce" | "payment_request", matching the Checkout API type enum). callPaymentMethods now takes plugin as a required argument, removing the ?? "payment_request" default that hid this. CreateSessionOptions.type narrowed from string to PaymentPlugin.
• All four demos — each declares const PLUGIN once and uses it for both the Payment Methods call and the session type, so the two can no longer drift apart.
• RecurringDemo / PaymentJourney — now send the type they already displayed in their request panels. RecurringDemo was rendering type: "e_commerce" while actually sending payment_request.
• WalletDemo — dropped a || ({} as any) that widened the filter to any and would have silently defeated the new required-plugin check.

Verification

Each demo driven in the browser with a fetch recorder capturing the real request bodies:

Demo	Payment Methods	Session
CheckoutDemo	plugin: "e_commerce" → 200	201, cbk-private absent from the 13 codes
RecurringDemo	plugin: "e_commerce" → 200	201, type: "e_commerce"
PaymentJourney	plugin: "payment_request" → 200	201
WalletDemo (KSA + webhook:local)	wallet filter → 200	seed 201, session 201

npm run typecheck and npm run build both pass. Omitting plugin, a misspelled plugin, and a misspelled session type are all now compile errors.

CheckoutDemo's SDK form then shows the SDK's own "Website doesn't run on non https pages" — that is the Ottu SDK refusing plain http://localhost, raised only after both API steps succeeded. It does not occur on the deployed https site.

Note for reviewers

This will not be visible on docs.ottu.dev yet. ACTIVE_CONNECT = KSA, and that merchant has a separate failure tracked in #159192: its demo gateways span KWD/USD/SAR default currencies and Connect rejects a session mixing two foreign defaults (a missing Currency Exchange entry). This PR takes effect on main/SANDBOX, or on dev once #159192 is resolved.

🤖 Generated with Claude Code

[farhan-t-ottu]

@claude review

[claude]

Claude finished @farhan-t-ottu's task in 2m 14s —— View job

---

Claude finished reviewing this PR

• Gather context (PR body, changed files list)
• Fetch branch diff against origin/dev
• Review src/utils/sandbox.ts changes
• Review each demo component's changes (CheckoutDemo, PaymentJourney, RecurringDemo, WalletDemo)
• Post review feedback

Summary

The fix itself is sound: callPaymentMethods's plugin is now required (no more ?? "payment_request" default), each demo declares one PLUGIN/filter.plugin source of truth, and I traced every createSandboxSession/callPaymentMethods call site in CheckoutDemo, RecurringDemo, WalletDemo — all pass a type/plugin that's derived from the single constant. RecurringDemoInner.tsx's citRequest/mitRequest display objects (used for the ApiPanel preview) are also correctly wired to PLUGIN now, matching what's actually sent — the drift called out in the PR description is fixed there.

Finding

src/components/PaymentJourney/PaymentJourneyInner.tsx:554 — the Step 3 ApiPanel preview for POST /b/checkout/v1/pymt-txn/ still hardcodes type: "payment_request" instead of PLUGIN:

<ApiPanellabel="POST /b/checkout/v1/pymt-txn/"data={{type: "payment_request",// ← should be `type: PLUGIN`pg_codes: state.pgCodes,
...

The actual request at line 349 correctly sends type: PLUGIN, and the Step 1 panel at line 523 was updated to plugin: PLUGIN, but this one spot was missed. It's harmless today only because PLUGIN = "payment_request" for this file, but it's exactly the class of bug this PR is fixing — the displayed request silently drifting from what's actually sent if PLUGIN is ever changed here. Worth a one-line fix for consistency: `Fix this →

Minor observation (non-blocking)

CreateSessionOptions.type in src/utils/sandbox.ts is still optional with a silent fallback (options.type ?? "payment_request" at sandbox.ts:92), while callPaymentMethods's plugin was deliberately made required to prevent exactly this kind of silent-default bug. Every current call site does pass type explicitly, so there's no live bug, but the same footgun that caused #159191 remains available to a future demo that forgets to pass it. Consider making type required on CreateSessionOptions too, for symmetry with plugin.

Not verified

I wasn't able to run npm run typecheck / npm run build in this sandboxed environment (command execution required approval that wasn't available). The PR description states both pass; the static review above didn't surface any type errors, but this wasn't independently confirmed.

[farhan-t-ottu]

Both points addressed in 2c56101.

Finding — PaymentJourneyInner.tsx:554. Fixed; the Step 3 panel now reads type: PLUGIN. You were right that it's the exact drift this branch removes. I swept the rest of the demos for the same pattern and this was the last hardcoded occurrence — the only remaining literals are walletDemoConfig.ts (the intended single source for WalletDemo) and the sandbox.ts fallback, which is gone as of this commit.

Verified in the browser against sandbox.ottu.net: the rendered Step 3 panel shows "type": "payment_request", identical output, now sourced from the constant.

Minor observation — CreateSessionOptions.type. Taken; type is now required and the ?? "payment_request" fallback is removed. Agreed that leaving it optional kept the exact footgun that caused #159191 available on the session side. Every call site already passed type explicitly, so it was type-level only — npm run typecheck passed without touching a single call site, and omitting type is now a compile error:

error TS2345: Argument of type '{ pg_codes: string[]; }' is not assignable to parameter of type 'CreateSessionOptions'.

npm run typecheck and npm run build both pass.

[farhan-t-ottu]

@claude review again

[claude]

Claude finished @farhan-t-ottu's task in 1m 12s —— View job

---

Re-review complete ✅

• Gather context (fetch latest diff since previous review, incl. commit 2c56101)
• Re-review sandbox.ts (now-required type)
• Re-review PaymentJourneyInner.tsx fix (Step 3 panel)
• Sweep all changed files for remaining issues
• Post final review feedback

Both items from the first pass are correctly resolved in 2c56101:

1. PaymentJourneyInner.tsx:554 — the Step 3 ApiPanel preview now reads type: PLUGIN instead of the hardcoded "payment_request". Confirmed the live call at line 349 and the displayed preview now share the same source.
2. sandbox.ts — CreateSessionOptions.type is now required (type: PaymentPlugin, no more ?: ), and createSandboxSession uses options.type directly with the ?? "payment_request" fallback removed. sandbox.ts:92 no longer has a silent default.

Additional verification this pass:

• Traced every createSandboxSession() call site in the repo (Grep) — exactly the 4 demo components + sandbox.ts itself, all passing type from a single PLUGIN/filter.plugin constant. No orphaned call site was left without an explicit type.
• Swept for remaining "payment_request"/"e_commerce" string literals — only the intended single-source declarations remain: PLUGIN const in CheckoutDemoInner.tsx, RecurringDemoInner.tsx, PaymentJourneyInner.tsx, and pgFilter.plugin in walletDemoConfig.ts. No drift.
• Re-checked RecurringDemoInner.tsx's citRequest/mitRequest (one-step and two-step) display objects against their actual request bodies — both still match, sourced from PLUGIN.
• Re-checked WalletDemoInner.tsx — no || ({} as any) reintroduced; filter.plugin from WALLET_DEMO.pgFilter is used consistently for both the Payment Methods call and the session type.

No new findings. The fix is complete and internally consistent.

Not verified (same limitation as last pass): I don't have permission to execute npm run typecheck / npm run build in this sandboxed environment (command execution requires approval that isn't available here). Static review found no type errors, and the author reported both passing after this commit, including the new compile-time enforcement (error TS2345 when type is omitted) — that wasn't independently re-run.
·

[junaidsarfrazdev]

LGTM