Timeout en pagos a creadores en Indonesia: comprobar antes de reintentar

Separar ingresos, importe por pagar y transferencia

Una plataforma de directos, chat de voz o redes sociales debe conciliar por separado las compras de clientes, los ingresos de los creadores y las transferencias salientes. El pago correcto de un regalo no demuestra por sí solo que se haya pagado al creador ni que ese flujo de desembolso esté autorizado.

Utilice tres registros vinculados: el cálculo de ingresos y sus ajustes, el importe aprobado por pagar al creador y cada intento de transferencia del proveedor. Es una propuesta de diseño contable para la plataforma. Confirme el modelo real de negocio, la relación con el beneficiario y el flujo de financiación permitido con su proveedor antes de implementarla.

Procedimiento de seis pasos para un desembolso incierto

1. Bloquee la obligación frente a envíos simultáneos. Conserve su referencia interna, importe, divisa, versión de los datos del beneficiario, hora de solicitud, referencia del proveedor si se recibió y clave de idempotencia original cuando la API la admita.
2. Identifique dónde ocurrió el error. Un timeout de la aplicación o una respuesta perdida no demuestra si el proveedor creó una transferencia. Distíngalo de un rechazo de validación documentado o de un estado final fallido confirmado.
3. Localice la transferencia original. Consulte por el identificador del proveedor cuando lo tenga, o use su búsqueda por referencia, panel o procedimiento de soporte autorizado. La falta de un webhook no prueba un fallo. Si no puede determinar si se creó, mantenga el caso en investigación.
4. Aplique el contrato de reintentos de la API aprobada. La guía de Xendit describe reutilizar la misma clave de idempotencia tras un error o timeout para evitar una creación duplicada. Es un ejemplo de ese proveedor: confirme la versión real de su API, el alcance de la clave, su vigencia y las reglas sobre solicitudes idénticas. Una respuesta de duplicado no autoriza a crear una obligación nueva.
5. Resuelva el resultado antes de sustituir la transferencia. Si sigue en curso, continúe siguiendo la original. Ante un fallo confirmado, revise la causa, el beneficiario y los fondos antes de autorizar un reemplazo. Corregir los datos del beneficiario cambia la instrucción y exige un nuevo intento controlado conforme a las reglas del proveedor.
6. Cierre la obligación únicamente según la política acordada de estados finales. Vincule todos los intentos y cualquier reversión a la misma obligación. Concilie las transferencias del proveedor con el libro de la plataforma; evite que soporte y los procesos por lotes paguen dos veces al mismo creador.

Ejemplo hipotético: se perdió la respuesta

Una plataforma aprueba un único importe de IDR 500.000 por pagar a un creador y envía una solicitud con referencia interna y clave. La conexión agota el tiempo de espera antes de recibir la respuesta. Son datos de un caso ficticio, no un contrato de API de PAYJN.

El proceso marca el resultado como desconocido y bloquea a un segundo proceso. Recupera la transferencia existente del proveedor y registra el resultado actual contra la misma obligación. Si el contrato de la API permite repetir una solicitud idéntica con su clave original, esa repetición forma parte del mismo intento. Una clave nueva podría representar otra instrucción y no debe utilizarse como atajo ante la incertidumbre.

Pruebas antes de liberar un lote de desembolsos

• Respuesta de creación perdida seguida de un webhook retrasado: una obligación queda vinculada a un único resultado de transferencia resuelto.
• Dos procesos seleccionan el mismo importe por pagar: un bloqueo o una restricción única equivalente impide envíos concurrentes.
• Un evento de estado repetido coincide con una consulta de conciliación: no se duplica el asiento contable.
• Un fallo exige corregir al destinatario: el reemplazo conserva un historial de aprobación y sigue vinculado a la obligación original.
• Una transferencia antes exitosa se revierte: se registra el ajuste sin volver a enviar dinero automáticamente. El ciclo de Xendit incluye expresamente reversiones; confirme el tratamiento equivalente de su ruta.

Preguntas frecuentes

¿Podemos marcar todos los timeouts como fallidos y reintentar?

No. Determine si se creó la instrucción original. Utilice exclusivamente el procedimiento aprobado de consulta y reintento.

¿Un regalo pagado implica que el desembolso al creador está liquidado?

No. Son transacciones diferentes, con referencias, contrapartes y estados de conciliación separados.

¿Qué información necesita soporte?

Facilite una referencia interna de la obligación con los datos sensibles ocultos, el ID del proveedor si lo conoce, importe y divisa, marcas de tiempo, resultado actual e historial de reintentos. Mantenga los secretos y los datos completos de la cuenta del beneficiario en el canal seguro acordado.

Documentación oficial y preparación de la integración

Documentación del proveedor consultada el 8 de noviembre de 2026. Sus campos de API y estados son ejemplos, no especificaciones de PAYJN. Solicite a PAYJN que confirme la elegibilidad del negocio, el flujo de pagos a creadores, la financiación, las rutas disponibles y el contrato técnico. Esta guía no promete reparto de pagos de plataformas, plazos de liquidación ni admisión de todos los sectores.

• Xendit — idempotencia y gestión de errores de desembolso (en inglés)
• Xendit — consultar un desembolso creado por ID (en inglés)
• Xendit — ciclo del desembolso y reversiones (en inglés)
• Consultas sobre desembolsos bancarios y a monederos en Indonesia (en inglés)
• Otras investigaciones de pagos en Indonesia (en inglés)