BayarAman - Platform Rekber dengan Midtrans dan Workflow Auditable

Overview

BayarAman adalah produk rekber untuk buyer dan seller yang sudah saling menemukan di luar marketplace. Project ini menggunakan Midtrans sebagai payment gateway agar buyer membayar melalui hosted payment page, sementara BayarAman memproses notifikasi pembayaran yang tervalidasi sebelum seller boleh melanjutkan fulfillment.

Saya mendefinisikan ulang pengalaman transaksi dari invitation dan pengisian data peran sampai pembayaran, fulfillment, konfirmasi buyer, payout seller, complaint hold, cancellation, dan refund. Product artifacts, technical design, implementasi aplikasi, admin operations, automated tests, serta staging deployment dikerjakan sebagai solo builder.

Tech & Libraries

Teknologi dan library yang dipakai atau disentuh di project ini:

Problem

Transaksi off-marketplace membuat buyer berisiko membayar sebelum barang diterima, sementara seller berisiko mengirim barang tanpa kepastian pembayaran. Koordinasi rekber manual juga dapat membuat status, ownership data, next action, dan bukti operasional tersebar di chat atau catatan yang tidak konsisten.

My Role & Ownership

Solo builder end-to-end: product artifacts, architecture, backend domain, API, admin operations, testing, dan deployment

Technical Approach

Membangun aplikasi Next.js dengan PostgreSQL dan Drizzle ORM yang memodelkan buyer dan seller sebagai role pada satu account system. Midtrans digunakan sebagai payment gateway melalui Invoice API dan hosted payment link; BayarAman tidak mengekspos credential provider ke client.

Webhook Midtrans yang tervalidasi dan Get Status reconciliation menentukan payment authority sebelum workflow WhatsApp, fulfillment, buyer OTP, payout, cancellation, complaint hold, dan refund berjalan melalui service boundary serta endpoint terotorisasi.

Architecture Notes

Struktur sistem memisahkan UI route, API mutation, domain service, repository, dan adapter provider.

1. Transaction terms dibekukan sebelum invoice dibuat agar nominal, fee, dan deadline tidak berubah saat payment flow berjalan.
2. Provider evidence dan data sensitif dipisahkan dari projection yang aman untuk buyer dan seller.
3. Idempotency key dan expected state version digunakan pada mutation penting untuk mencegah duplikasi dan lost update.
4. Job runner menangani expiry, notification delivery, recovery, dan SLA escalation secara aman untuk dijalankan ulang.

Trade-offs

Project memprioritaskan workflow manual yang auditable sebelum otomatisasi penuh.

1. WhatsApp tetap menjadi channel fulfillment dan complaint karena kebutuhan MVP, dengan checkpoint eksplisit di sistem sebagai kompromi antara kecepatan implementasi dan traceability.
2. PostgreSQL relational constraints dipakai untuk menjaga invariants transaksi, meskipun schema dan migration menjadi lebih ketat.
3. Midtrans sandbox dan fake adapter dipakai untuk local serta automated tests; real-money launch tetap ditahan sampai settlement, legal, compliance, credential, dan pilot evidence disetujui.

Implementation Highlights

• Integrasi payment gateway Midtrans melalui Invoice API dan hosted payment link dengan invoice idempotency.
• Idempotent invoice creation dan webhook processing dengan signature, order, amount, fraud, serta ordering validation.
• Role-owned buyer/seller data dengan distinct-account constraint dan masking raw financial, provider, WhatsApp, OTP, serta risk evidence.
• Cancellation lifecycle yang membedakan unfunded cancellation, funded cancellation, reconciliation, complaint handoff, risk hold, refund, dan terminal state.
• Two-admin approval, payout re-authentication, append-only audit event, expected state version, dan idempotency boundary untuk operasi sensitif.
• Background job registry untuk expiry, confirmation recovery, cancellation timeout, notification delivery, dan SLA escalation.

Results

• Mengubah proses rekber yang rawan status ambigu menjadi alur transaksi dengan ownership data, payment authority, checkpoint operasional, dan audit trail yang eksplisit.
• Product Brief, User Journey, UX Flow, User Requirements, UI/UX Spec, dan QA Scenarios disusun sebagai artifact yang saling terlacak.
• Payment, cancellation, complaint, risk hold, refund, payout, OTP, audit, dan SLA memiliki boundary implementasi yang eksplisit.
• Staging app dan prototype publik tersedia untuk review tanpa membuka credential atau data transaksi nyata.
• 27 commit pada branch main per 2026-08-04.
• 23 file test dengan 97 blok test dan describe terdeteksi.
• Product Brief v0.10 dan TRD v1.2 berstatus Approved; QA Scenarios v0.2 juga berstatus Approved.

Links

• Live Demo
• GitHub Repository