Bank transfers and supported wallet destinations
PAYJN’s published Indonesia payout coverage includes supported bank transfers and DANA, OVO, GoPay, LinkAja and ShopeePay wallet destinations. Confirm which destinations and beneficiary types are enabled for your merchant setup before submitting orders.
This is separate from collections. DANA pay-in is not currently open for merchant onboarding, while DANA payouts are listed separately. A supported payout destination does not establish a direct partnership or imply that wallet collection is also available.
Prepare a bank or wallet payout request
| Area | Confirm with the team |
|---|---|
| Beneficiary | Supported bank or wallet code and required destination fields |
| Amount and currency | Documented IDR representation, fees and current payout limits |
| Funding | Required balance, applicable charges and funding arrangements |
| Order reference | Stable merchant reference and supported retry rules |
| Status verification | Callback handling and the documented order-query process |
Use the codes and field formats from your approved PAYJN integration documentation. Do not substitute a wallet display name for its documented code, or apply the virtual account pay-in limits to a payout request.
How an Indonesia payout API flow works
A reliable payout integration separates "the request was accepted" from "the money arrived". Plan each step and the record your system keeps at that step.
- Fund the balance: make sure the payout balance covers the amount and charges before you submit, according to your agreed funding arrangement.
- Validate the beneficiary: check the bank or wallet code and destination fields, and use account validation where the route supports it.
- Create the payout with a unique reference: one business payout, one merchant reference. Store it before sending the request.
- Record the immediate response: an accepted or processing response means the request is being handled, not that the recipient has been paid.
- Confirm the final state: rely on the verified callback, and query the order status if the callback is late.
- Reconcile: match each payout against the transaction record and balance movements, including charges and any returned transfers.
Beneficiary validation before sending
Incorrect or outdated destination data is a common, preventable reason for rejected payouts. Validation before submission is cheaper than investigating a failed or misdirected transfer afterwards.
- Bank transfers: collect the bank code and account number in separate fields. Where the route offers an account inquiry, compare the returned account holder name with the name your user registered.
- E-wallet transfers: collect the identifier the wallet route requires, usually the phone number registered to the wallet, in one consistent format.
- Name mismatch: decide in advance whether a mismatch blocks the payout, sends it to manual review or is allowed for known cases. Do not silently correct names.
- Changed details: treat a newly changed destination as higher risk. A short review or cooling-off period before the first payout to a new account protects against account takeover.
Payout states and what your system should do
The exact status names come from your approved documentation. The handling below is what matters for avoiding duplicate or lost payouts.
| State | Meaning | What your system should do |
|---|---|---|
| Accepted / processing | The request is being handled | Wait for the callback or query; do not create a new payout |
| Successful | The payout completed on the provider side | Mark it paid, store the provider reference, notify the recipient |
| Failed | A final failure was returned | Record the reason; correct the data and create a new payout only after review |
| Pending for longer than expected | No final state yet | Query the status, then escalate with the reference instead of retrying |
| Returned or reversed | Funds came back after an earlier result | Reconcile the balance, update the payout record and contact the recipient |
Bank payouts compared with e-wallet payouts
| Bank transfer | E-wallet (DANA, OVO, GoPay, LinkAja, ShopeePay) | |
|---|---|---|
| Destination identifier | Bank code and account number | The identifier required by the wallet route, usually the registered phone number |
| Common rejection reasons | Invalid or closed account, name mismatch, unsupported bank code | Unregistered number, wallet account restrictions, recipient balance limits |
| Timing considerations | Can depend on the transfer route, bank operating hours and public holidays | Depends on the wallet route; confirm expected timing with the team |
| Typical fit | Seller settlements, larger payouts, B2B transfers | Creator rewards, smaller and frequent payouts to individuals |
Indonesian e-wallet accounts carry balance limits that depend on the account's verification level, so a payout that would push a recipient over their limit can be rejected. Ask recipients to verify their wallet if they expect larger payouts.
Funding, balance and scheduling
Payouts fail predictably when the balance runs out. Set an alert threshold above your normal daily payout total, and check the balance before releasing a large batch. Schedule batches with enough time to resolve rejections in the same working day, and plan around Indonesian public holidays, when bank-side processing can take longer. Agree with the team how charges are deducted, how returned transfers are credited back, and which report you will use for daily balance reconciliation.
Controls for creator, seller and agent payouts
Platforms paying many individuals need operational controls as much as an API. Before going live, decide:
- who approves payouts above a set amount, and whether large or first-time payouts need a second approval;
- daily and per-recipient limits in your own system, separate from provider limits;
- how a recipient changes their payout destination and how that change is verified;
- how you handle a recipient who reports non-receipt, including what evidence you ask for;
- which audit log records every payout request, approval, status change and support action.
The creator payout timeout and retry checklist applies these controls to live streaming, voice chat and social platforms. Licensed forex and futures-trading platforms should also read the forex broker onboarding checks before requesting withdrawal flows, and see client withdrawals for forex brokers for the supported setup.
Avoid duplicate payouts after a request timeout
A timeout means your application did not receive a conclusive response; it does not prove that the transfer failed. Preserve the existing order reference and follow the documented status-query and retry process before creating another instruction.
Confirm final transaction status on the backend. Repeated notifications must not trigger another payout, and a user refreshing a page must not create a second transfer.
For live streaming, voice chat and social platforms, the creator payout timeout and retry checklist covers pending transfer investigations, reconciliation and duplicate-payment tests.
Invalid fields and channel-unavailable responses
These messages need separate checks. An invalid-field response calls for reviewing the submitted value, required fields and expected format. A channel-unavailable response can require checking the approved method, merchant configuration or route status. The message alone does not establish bank maintenance or an incorrect bank code as the cause.
Send support the order reference, method, timestamp and sanitized error text. Share request details only through the agreed support process, with credentials and unrelated beneficiary information removed.
Successful payout, but the recipient has not received it
Ask PAYJN support to verify the recorded amount, destination, time and final order result, and to review the provider reference or transfer evidence where available. Agree the investigation steps and expected review timing for the specific route.
There is no single waiting period promised on this page for every bank and wallet. Further recipient-side evidence may be requested when necessary through the agreed channel; a full bank-history video is not a universal first requirement.
Request an Indonesia bank and wallet payout proposal
Provide your company website, registration jurisdiction, purpose of the payouts, beneficiary types, preferred bank or wallet destinations, average IDR amount and expected monthly volume and transaction count.
- Review merchant eligibility, destination coverage and required beneficiary fields.
- Request the payout fee schedule, funding arrangements, limits and handling of rejected or reversed transfers.
- Agree status queries, retry rules, reconciliation and support responsibilities before testing.
Request a payout integration review with this brief so the team can assess your proposed flow.
For receiving funds, compare virtual account collections and QRIS API integration. The Indonesia payment troubleshooting guide explains how to prepare an investigation brief.
Explore the integration approach · Chat on WhatsApp · Telegram
PAYJN provides payment technology and operational services, not banking services. Coverage, fees and operating terms depend on the approved merchant setup.