root
/
Midtrans-Middleware
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
Midtrans-Middleware/docs/stories/checkout-wizard-demo.md

5.9 KiB
Raw Blame History

Checkout Wizard untuk Demo Store (1 Produk) - Brownfield Addition

Status Story

  • Status: Approved
  • Disetujui oleh: John (PM)
  • Tanggal: 2025-11-08

User Story

Sebagai pengguna demo toko, Saya ingin membeli satu produk melalui alur checkout bertahap (step-by-step) dan memilih metode pembayaran di langkah terpisah, Agar demo alur belanja jelas, ringkas, dan mudah dipahami.

Story Context

Existing System Integration:

  • Integrates with: src/pages/CheckoutPage.tsx, komponen pembayaran di src/features/payments/components/*
  • Technology: React + Vite + Tailwind
  • Follows pattern: Reuse komponen PaymentMethodList dan panel metode (Bank/Card/GoPay), state-driven UI tanpa perubahan arsitektur
  • Touch points: PaymentMethodList.tsx, BankTransferPanel.tsx, CardPanel.tsx, GoPayPanel.tsx

Acceptance Criteria

Functional Requirements:

  1. Tersedia halaman Demo Store berisi 1 produk dengan tombol Buy Now.
  2. Klik Buy Now mengarahkan ke Checkout Page dengan form checkout yang menampilkan field: Nama, Email/HP, Alamat, dan Catatan; seluruh field terisi nilai dummy default (editable) untuk keperluan demo.
  3. Setelah konfirmasi form, pengguna masuk ke langkah pemilihan metode pembayaran (Step 2).
  4. Pemilihan metode pembayaran dilakukan di langkah terpisah, bukan dropdown/accordion pada halaman yang sama seperti saat ini.
  5. Setelah memilih metode (Bank Transfer / Kartu / GoPay/QRIS), pengguna masuk ke langkah berikutnya (Step 3) yang menampilkan panel/instruksi sesuai metode terpilih.
  6. Tersedia tombol Back untuk kembali ke langkah sebelumnya (mis. dari Step 3 ke Step 2 untuk mengganti metode).
  7. Flow bekerja mulus di dev server tanpa error browser/terminal.

Integration Requirements: 8. Fungsi panel pembayaran yang ada tetap digunakan (reusable) tanpa perubahan API backend. 9. Tidak ada regresi pada halaman status pembayaran (PaymentStatusPage.tsx) dan riwayat pembayaran (PaymentHistoryPage.tsx). 10. Tetap mengikuti pola styling dan komponen yang ada (Tailwind, komponen internal) agar konsisten.

Quality Requirements: 11. Navigasi antar langkah jelas (indikator step atau label sederhana) dan dapat dioperasikan dengan keyboard. 12. Dokumentasi singkat alur (README atau komentar terstruktur) ditambahkan bila perlu. 13. Verifikasi manual dilakukan: pilih setiap metode dan pastikan panel/instruksi tampil sesuai. 14. Layout, card, dan grid yang ada TIDAK diubah (wrapper, spacing, breakpoints tetap). 15. Tidak mengubah ukuran container, struktur grid, atau komponen kartu; hanya pengaturan visibilitas/kondisional antar langkah.

Technical Notes

  • Integration Approach: Implementasi wizard berbasis state di CheckoutPage.tsx (Step 1: konfirmasi data, Step 2: pilih metode, Step 3: panel metode). Hindari perubahan routing besar; tetap di /checkout untuk kesederhanaan.
  • Existing Pattern Reference: Gunakan komponen PaymentMethodList untuk Step 2 (list-only), dan render panel metode di Step 3 berdasarkan pilihan.
  • Key Constraints: Minimalkan perubahan pada arsitektur; jangan mengubah kontrak API atau data model pembayaran. Jaga konsistensi UI. Jangan sentuh wrapper layout (grid, card, container), hindari perubahan spacing/breakpoints — hanya atur visibilitas komponen antar langkah.
  • Dummy Form Fields: Nama, Email/HP, Alamat, Catatan dengan nilai default: "Demo User", "demo@example.com" / "081234567890", "Jl. Contoh No. 1", dan Catatan kosong/opsional. Semua nilai editable; tidak diperlukan validasi berat untuk demo.

Definition of Done

  • Functional requirements terpenuhi (demo 1 produk → checkout dummy → pilih metode → panel langkah berikutnya)
  • Integration requirements terverifikasi (komponen lama dipakai kembali; status/history tidak regresi)
  • Regression manual terhadap alur pembayaran yang sudah ada
  • Kode mengikuti pola dan standar proyek (React, Tailwind)
  • Dev server berjalan tanpa error; flow diuji untuk semua metode
  • Dokumentasi ringkas alur ditambah bila perlu

Risk and Compatibility Check

Minimal Risk Assessment:

  • Primary Risk: Perubahan alur UI dapat mempengaruhi asumsi pengguna lama yang terbiasa dengan accordion.
  • Mitigation: Sediakan tombol Back dan label step yang jelas; lakukan pengujian manual untuk semua metode.
  • Rollback: Kembalikan rendering panel ke model accordion (seperti implementasi saat ini) jika diperlukan.

Compatibility Verification:

  • Tidak ada perubahan pada API publik/back-end
  • Tidak ada perubahan DB
  • Perubahan UI mengikuti pola Tailwind/komponen internal
  • Dampak performa diabaikan (UI lokal/state)

Validation Checklist

Scope Validation:

  • Dapat diselesaikan dalam satu sesi pengembangan
  • Integrasi straightforward (komponen yang ada digunakan ulang)
  • Mengikuti pola yang sudah ada
  • Tidak perlu desain/arsitektur baru

Clarity Check:

  • Requirement jelas dan tidak ambigu
  • Titik integrasi ditentukan (CheckoutPage, PaymentMethodList, panel metode)
  • Kriteria sukses dapat diuji (navigasi step, panel tampil sesuai)
  • Rollback sederhana (kembali ke accordion)

Out-of-Scope

  • Multi-route wizard (mis. /checkout/step/2) — tetap single-route untuk kesederhanaan.
  • Perubahan kontrak API pembayaran atau penambahan metode baru.
  • Penataan ulang besar desain visual di luar kebutuhan stepper sederhana.

Implementasi Minimal yang Direkomendasikan

  • Tambah state currentStep di CheckoutPage.tsx dengan nilai: 1 (Form Dummy) → 2 (Pilih Metode) → 3 (Panel Metode).
  • Refactor rendering: PaymentMethodList hanya list dan memilih metode di Step 2; panel detail dirender di Step 3 berdasarkan pilihan.
  • Tambah kontrol Next/Back untuk perpindahan step.
  • Jangan ubah wrapper layout (grid, card, container) yang sudah rapi; tetap gunakan struktur/kelas yang ada dan hanya ubah visibilitas komponen sesuai step.
  • Prefill form Step 1 dengan nilai dummy default dan lanjutkan ke Step 2 lewat tombol Next tanpa memaksa validasi berat.