Disbursement
Business Overview
MoneyCollect Fund Disbursement is a flexible fund distribution solution designed for merchants. In day-to-day operations, merchants not only need to collect payments from customers but also frequently face the need to distribute funds outward — for example, settling payments to suppliers, distributing commissions to distributors or agents, or issuing refunds to payers in scenarios such as transaction disputes or order cancellations.
MoneyCollect Fund Disbursement was built to address these exact scenarios. Through a standard API, merchants can flexibly transfer funds collected via payment acquiring to supported target platforms and beneficiary accounts. Currently, we support multiple transfer methods including instapay, instapay_qr, swiftpay_pesonet, coins, enabling precise and timely fund distribution to beneficiaries' bank accounts or e-wallets.
Compared to traditional offline remittance or manual operations, MoneyCollect Fund Disbursement offers the following core advantages:
Fully Automated Online Process: Merchants can complete the entire workflow — from creating a beneficiary to initiating a transfer — through a standard API, eliminating the need for manual intervention and significantly reducing operational costs.
Flexible Transfer Methods: Supports instapay, instapay_qr, swiftpay_pesonet, coins to meet different timing and amount requirements.
Complete Lifecycle Management: Transfers support a step-by-step "Create → Confirm → Complete" workflow. Merchants can review and confirm after creation, or cancel before confirmation to avoid accidental operations.
Security & Compliance: Every transfer requires signature verification and merchant authorization checks. Beneficiary information and transfer operations are subject to strict resource ownership validation to ensure fund security.
Business Workflow
The fund disbursement process consists of two core steps: Create a Beneficiary and Initiate a Transfer.
+-----------------------------------------------------------------+
| Fund Disbursement Workflow |
+-----------------------------------------------------------------+
| |
| Step 1: Create a Beneficiary |
| +--------------+ +--------------+ +------------------+ |
| | POST | | Provide | | Returns | |
| | /beneficiary|--->| beneficiary |--> | beneficiary ID | |
| | /create | | & bank info | | (ben_xxx) | |
| +--------------+ +--------------+ +------------------+ |
| | | |
| | (Optional) Retrieve/Update/Delete | |
| | | |
| v v |
| Step 2: Initiate a Transfer |
| +--------------+ +--------------+ +------------------+ |
| | POST | | Specify | | Returns | |
| | /transfer |--->| beneficiary |--> | transfer ID | |
| | /create | | amount etc | | (trf_xxx) | |
| +--------------+ +--------------+ +--------+---------+ |
| | |
| v |
| +------------------+ |
| | confirm = true? | |
| +---+----------+---+ |
| YES NO |
| | | |
| v v |
| +----------+ +----------+ |
| | Proceeds | | Awaiting | |
| | directly | | manual | |
| +----------+ | confirm | |
| +----+-----+ |
| | |
| POST | |
| /transfer/{id} | |
| /confirm <--------+ |
| | |
| v |
| +----------+ |
| |processing| |
| +----+-----+ |
| | |
| v |
| +------------------+ |
| | Bank callback | |
| | success/failed | |
| +------------------+ |
| |
+-----------------------------------------------------------------+Create a Beneficiary
Before initiating a fund disbursement, the merchant must first create a beneficiary, recording the beneficiary's identity, bank account, and address details. Once created, a unique ID is returned, and all subsequent transfer operations reference this ID.
The same beneficiary can be reused across multiple transfers, so merchants do not need to re-enter bank details for each transfer.
Beneficiary Endpoints
Request Example -- Create a Beneficiary
Response Example
Initiate a Transfer
Using the beneficiary ID created earlier, the merchant can initiate a transfer. When creating a transfer, the merchant specifies the order number, amount, currency, and other details, and can choose whether to confirm immediately (the confirm parameter defaults to true).
If
confirm = true: The transfer proceeds to processing immediately after creation.If
confirm = false: The transfer enters therequires_confirmationstate. The merchant must call the confirm endpoint to proceed, or call the cancel endpoint to abort the transfer.
Transfer results are delivered asynchronously via the notifyUrl configured by the merchant.
Transfer Endpoints
Request Example -- Create a Transfer
Response Example
Transfer Reason (reason) Options
wages_salary
Wages / Salary
business_expenses
Business Expenses
goods_purchased
Goods Purchased
freight
Freight / Logistics
bill_payment
Bill Payment
investment_capital
Investment Capital
investment_proceeds
Investment Proceeds
loan_credit_repayment
Loan / Credit Repayment
donation_charitable_contribution
Donation / Charitable Contribution
education_training
Education / Training
medical_services
Medical Services
real_estate
Real Estate
construction
Construction
living_expenses
Living Expenses
pension
Pension
technical_services
Technical Services
professional_business_services
Professional / Business Services
audio_visual_services
Audio-Visual Services
transfer_to_own_account
Transfer to Own Account
travel
Travel
taxes
Taxes
other_services
Other Services
Transfer Status Lifecycle
requires_confirmation
Pending confirmation — the transfer has been created but not yet confirmed; awaiting merchant to call the confirm endpoint
processing
Processing — the transfer is processing
sent
Sent — funds have been sent to the bank or platform
succeeded
Succeeded — the transfer has been completed successfully
failed
Failed — the transfer processing has failed
canceled
Canceled — the transfer has been canceled by the merchant
Signature header with SHA256withRSA
Signature Generation Rule:
Signature format:
requestPath: String of requestPath parameters for GET requests or POST requests.
Parameters must be sorted in ASCII order by key name.
The signature uses the concatenated values of these parameters (e.g., for bb=22&aa=11, the ordered values are 11 and 22, resulting in 1122).
requestParameters: String of request parameters for GET requests or POST form submissions.
Parameters must be sorted in ASCII order by key name.
The signature uses the concatenated values of these parameters (e.g., for bb=22&aa=11, the ordered values are 11 and 22, resulting in 1122).
requestBody: The body of the POST request (if present).
key:
For API requests, use the RSA PrivateKey.
If any of the required headers are not applicable for a specific API endpoint, their values should be set as empty strings. When constructing the signature string, omit the . separator if either requestBody or requestParameters is absent.
Example
beneficiary/create: Signature=SHA256withRSA (requestBody, privateKey)
beneficiary/{id}/update: Signature=SHA256withRSA (id + "." + requestBody, privateKey)
beneficiary/{id}: Signature=SHA256withRSA (id, privateKey)
beneficiary/{id}/delete: Signature=SHA256withRSA (id, privateKey)
RSA generate script
After generating the RSA public key (cert.crt) and private key (private_pkcs8.pem), please safeguard the private key securely and email the public key—along with your MID—to us.
Java demo
Last updated