Fast-Track Payment × SIMPADHU/SIMPONI — Done Report (2026-07-12)

Decision implemented (Efran): option 1 without verifikator attestation — the applicant's kode billing is checked directly against SIMPADHU/SIMPONI, read-only, with a dev bypass mode.

Status: DONE & DEPLOYED — staging ahu-ai-ocr:7bf3ffb6 (:3520). Both suites green (backend 2537, frontend 970). Verified end-to-end against the real billing database, including a genuine paid voucher returning VERIFIED with its NTPN.

How it works

sequenceDiagram participant A as Pemohon participant OCR as ahu-ocr (this app) participant S as AHU_BILLING_SIMPADHU (MySQL, read-only) A->>OCR: kode billing (upload atau halaman tinjauan) OCR->>S: SELECT … FROM billing_YYYYMM_x WHERE KODE_PEMBAYARAN = ? S-->>OCR: FLAG_PEMBAYARAN / TERPAKAI / TGL_EXPIRED / NTPN / tarif OCR-->>A: VERIFIED · UNPAID · EXPIRED · USED · … (chip + pesan) A->>OCR: Kirim ke Verifikator (PERCEPATAN) OCR->>S: re-verify pada saat submit OCR-->>A: lolos (VERIFIED/BYPASSED) atau 409 FASTTRACK_PAYMENT

Read-only by construction AND by privilege: the lookup uses the same MySQL server + bht-read user as the SABH integration; its grant is literally SELECT, SHOW VIEW (checked live via SHOW GRANTS). We never mark a voucher consumed — TERPAKAI remains SABH's to write.
Schema facts (from the SIMPADHU/SIMPONI source + live DB): vouchers live in half-month partitions billing_YYYYMM_0|1; the typed code embeds its issue date (8+YYYYMMDD+seq, newer 2+YYYYMMDD) which resolves the partition (sibling probed as fallback); FLAG_PEMBAYARAN=1 = paid (2 = reversed), TERPAKAI 0 usable / 1 consumed / 2 refund / 3 expired, plus SIMPADHU's paid-unused +60 days expiry rule. Verdict order mirrors SIMPADHU's own cekKodeVoucher.
Where it gates: the code is optional at upload and editable on the review page ("Detail Permohonan" → Pembayaran PNBP block with live verify); Kirim ke Verifikator re-verifies at the moment of submission for PERCEPATAN and 409s unless VERIFIED (or bypassed) — so a voucher paid five minutes ago passes, and one consumed elsewhere in the meantime stops passing. Result (status, NTPN, amount, tariff name, payer) is persisted on the submission and shown to both applicant and verifikator.

Dev bypass (as requested)

fasttrackPaymentBypass is an admin-togglable knob in /admin/settings (env default FASTTRACK_PAYMENT_BYPASS=on). While on, every check reports "Dilewati (mode pengembangan)" and percepatan submits without a voucher — flip it to 0 in the admin UI to enforce the real SIMPONI check instantly (no redeploy).

Live verification (staging, real data)

Input	Result
`garbage`	INVALID_FORMAT — "Format kode billing tidak dikenali"
`820260701999999` (well-formed, unknown)	NOT_FOUND
`820260701189127` (real paid voucher)	VERIFIED — Rp500.000 · NTPN `9D9E81JNGHS7SD07` · a.n. JHON · tarif read back from `ahu_tarif_pnbp`
any code with bypass on	BYPASSED

Also confirmed live: the apostille tariff exists in the tariff table ("Permohonan Legalisasi Apostille", KDPP 202445, Rp150.000) — we display the voucher's own tariff description rather than hard-requiring a specific tariff code, since the percepatan surcharge's tariff row isn't distinguishable yet; tightening to specific KD_TARIFs is a one-line change when the business rule is settled.

Notes

Demo row cee52830 and the admin overrides were reverted after testing (everything back on env defaults, bypass ON).
The weekday/window gates still apply to entering percepatan (it's Sunday — the lane switch correctly refused during testing; I set the lane via DB for the test only).
New pieces: lib/simpadhu-db.ts, services/apostille-fasttrack-payment.ts, routes/apostille-fasttrack-routes.ts (lane routes split at the monster-file cap), migration 20260712080000_fasttrack_payment, FE FastTrackPaymentBlock + upload-page input + submit precheck. 12 new backend tests (parsing, partition math, verdict ladder, bypass, route gates).