# Partner fees

Ghana-first published schedule. **List prices are commercial terms** — per-merchant overrides are issued only after [apply-for-access](../partners/GETTING_STARTED.md#request-access).

## Two rails

| Rail | Platform fee | Applies to |
|------|----------------|------------|
| **P2P** | **0%** | Person → person in the Sika wallet |
| **Commerce** | **1.5%** list (150 bps) | Merchant QR, pay links, API-minted `/pay` intents, checkout |

**MoMo / bank aggregation** (when enabled later) is quoted as a **separate rail fee** (`railFeeBps` / `railFeeAmount`). It is **never folded silently into** the 1.5% platform list. Confirm UI and API show platform and rail as distinct lines; settlement uses an additional transfer leg to a rail collector account when `railFeeBps > 0`.

Protocol resource costs (CPU/NET/RAM on Vaulta/EOS) are separate from the Sika commerce take rate. Do not describe RAM fees as “Sika platform fee.”

## Commerce tiers

| Tier | Fee | Who |
|------|-----|-----|
| **List** | **1.5%** | Default for hotels, restaurants, SMEs, marketplaces |
| **Pilot / intro** | 1.0% | Time-boxed, approved pilots only |
| **Volume** | 0.8–1.2% | Contracted after volume review |
| **Strategic (banks / large chains)** | 0.5–0.8% | Negotiated only |
| **Marketplace (multi-seller)** | 1.5–2.0% | Higher support surface |

## Who pays

**Merchant-absorbed by default.** The customer pays the face amount; the merchant receives net of fee.

Example at **1.5%**:

- Customer pays **GHS 100.00**
- Merchant receives **GHS 98.50**
- Sika fee **GHS 1.50**

Optional later: customer surcharge mode (both lines shown at confirm). Not the launch default.

## Settlement rules

**Chain (gh-v1):** Sika App deploys on **EOS / Vaulta**. Commerce fees use the **same token contract as the payment** — typically native **`core.vaulta` / `A`**, or a configured stablecoin if that is what the intent sends. There is **no custom fee smart contract**; settlement is two standard `transfer` actions.

- Fee is charged only when the signed transfer **settles**
- Expired or cancelled intents: **no fee**
- Merchant / API intents with `feeBps > 0` settle as **two transfers in one transaction**: net → merchant, platform fee → `NEXT_PUBLIC_COMMERCE_FEE_ACCOUNT`
- When `railFeeBps > 0` (MoMo/bank later), add a **third** transfer to `NEXT_PUBLIC_COMMERCE_RAIL_FEE_ACCOUNT` — do not increase the 150 bps platform leg
- Plain P2P (no merchant / `feeBps: 0`) stays a single transfer
- Fee account, `feeBps`, and `railFeeBps` are server-issued — partners cannot lower fees from the client
- Deploy must set `NEXT_PUBLIC_COMMERCE_FEE_ACCOUNT` to a **Vaulta account that can receive that token** (and optionally `COMMERCE_FEE_ACCOUNT`) or commerce intents refuse to send
- Do **not** point the fee account at a SikaChain-only `sika.token` setup for this deploy

## UX

Always show before confirm:

1. Amount  
2. Platform fee (e.g. 1.5%)  
3. Rail fee (only when `railFeeBps > 0`)  
4. Network / resources (if any)  
5. **Merchant receives** (emphasized)

Never bury the platform fee inside “network fee.” Rail fees are a separate line and are not part of the 1.5% platform list.

## API quote fields

Partner responses should expose:

```json
{
  "amount": "100.0000",
  "feeBps": 150,
  "feeAmount": "1.5000",
  "platformFeeBps": 150,
  "platformFeeAmount": "1.5000",
  "railFeeBps": 0,
  "railFeeAmount": "0.0000",
  "netToMerchant": "98.5000"
}
```

(`feeBps` / `feeAmount` remain aliases of the platform take for backward compatibility. Precision matches the intent token — typically 4 for `core.vaulta` / `A`.)

**Minimum face amount:** at list **150 bps** and precision **4**, the fee must round to at least `0.0001` of the token — amounts so small that the fee becomes `0.0000` are rejected at mint and blocked in the wallet.

Helpers: repo `src/app/_lib/partnerFees.ts` and `src/sdk/partnerPay.ts` (not served from this public docs path).