Arsitektur platform

Satu inti, banyak antarmuka — cara kerja platform yang sebenarnya.

Penelusuran platform dari ledger ke atas: akun, KYC, kartu, dan kripto yang berbagi satu inti double-entry, bagaimana satu pembayaran bergerak dari pembuatan hingga rekonsiliasi, serta posisi lapisan aplikasi, konsol operator, dan batas regulasi.

Inti platform

Satu ledger di balik semuanya.

Di pusat platform terdapat satu ledger akun. Setiap akun — dompet nasabah, saldo merchant, akun biaya, akun settlement — adalah satu simpul di ledger itu, dan setiap perpindahan nilai dicatat sebagai posting double-entry: satu akun didebit, akun lain dikredit, kedua sisinya selalu sama. Ledger bersifat append-only. Entri tidak pernah diubah atau dihapus; koreksi berupa entri baru yang berlawanan, sehingga riwayat lengkap bagaimana sebuah saldo mencapai nilainya saat ini selalu dapat direkonstruksi. Akun, status KYC, kartu yang diterbitkan, dan alamat kripto semuanya terhubung ke model akun yang sama. Karena itu otorisasi kartu, transfer bank, dan deposit on-chain bisa masuk ke satu saldo tanpa lapisan rekonsiliasi yang menyambungkan sistem-sistem terpisah.

  1. 01Double-entry: setiap posting seimbang, debit sama dengan kredit
  2. 02Append-only: koreksi berupa entri baru, bukan pengubahan
  3. 03Satu model akun untuk fiat, kartu, dan kripto
  4. 04Status KYC menyatu dengan akun, bukan tabel terpisah

Satu pembayaran, dari awal hingga akhir

Satu pembayaran, dari create hingga reconcile.

Pembayaran bukan satu panggilan, melainkan siklus singkat, dan setiap tahap adalah status yang dapat dilihat oleh ledger maupun sistem Anda. Setiap perubahan status mengirim webhook, dan setiap operasi tulis bersifat idempoten — kunci yang sama menghasilkan hasil yang sama, sehingga permintaan yang diulang tidak pernah menagih dua kali.

  1. 01

    Create

    Sebuah intent dibuka: jumlah, mata uang, dan akun yang terlibat. Belum ada yang berpindah — ledger mencatat entri pending.

  2. 02

    Authorize

    Rel memeriksa dana dan risiko, lalu menempatkan hold. Pada kartu, ini adalah otorisasi; pada transfer, debit dicadangkan.

  3. 03

    Capture

    Jumlah yang ditahan dikonfirmasi. Ledger memposting double-entry yang benar-benar memindahkan nilai antara kedua akun.

  4. 04

    Settle

    Dana dikliring melalui rel yang mendasarinya — skema kartu, bank, atau chain — dan akun settlement direkonsiliasi dengan uang nyata.

  5. 05

    Reconcile

    Platform mencocokkan postingnya sendiri dengan laporan settlement dari rel; apa pun yang tidak cocok ditandai, bukan disembunyikan.

Webhook dan idempotensi hadir di setiap tepi alur ini. Sistem Anda mengetahui sebuah pembayaran berpindah dengan menerima event, bukan polling, dan setiap permintaan yang Anda ulang setelah timeout diselesaikan — melalui idempotency key — ke hasil yang sama, sehingga pengulangan tidak pernah menagih dua kali. Layanan yang menjalankan authorize dan capture adalah payment gateway.

Lapisan aplikasi

Aplikasi whitelabel di atas, satu platform di bawah.

Inti platform menyediakan kapabilitas; lapisan aplikasi mengubahnya menjadi produk. Setiap aplikasi untuk pelanggan — web maupun mobile — adalah klien whitelabel yang menampilkan akun, pembayaran, dan kartu yang sama dengan merek masing-masing. Tema digerakkan oleh token: warna, tipografi, radius, dan jarak berasal dari sistem design token (PDS), sehingga operator dapat mengubah tampilan seluruh antarmuka dengan mengganti token, bukan dengan mem-fork aplikasi. Platform yang sama bisa diarahkan ke berbagai tujuan — neobank konsumen, aplikasi acquiring untuk merchant, program penerbitan kartu, on/off-ramp kripto, atau alat operasional internal — tanpa menjadi lima produk terpisah. Satu platform dengan tampilan berbeda, masing-masing dikonfigurasi, bukan dibangun ulang.

  1. 01Klien whitelabel web + mobile di atas API bersama
  2. 02Tema berbasis token (PDS): ubah tampilan lewat konfigurasi, bukan fork
  3. 03Lima contoh arah — neobank, acquiring, issuing, ramp, ops
  4. 04Antarmuka baru dikonfigurasi, bukan dibangun ulang

Operasional

Jalankan dari konsol, dengan alasan tercatat.

Di balik setiap aplikasi ada konsol operator. Di sinilah agen dukungan mencari akun, analis risiko membekukan kartu, atau kepala operasional membalik sebuah posting. Akses baca luas; tindakan istimewa tidak. Setiap hal yang memindahkan uang, mengubah limit, atau menyentuh dana nasabah mewajibkan alasan tertulis sebelum dijalankan dan menghasilkan entri audit yang tidak dapat diubah — siapa yang bertindak, atas apa, kapan, dan mengapa. Akses mengikuti prinsip least privilege, sehingga setiap operator hanya melihat dan melakukan apa yang diizinkan perannya. Inilah model di Protocore Center, konsol operator kami, dan pendekatan yang sama tertanam di setiap sistem pada platform: tindakan sensitif dilakukan dengan sengaja, dapat ditelusuri pelakunya, dan dapat ditinjau kembali.

  1. 01Baca luas, tulis terbatas — tindakan istimewa adalah pengecualian
  2. 02Alasan wajib diisi sebelum tindakan yang menyentuh dana
  3. 03Jejak audit permanen: siapa, apa, kapan, mengapa
  4. 04Least privilege untuk setiap peran operator

Jembatan kripto

Kripto dan fiat di ledger yang sama.

Kripto bukan silo terpisah di platform ini; alamat kripto hanyalah akun lain di ledger yang sama. On/off-ramp mengonversi antara fiat dan aset digital di tepi sistem — nasabah mengisi saldo dengan kartu atau transfer lalu menerima kripto, atau menjual kripto dan menarik dananya ke rekening bank. Nilai on-chain dapat diselesaikan hingga ke rel bank: pembayaran on-chain yang masuk dikreditkan ke akun, dikonversi, lalu dibayarkan ke IBAN, sehingga penerima melihat uang biasa di rekening bank biasa. Karena kedua sisinya diposting ke satu ledger double-entry, perpindahan yang bermula on-chain dan berakhir sebagai transfer bank menjadi satu riwayat yang terekonsiliasi, bukan dua sistem yang direkonsiliasi manual.

  1. 01Alamat kripto adalah akun seperti akun lainnya
  2. 02On/off-ramp: fiat dan aset digital dikonversi di tepi sistem
  3. 03Settlement on-chain hingga payout ke IBAN
  4. 04Satu riwayat terekonsiliasi di kedua sisi

Antarmuka pengembangan

API, webhook, dan sandbox untuk membangun.

Semua yang dilakukan aplikasi dijalankan lewat API yang terdokumentasi — membuat akun, membuka pembayaran, menerbitkan kartu, memulai ramp. Contoh panggilan seperti POST /v1/wallets atau POST /v1/payments; bentuknya REST dengan idempotency key pada setiap operasi tulis. Perubahan status dikirim sebagai webhook, sehingga sistem Anda bereaksi terhadap event, bukan melakukan polling. Pengembangan berlangsung di tenant sandbox — salinan platform yang terisolasi dengan rel uji, tempat Anda dapat menjalankan alur lengkap dari pembuatan hingga rekonsiliasi tanpa memindahkan uang sungguhan. Apa yang disediakan setiap produk, dan pada tier mana, ditentukan oleh access band-nya; halaman tiap produk merinci isi setiap band.

  1. 01REST API terdokumentasi, operasi tulis idempoten
  2. 02Webhook untuk setiap perubahan status — berbasis event, bukan polling
  3. 03Tenant sandbox dengan rel uji, terisolasi dari produksi
  4. 04Cakupan dan batas ditentukan oleh access band tiap produk

Batas yang jujur

Protocore membangun perangkat lunaknya. Lisensi memegang batas regulasi.

Produk pembayaran terdiri dari dua hal yang menyatu: izin regulasi untuk menyimpan dan memindahkan uang, serta perangkat lunak yang menginstruksikan, mencatat, dan merekonsiliasinya. Protocore membangun perangkat lunaknya. Aktivitas teregulasi — menyimpan dana nasabah, menerbitkan akun, memindahkan uang melalui skema — berada pada lisensi operator sendiri atau mitra berlisensi: bank, EMI, atau lembaga pembayaran. Platform ini dibangun agar sesuai dengan rel teregulasi apa pun yang Anda bawa, dan agar data kartu tetap berada di rel sehingga tidak pernah menyentuh server Anda; platform ini bukan pengganti izin tersebut, dan tidak ada perangkat lunak yang bisa. Di mana batas regulasi ditarik adalah keputusan yang Anda ambil bersama mitra Anda, dan arsitekturnya dirancang agar pas di kedua sisi batas itu.

  1. 01Lapisan perangkat lunak, bukan lisensi
  2. 02Aktivitas teregulasi berada pada operator atau mitra berlisensi
  3. 03Data kartu tetap di rel, di luar server Anda
  4. 04Dibangun agar sesuai dengan rel teregulasi yang Anda bawa

Ingin arsitektur untuk proyek Anda?

Ceritakan apa yang Anda bangun. Kami akan kembali dengan rancangan sistem dan posisi batas regulasi — bukan pitch deck.