> For the complete documentation index, see [llms.txt](https://payana-saas.gitbook.io/payana-saas-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://payana-saas.gitbook.io/payana-saas-docs/pengenalan/solusi.md).

# Solusi Payana

Payana menjawab keempat masalah di halaman sebelumnya dengan satu prinsip desain: **pindahkan sumber kebenaran ke blockchain**, lalu bangun pengalaman pengguna di atasnya yang terasa semudah aplikasi keuangan biasa.

## Gaji mengalir, bukan menumpuk lalu dicairkan sekaligus

Setiap `CompanyVault` menjalankan mekanisme *salary streaming* — begitu HR memulai stream untuk seorang karyawan (`startStream`), saldo yang bisa ditarik karyawan itu bertambah terus secara linear terhadap waktu, dihitung langsung dari `flowRate` dan `startTs` yang tercatat on-chain. Ini yang memungkinkan fitur **Earned Wage Access**: karyawan bisa memanggil `claimSalary()` kapan saja, menarik persis sebesar apa yang sudah mereka hasilkan sampai detik itu — bukan estimasi, bukan potongan di muka.

## Kasbon menggantikan pinjol — tanpa bunga pihak ketiga

Alih-alih meminjam dari pihak luar dengan bunga, karyawan bisa menarik **kasbon**: uang muka dari gaji yang *sudah* mereka hasilkan (bukan gaji masa depan), dibatasi maksimum 80% dari saldo terakumulasi (`MAX_ADVANCE_BPS`), dan dilunasi otomatis 20% per siklus klaim berikutnya (`ADVANCE_REPAY_BPS`) — langsung dari smart contract yang sama, tanpa perantara, tanpa bunga eksternal, karena ini uang mereka sendiri yang dipercepat aksesnya.

## Aturan payroll & pajak yang ditulis di kode, bukan spreadsheet

Potongan BPJS dan PPh21 dikonfigurasi per perusahaan di level kontrak, dihitung otomatis setiap kali gaji diklaim, dan diindeks real-time oleh `payana-indexer` ke dalam tabel yang bisa dibaca kapan saja oleh HR lewat dashboard compliance — lengkap dengan ekspor Excel/CSV untuk pelaporan resmi. Karena perhitungan terjadi di kontrak yang sama untuk semua karyawan, tidak ada spreadsheet yang bisa "salah rumus" secara diam-diam.

## Identitas kerja yang bisa diverifikasi siapa saja

Setiap karyawan yang terdaftar mendapat **Employment SBT** — token ERC-5192 yang terikat permanen ke alamat mereka (tidak bisa dipindahtangankan atau dipalsukan), berisi nama perusahaan, tanggal mulai kerja, dan status. Siapa pun — bank, platform lain, calon employer berikutnya — bisa memverifikasinya lewat halaman publik `/verify` tanpa perlu menghubungi HR sama sekali.

## Semua tanpa beban teknis ke pengguna

Di balik layar ini semua adalah interaksi blockchain, tapi karyawan dan HR tidak pernah melihatnya sebagai itu:

* **Login** semudah aplikasi biasa — email atau Google, lewat Privy — bukan menyambungkan wallet dan menghafal seed phrase.
* **Setiap transaksi gasless** — setiap `CompanyVault` bertindak sebagai *Paymaster* ERC-4337 miliknya sendiri, jadi karyawan tidak pernah perlu memegang ETH untuk membayar gas.
* **Antarmuka terasa seperti aplikasi keuangan modern** — bukan dashboard kripto dengan istilah teknis yang membingungkan.

Detail teknis lengkap tentang bagaimana keempat lapisan sistem ini bekerja sama ada di [Arsitektur](/payana-saas-docs/arsitektur/arsitektur.md). Untuk gambaran dampaknya, lanjut ke [Dampak & Manfaat](/payana-saas-docs/pengenalan/dampak.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://payana-saas.gitbook.io/payana-saas-docs/pengenalan/solusi.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.