# Technical architecture

### Using Yumi as a BNPL Option (Onboarding)

* The entire flow takes place **within the merchant’s or PSP's UI**; integration is achieved via the SDK, which includes theming support.
* The user can l**ink a bank account** (optional) to receive asset statements and transaction + identity data. In the US, this is done via Plaid; in other locations, we use zkTLS.
* The user can also **connect** **EVM and/or SVM wallets**.
* If a bank is not connected, the user must **complete a zkKYC**.
* At least **one financial data source** (a wallet or a bank) is required.
* We are currently working to integrate with other data sources to improve coverage.

After onboarding, an initial **credit limit** is set based on financial data and **dynamically updated**.

### Payment

* The merchant queries Yumi for a **decision (limit/approval)**; the SDK returns a **callback** with the current **credit limit, approval (or rejection),** and additional loan information. The user's limit may change from purchase to purchase and after repayments.
* The **user sends 25%** of the purchase amount to the merchant, and **Yumi sends the other 75%**.

### Debt Repayment (Installments)

**Every 2 weeks**, Yumi automatically pulls the **scheduled installment** directly from the user’s wallet using the provided allowance (onchain or offchain), until the debt is fully repaid (**3 pulls in total**). If the user’s wallet does not have sufficient balance at the scheduled time, repayment will fail, and the user may incur penalties or risk a lowered credit score.

<figure><img src="https://439661759-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FXg9Y18a1AYeemkRuTkgR%2Fuploads%2F8kKL3mXLOylBu9Cf4UnJ%2Fimage.png?alt=media&#x26;token=0ecae030-1b0b-4086-a186-425a41132c50" alt=""><figcaption></figcaption></figure>