Indonesia Creator Payout API Timeout: Check Before Retrying

Separate the earning, payable and transfer

A live-streaming, voice-chat or social platform should reconcile customer purchases, creator earnings and outbound transfers separately. A successful gift purchase does not itself prove that a creator payment has been made or that a particular payout flow is approved.

Use three linked records: the earning calculation and adjustments, the approved amount payable to the creator, and each provider transfer attempt. This is a suggested platform ledger design. Confirm the real business model, beneficiary relationship and permitted funding flow with your provider before implementing it.

A six-step procedure for an uncertain payout

1. Lock the payable against parallel resubmission. Preserve its internal reference, amount, currency, beneficiary version, request time, provider reference if returned and the original idempotency key where the API supports one.
2. Classify the failure point. An application timeout or lost response does not establish whether the provider created a transfer. Separate this from a documented validation rejection or a confirmed final failed status.
3. Find the original transfer. Query by the provider ID when available, or use its approved reference lookup, dashboard or support procedure. A missing webhook alone is not proof of failure. If creation cannot be resolved, keep the item under investigation.
4. Apply the approved API’s retry contract. Xendit’s integration guide describes reusing the same idempotency key after an error or timeout to avoid duplicate creation. This is a supplier example: confirm your actual API version, key scope, retention period and matching-payload rules before relying on them. Do not treat a duplicate response as permission to create a new obligation.
5. Resolve the outcome before a replacement. For an in-progress transfer, continue tracking the original. For confirmed failure, review the reason, beneficiary and funding position before an authorised replacement. Correcting beneficiary details changes the instruction and requires a controlled new attempt under the provider’s rules.
6. Close the payable only through the agreed final-state policy. Link every attempt and any reversal to the same obligation. Reconcile provider transfers with the platform ledger; prevent support and batch workers from paying the same creator twice.

Hypothetical example: the response was lost

A platform approves one IDR 500,000 creator payable and sends a request with an internal reference and key. The connection times out before the response arrives. These values describe an invented scenario, not a PAYJN API contract.

The worker marks the outcome unknown and blocks a second worker. It retrieves the existing provider transfer, then records the current result against the same payable. If the API contract permits replaying the identical request with its original key, that replay is part of the same attempt. A fresh key would risk representing another instruction and must not be used as a shortcut around uncertainty.

Test these cases before releasing a payout batch

• Lost create-response followed by a delayed webhook; one obligation remains linked to one resolved transfer outcome.
• Two workers select the same payable; a lock or equivalent unique constraint prevents concurrent submissions.
• A repeated status event and a reconciliation query arrive together; no duplicate ledger posting occurs.
• A failure requires corrected recipient details; the replacement has an approval trail and remains linked to the original obligation.
• A previously successful transfer is reversed; the adjustment is recorded without silently reissuing money. Xendit’s lifecycle explicitly includes reversals, so confirm your own route’s equivalent handling.

Frequently asked questions

Can we mark every timeout failed and retry?

No. Resolve whether the original instruction was created. Use only the approved query and retry procedure.

Does a paid gift mean the creator payout is settled?

No. They are different transactions with separate references, counterparties and reconciliation states.

What should support receive?

Provide a redacted internal payable reference, provider ID if known, amount/currency, timestamps, current result and a retry history. Keep secrets and complete beneficiary account details in the agreed secure channel.

Official documentation and integration planning

Supplier documentation checked on 8 November 2026. Supplier API fields and status names are examples, not PAYJN specifications. Ask PAYJN to confirm business eligibility, creator-payment flow, funding, available routes and technical contract. This guide does not promise platform split payments, settlement timing or support for every industry.

• Xendit — payout idempotency and error handling
• Xendit — retrieve a created payout by ID
• Xendit — payout lifecycle and reversals
• Indonesia bank and wallet payout enquiries
• Other Indonesia payment investigations