> For the complete documentation index, see [llms.txt](https://docs.doku.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.doku.com/wallet-as-a-service/sub-account/collect-and-route.md). # Collect and Route Smart revenue routing for platforms. Accept payments, deduct commissions, and distribute funds to partners instantly with automated splitting. *** ## How It Works ```mermaid sequenceDiagram participant Merchant participant DOKU participant Bank Merchant->>DOKU: 1. Register Sub-Account DOKU-->>Merchant: profileId Merchant->>DOKU: 2. Create Split Rule DOKU-->>Merchant: splitRuleId Merchant->>DOKU: 3. Accept Payment (additionalInfo: account.id + splitRuleId) DOKU-->>Merchant: Payment success → funds in PENDING_IDR DOKU->>DOKU: 4. Settlement (split rule applied) DOKU-->>Merchant: Funds move to MERCHANT_IDR Merchant->>DOKU: 5. Transfer Inquiry DOKU-->>Merchant: referenceNo + beneficiary name Merchant->>DOKU: 6. Transfer Payment DOKU->>Bank: Payout to bank DOKU-->>Merchant: Webhook notification ``` *** ## Accept Payments To use Collect & Route, you accept payments through DOKU Checkout API or DOKU Direct API and include `additionalInfo` to tell DOKU which sub-account and split rule to apply. When creating a payment, add the `additionalInfo` object to your request body: ```json { "additionalInfo": { "account": { "id": "SAC-1670-1628490169910", "split_rule_id": "4ef065e3-8ffe-4c91-8ee2-d1b31a4da5b1" } } } ``` | Field | Type | Required | Description | | -------------------------------------- | ------ | -------- | ---------------------------------------------------------------------------------------------------------------------------- | | `additionalInfo.account.id` | string | Yes | The sub-account ID that receives the incoming payment. This is the `profileId` returned when you registered the sub-account. | | `additionalInfo.account.split_rule_id` | string | No | The split rule to apply to this payment. This is the `splitRuleId` returned when you created the split rule. | The `additionalInfo` object works with **DOKU Checkout API** (`POST /checkout/v1/payment`) and **DOKU Direct API** (all payment methods). See Payment Channel Compatibility for which channels support Sub-Account routing. {% tabs %} {% tab title="With Split Rule" %} Include `split_rule_id` to automatically split the payment across multiple sub-accounts based on your configured rule. ``` Customer pays Rp 500,000 │ ▼ Rp 500,000 held in DOKU_MERCHANT_PENDING_IDR (not yet split) │ ▼ at settlement PG fee deducted (e.g., Rp 5,000) │ ▼ Net amount: Rp 495,000 │ ▼ Split rule applied on net amount (95/5), into DOKU_MERCHANT_IDR: ├── Rp 470,250 → Seller sub-account └── Rp 24,750 → Platform fee ledger ``` > **Note:** The split is calculated on the **net amount after DOKU PG fees**, not the gross payment. See How Splitting is Calculated for details. Best for: **Marketplaces, platforms with commission models** — where every payment needs to be routed between multiple parties. {% endtab %} {% tab title="Without Split Rule" %} Omit `split_rule_id` to route the full payment amount directly into the specified sub-account. No splitting occurs. Best for: **Direct payments to a single party** — where the full amount belongs to one sub-account and you'll handle distribution later via the Transfer API. {% endtab %} {% tab title="Without additionalInfo.account" %} If you omit `additionalInfo.account` entirely, the payment is **not routed to any sub-account**. DOKU will auto-settle the funds directly to the merchant's main bank account at H+1. This is normal non-SAC payment behavior. > **Warning:** If you send an **invalid** `account.id` (e.g., account number instead of profileId), the API will NOT return an error. The payment succeeds but the transaction needs to be **resolved manually by the ops team**. Always validate that `account.id` is a valid profileId (format: `SAC-xxxx-xxxxxxxxxxxxx`) before sending. > {% endtab %} > {% endtabs %} *** ### Split Rules Split rules automate how incoming funds are distributed. Once configured, every qualifying transaction is split **at settlement** — when funds move from Pending IDR to Merchant IDR. | Type | How It Works | Example | | -------------- | ----------------------------------------- | ----------------------------------------- | | **PERCENTAGE** | Each party gets a percentage of the total | 95% to seller, 5% to platform | | **FLAT** | Each party gets a fixed amount | Rp 5,000 to platform, remainder to seller | > **Important:** The split is calculated on the **net amount after PG fees**, not the gross customer payment. **Setup:** 1. Add rules — specify the type (percentage or flat), the value, and the destination account 2. Call the Split Rules API — DOKU saves the rule and returns a `splitRuleId` 3. Pass `splitRuleId` in `additionalInfo` when accepting payments The payment first lands in `DOKU_MERCHANT_PENDING_IDR`, held and **not yet split**. At settlement the PG fee is deducted, the rule is applied to the net amount, and each destination receives a `SPLIT_TRANSACTION` credit into `DOKU_MERCHANT_IDR` — where it becomes payable. > **Split shares are not visible at payment time.** Until settlement completes, the funds sit unsplit in Pending IDR, so a seller checking their balance right after a customer pays will not see their share yet. > **Warning:** If you pass an **invalid** `split_rule_id`, the API will NOT return an error. The payment will land in the sub-account **without any splitting applied**. Always validate your `split_rule_id` before sending. *** > **Settlement:** Funds from Checkout/Direct API land in `DOKU_MERCHANT_PENDING_IDR` first. After settlement, they move to `DOKU_MERCHANT_IDR` and become available for payout. *** ### Payout to Bank Pay out funds to any of 100+ Indonesian bank accounts via **Transfer Inquiry** → **Transfer Payment**. | Channel | Description | | --------- | -------------------------------------------- | | `BI_FAST` | Indonesia's real-time payment rail (default) | | `ONLINE` | Standard online bank transfer | *** ### Step-by-Step Integration 1. **Register a Sub-Account** — `POST /sub-account/v2.0/register` → save the `profileId` 2. **Create a Split Rule** — `POST /sub-account/v2.0/split-rules` → save the `splitRuleId` 3. **Accept Payment** — Include both IDs in `additionalInfo` when calling Checkout API or Direct API 4. **Wait for Settlement** — Funds move from `DOKU_MERCHANT_PENDING_IDR` to `DOKU_MERCHANT_IDR`, split rule applied 5. **Payout** — Transfer Inquiry → Transfer Payment to bank account --- # 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://docs.doku.com/wallet-as-a-service/sub-account/collect-and-route.md?ask=&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.