Phase 5/6 polish: end-session flow, notif sound on API 33+, Xendit webview

Customer end-of-session (figma §6):
- PricingBottomSheet: ghost "cukup, akhiri sesi" CTA + dedup divider
- chat_screen._runEndSessionFlow chains ConfirmEndStep1 → ConfirmEndStep2
  → ClosingMessageSheet (or "lewati saja" → close + /home). The four
  popup/sheet widgets already existed; this commit just wires them
- showModalBottomSheet: showDragHandle=false to suppress the Material 3
  auto-injected handle that was stacking with our own pill

Notification sound on API 33+:
- Bump channel halobestie_chat_v1 → halobestie_chat_v2, created from
  native Kotlin in MainActivity.kt with AudioAttributes contentType
  CONTENT_TYPE_SONIFICATION. flutter_local_notifications' default of
  CONTENT_TYPE_UNKNOWN was causing Android 13 to silently drop audio
  focus while the notification still posted (isNoisy=true). Both apps
- Backend FCM payload channelId updated to v2
- AndroidManifest meta-data: default_notification_icon + color → brand
  silhouette tinted pink instead of generic Android bell. Both apps

Customer pairing reliability:
- pairing_notifier: applyPairedFromPush({sessionId, mitraName}) unsticks
  searching screen when WS push failed and FCM/active-session-poll is
  the first signal. Idempotent across PairingSearchingData,
  PairingTargetedWaitingData, PairingErrorData (covers ALREADY_ACTIVE)
- notification_service: dispatches every FCM data payload to an
  onDataMessage callback (foreground + tap + cold-start). main.dart
  wires that to applyPairedFromPush on type=='paired'. Foreground
  'paired' no longer renders a local banner — screen self-advances
- main.dart activeSession listener also calls applyPairedFromPush when
  a session appears server-side while pairing is in a waiting state.
  Covers stale ALREADY_ACTIVE recovery without a full page refresh

Auth refresh token race:
- auth_notifier._refreshFromStorage shares a single in-flight Future
  across all callers (Auth.build + 401-retry path). Backend rotates
  refresh tokens, so concurrent callers using the same stored token
  would race → loser 401s → catch wipes flutter_secure_storage → user
  appears logged out after kill+reopen

Polish:
- method_pick_screen: resizeToAvoidBottomInset=false — prevents the
  one-frame overflow when entering with the previous screen's keyboard
  still animating out
- bestie_history: BestieHistoryItem now carries `status` (backend
  already returns it). Removed _rawHistoryProvider that fetched the
  same endpoint just to read status; the two providers could go out
  of sync mid-rebuild and throw RangeError(length) on indexing

Xendit Stage 8 (carried from WIP):
- xendit_checkout_screen: embedded webview hosting Xendit's invoice
  page (intercepts halobestie:// deeplink + return-page URLs for
  deterministic pop)
- waiting_payment_screen: auto-pushes the webview when the backend
  payload includes xendit_invoice_url; spinner card + "Buka ulang
  halaman pembayaran" CTA for the QR-fallback path
- pubspec: webview_flutter ^4.13.0

Maestro infra:
- subflows/onboarding_returning_user: drop the "Mulai" carousel wait
  (splash auto-advances since 2026-05-26); tap phone-field hint
  instead of point; drop hideKeyboard (sends BACK → /home when the
  IME isn't actually up)
- New flow ts-customer-06-01-end_session_via_timeup_sheet: drives
  the full path to the chat-expired banner. Last step blocked by a
  Maestro+Flutter gesture quirk on the perpanjang ElevatedButton
  (raw `adb input tap` works at the same coords). Documented in
  memory; deeplink fixture or manual verify recommended
- ChatExpiredBanner button wrapped with Semantics(identifier:
  'chat_extend_button', button: true, onTap: …) — good hygiene for
  future tests even though it doesn't fix the dadb tap issue

.dev/: tracked wsl_emulator_bridge.ps1 + wsl_tcp_relay.py for
Maestro-on-WSL setup (Windows-side netsh portproxy + WSL-side
loopback relays). Both referenced from existing CLAUDE.md notes.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

backend/CLAUDE.md

@@ -60,10 +60,12 @@ When a new value needs to flow from CC → app, prefer DB. When it's a deploy-fi
 
 ## FCM Channel Convention
 
-Single channel `halobestie_chat_v1` is shared by both apps (registered in each app's `core/notifications/notification_service.dart`) and ships the branded `halobestie_notif.ogg` sound. Backend FCM payloads should always target this channel ID via `android.notification.channelId`:
+Single channel `halobestie_chat_v2` is shared by both apps and ships the branded `halobestie_notif.ogg` sound. Backend FCM payloads should always target this channel ID via `android.notification.channelId`:
 
 ```js
-android: { priority: 'high', notification: { channelId: 'halobestie_chat_v1' } }
+android: { priority: 'high', notification: { channelId: 'halobestie_chat_v2' } }
 ```
 
-Do not introduce per-recipient or per-feature channels lightly. If a new sound is required (e.g. payment alert), bump the channel ID (`halobestie_chat_v2`) and update both apps simultaneously — Android binds channel sound at create-time on API 26+, so mutating the existing channel doesn't pick up the new sound for installed users.
+**Channel must be created from native Android (Kotlin) code, not from Dart via `flutter_local_notifications`.** The plugin's `AndroidNotificationChannel` sets `AudioAttributes` with `CONTENT_TYPE_UNKNOWN`; on Android 13+ (API 33) this causes notifications to post and be tagged `isNoisy=true`, but `systemui` never requests audio focus and the sound is silently dropped. The native channel must use `setContentType(CONTENT_TYPE_SONIFICATION)` alongside `USAGE_NOTIFICATION`. See `MainActivity.kt` in both `client_app` and `mitra_app`. The Dart-side `AndroidNotificationChannel` definition stays in `notification_service.dart` so `flutter_local_notifications.show()` resolves the channel id, but its `createNotificationChannel` call is a no-op since the native channel already exists (channels are immutable on API 26+).
+
+Do not introduce per-recipient or per-feature channels lightly. If a new sound is required (e.g. payment alert), bump the channel ID (`halobestie_chat_v3`) and update both apps' native MainActivity + Dart definition + backend simultaneously — Android binds channel sound at create-time on API 26+, so mutating the existing channel doesn't pick up the new sound for installed users.

backend/src/services/notification.service.js

@@ -36,7 +36,7 @@ export const sendPushNotification = async (recipientType, recipientId, { title,
         // Both apps register the same channel ID with the branded
         // notification sound (halobestie_notif.ogg in res/raw). See each
         // app's lib/core/notifications/notification_service.dart.
-        notification: { channelId: 'halobestie_chat_v1' },
+        notification: { channelId: 'halobestie_chat_v2' },
       },
       apns: {
         payload: {

backend/src/services/payment.service.js

@@ -26,6 +26,7 @@
 //
 //   on(eventName, handler) → subscribe to lifecycle events
 //   verifyWebhookToken(headerToken) → constant-time compare for webhook auth (used by route)
+//   xenditInvoiceMethodFromCode(payment_code) → catalog→Xendit invoice filter map (exported for tests)
 //
 //   registerPairingSubscriber() → wires pairing.service as a subscriber to payment_request.confirmed
 //   recordIntermediateFailure(...) → audit-only failure for flows with a fallback path
@@ -87,8 +88,54 @@ const xenditClient = () => {
   return _xenditClient
 }
 
-const createXenditInvoice = async ({ paymentRequestId, amount, ttlMinutes, description }) => {
+// Map our catalog `payment_code` (Xendit channel-code style — `BCA_VIRTUAL_ACCOUNT`,
+// `CARDS`, etc., per https://docs.xendit.co/docs/available-payment-channels) to the
+// short token Xendit's Create-Invoice `paymentMethods[]` filter expects. The two
+// vocabularies overlap a lot but are not identical — channel codes are descriptive
+// (`BCA_VIRTUAL_ACCOUNT`), invoice filter values are by-payment-rail (`BCA`).
+//
+// Returning null means "no mapping" — caller should omit `paymentMethods` so Xendit
+// shows the full multi-method picker (graceful degradation). Avoid throwing here —
+// a stray unknown code shouldn't break invoice creation.
+//
+// Reference list (Xendit Create Invoice `payment_methods` accepted values, May 2026):
+//   Bank: BCA, BNI, BRI, BSI, BJB, MANDIRI, PERMATA, SAHABAT_SAMPOERNA
+//   Retail: ALFAMART, INDOMARET
+//   E-wallet: OVO, DANA, SHOPEEPAY, LINKAJA, JENIUSPAY, ASTRAPAY
+//   QR: QRIS    Card: CREDIT_CARD    Paylater: KREDIVO, AKULAKU, UANGME, ATOME
+//
+// Notes:
+// - CIMB is NOT exposed by Xendit's invoice paymentMethods filter (only as a raw VA
+//   channel via the lower-level VA API), so CIMB_VIRTUAL_ACCOUNT intentionally
+//   returns null → multi-method page fallback.
+export const xenditInvoiceMethodFromCode = (code) => {
+  if (!code || typeof code !== 'string') return null
+  const m = {
+    QRIS: 'QRIS',
+    OVO: 'OVO',
+    DANA: 'DANA',
+    SHOPEEPAY: 'SHOPEEPAY',
+    LINKAJA: 'LINKAJA',
+    ASTRAPAY: 'ASTRAPAY',
+    BCA_VIRTUAL_ACCOUNT: 'BCA',
+    BNI_VIRTUAL_ACCOUNT: 'BNI',
+    BRI_VIRTUAL_ACCOUNT: 'BRI',
+    BSI_VIRTUAL_ACCOUNT: 'BSI',
+    MANDIRI_VIRTUAL_ACCOUNT: 'MANDIRI',
+    PERMATA_VIRTUAL_ACCOUNT: 'PERMATA',
+    BJB_VIRTUAL_ACCOUNT: 'BJB',
+    BSS_VIRTUAL_ACCOUNT: 'SAHABAT_SAMPOERNA',
+    ALFAMART: 'ALFAMART',
+    INDOMARET: 'INDOMARET',
+    CARDS: 'CREDIT_CARD',
+  }
+  return m[code.toUpperCase()] ?? null
+}
+
+const createXenditInvoice = async ({ paymentRequestId, amount, ttlMinutes, description, preferredPaymentCode }) => {
   const { successRedirectUrl, failureRedirectUrl } = getXenditConfig()
+  const invoiceMethod = xenditInvoiceMethodFromCode(preferredPaymentCode)
+  console.log('[xendit] createInvoice', { paymentRequestId, amount, preferredPaymentCode, invoiceMethod })
   const inv = await xenditClient().Invoice.createInvoice({
     data: {
       externalId: paymentRequestId,             // D4 — our UUID is the Xendit external_id
@@ -101,7 +148,10 @@ const createXenditInvoice = async ({ paymentRequestId, amount, ttlMinutes, descr
       // Stamped so a shared webhook router (no DB access) can route v1 vs v2 traffic
       // purely from the echoed payload. Keep this string stable — it is a routing key.
       metadata: { app: 'halobestie_v2' },
-      // paymentMethods omitted → honor dashboard config (operator picks methods without a deploy)
+      // Lock the hosted page to the customer's chosen method when we have a mapping.
+      // When mapping returns null (unknown / unsupported code), omit the filter and
+      // let Xendit show the full picker so the customer can still pay.
+      ...(invoiceMethod ? { paymentMethods: [invoiceMethod] } : {}),
     },
   })
   return { invoiceId: inv.id, invoiceUrl: inv.invoiceUrl }
@@ -177,10 +227,10 @@ export const requestPayment = async ({
   isExtension = false,
   targetedMitraId = null,
   // Customer's pre-picked payment method from the catalog. Optional;
-  // upper-cased Xendit channel code (e.g. `OVO`). Stamped onto
-  // product_metadata for analytics + future use as a Xendit `paymentMethods`
-  // filter. Not currently passed to Xendit invoice creation — the customer
-  // re-picks on Xendit's checkout page.
+  // upper-cased channel code (e.g. `OVO`, `BCA_VIRTUAL_ACCOUNT`, `CARDS`).
+  // Stamped onto product_metadata for analytics AND translated via
+  // xenditInvoiceMethodFromCode() into Xendit's invoice paymentMethods[]
+  // filter so the customer doesn't have to re-pick on the hosted page.
   preferredPaymentCode = null,
 }) => {
   if (!customerId) {
@@ -239,6 +289,7 @@ export const requestPayment = async ({
         amount: row.amount,
         ttlMinutes: ttl,
         description: buildInvoiceDescription(row),
+        preferredPaymentCode,
       })
       await sql`
         UPDATE payment_requests

backend/test/services/payment.service.test.js

@@ -4,6 +4,7 @@ import {
   confirmPaymentSession,
   getPaymentSession,
   getCustomerPendingPayments,
+  xenditInvoiceMethodFromCode,
 } from '../../src/services/payment.service.js'
 import { PaymentRequestStatus, SessionStatus } from '../../src/constants.js'
 import { resetDb, resetAppConfig, db } from '../helpers/db.js'
@@ -85,6 +86,45 @@ describe('payment.service', () => {
     expect(reloaded.confirmed_at).toBeNull()
   })
 
+  // Phase 5.x — catalog payment_code → Xendit invoice paymentMethods filter.
+  // Pure function, no DB / no Xendit client touched.
+  describe('xenditInvoiceMethodFromCode', () => {
+    it('maps Virtual Account codes to bank rails', () => {
+      expect(xenditInvoiceMethodFromCode('BCA_VIRTUAL_ACCOUNT')).toBe('BCA')
+      expect(xenditInvoiceMethodFromCode('BNI_VIRTUAL_ACCOUNT')).toBe('BNI')
+      expect(xenditInvoiceMethodFromCode('MANDIRI_VIRTUAL_ACCOUNT')).toBe('MANDIRI')
+      expect(xenditInvoiceMethodFromCode('PERMATA_VIRTUAL_ACCOUNT')).toBe('PERMATA')
+      expect(xenditInvoiceMethodFromCode('BSS_VIRTUAL_ACCOUNT')).toBe('SAHABAT_SAMPOERNA')
+    })
+
+    it('maps e-wallet codes verbatim', () => {
+      expect(xenditInvoiceMethodFromCode('OVO')).toBe('OVO')
+      expect(xenditInvoiceMethodFromCode('DANA')).toBe('DANA')
+      expect(xenditInvoiceMethodFromCode('SHOPEEPAY')).toBe('SHOPEEPAY')
+    })
+
+    it('maps CARDS to CREDIT_CARD and QRIS verbatim', () => {
+      expect(xenditInvoiceMethodFromCode('CARDS')).toBe('CREDIT_CARD')
+      expect(xenditInvoiceMethodFromCode('QRIS')).toBe('QRIS')
+    })
+
+    it('is casing-tolerant', () => {
+      expect(xenditInvoiceMethodFromCode('bca_virtual_account')).toBe('BCA')
+      expect(xenditInvoiceMethodFromCode('Ovo')).toBe('OVO')
+    })
+
+    it('returns null for unknown / unsupported / falsy codes', () => {
+      // CIMB is not in Xendit's invoice paymentMethods filter list (only as a
+      // raw VA channel) — must degrade to the full-picker fallback, not throw.
+      expect(xenditInvoiceMethodFromCode('CIMB_VIRTUAL_ACCOUNT')).toBeNull()
+      expect(xenditInvoiceMethodFromCode('NOT_A_REAL_CODE')).toBeNull()
+      expect(xenditInvoiceMethodFromCode('')).toBeNull()
+      expect(xenditInvoiceMethodFromCode(null)).toBeNull()
+      expect(xenditInvoiceMethodFromCode(undefined)).toBeNull()
+      expect(xenditInvoiceMethodFromCode(42)).toBeNull()
+    })
+  })
+
   // Phase 4 Stage 10 — Chat Tab Pembayaran feed.
   describe('getCustomerPendingPayments', () => {
     it('returns empty when customer has no payments', async () => {