Corea del Sur: cuentas virtuales, transferencias bancarias y botones KakaoPay/Toss

En un checkout coreano, un mismo botón puede esconder obligaciones muy distintas. La transferencia bancaria, la cuenta virtual para pagar un pedido y el easy-pay mediante KakaoPay o Toss Pay no deberían agruparse bajo una categoría común de «P2P local». Se inician, se confirman y se reembolsan de maneras diferentes. Para el procesamiento, se trata ante todo del ciclo de vida del pago.

Otra distinción útil: el servicio de consumo Toss Pay y la pasarela de pago Toss Payments no son el mismo nombre de método. La API de la pasarela presenta por separado TRANSFER, VIRTUAL_ACCOUNT y EASY_PAY. Con la palabra Toss no se puede saber si el comprador usó su cuenta bancaria, una tarjeta dentro de una interfaz cómoda u otro instrumento acordado.

Virtual account: primero los datos de depósito, después el dinero

En la integración de cuentas virtuales de Toss Payments, la llamada de confirmación emite los datos de depósito, no completa el pago. Hasta que llega el dinero el estado sigue siendo WAITING_FOR_DEPOSIT; cuando entra el monto correcto, pasa a DONE. Es una particularidad documentada de este producto. Si un desarrollador traslada la lógica del pago con tarjeta y entrega el producto apenas recibe una respuesta exitosa de la API, puede entregarlo a cambio de datos de depósito sin pagar.

Los campos paymentKey y orderId deben guardarse por separado. En virtualAccount están disponibles accountNumber, bankCode, customerName y dueDate; refundStatus y settlementStatus se describen aparte. Por eso un único indicador paid no puede expresar todo el ciclo. Una compra confirmada, un reembolso en proceso y una liquidación al comercio aún pendiente pueden corresponder al mismo pedido al mismo tiempo.

El registro interno debe vincular los datos emitidos con el monto exacto, el plazo y el intento de pago. Se recomienda guardar la hora en la zona horaria de origen y en una escala interna única para que los vencimientos no se desplacen durante el turno nocturno. Si el pedido se cancela antes del depósito, eso todavía no es un reembolso: aún no hay nada que devolver. El usuario debe ver la cancelación de la instrucción, no la promesa de un refund inexistente.

Un detalle inusual de la documentación: el estado puede retroceder

Toss Payments advierte sobre errores de depósito en los que DONE vuelve a WAITING_FOR_DEPOSIT. Además, suscribirse a la vez a PAYMENT_STATUS_CHANGED y a DEPOSIT_CALLBACK genera dos eventos sobre el mismo pago. Descripción de eventos. Es razón suficiente para no construir el procesamiento con la regla «una vez que vimos DONE, ya no leemos nada más».

La conclusión operativa: verificar la autenticidad del webhook según la instrucción vigente, guardar el historial de transiciones y enviar a revisión cualquier retroceso excepcional. No conviene pedirle automáticamente al comprador que deposite otra vez solo por un evento inconsistente. Primero se confirma el estado actual con el proveedor y se le explica al cliente la situación confirmada; de lo contrario, la excepción se convierte en un doble cobro y en un conflicto.

También está documentado que, con el monto correcto, el nombre del comprador y el de quien deposita pueden diferir sin que el pago por virtual account se rechace técnicamente. Eso no autoriza a ignorar la identificación del pagador en un negocio que tiene esa obligación. Que el ingreso se asocie correctamente por número de depósito y monto no demuestra que el origen del dinero pertenezca al cliente registrado.

Reembolso a una cuenta bancaria: aquí sí hacen falta datos adicionales

Para reembolsar una cuenta virtual ya pagada, Toss Payments exige los datos de refundReceiveAccount: banco, número de cuenta y nombre del titular. Antes del depósito, esos datos no son necesarios para cancelar. La documentación también indica una ventana limitada para obtener refundReceiveAccount mediante el flujo correspondiente de la interfaz: 30 minutos después de abrir la ventana de pago. La información recibida debe tratarse conforme a los requisitos de protección de datos acordados.

El nombre del titular no es un campo decorativo. La guía de métodos de pago señala por separado problemas al validar nombres de cuentas corporativas y nombres en alfabeto latino con espacios. Por eso el formulario de reembolso debe explicar que se requiere la grafía tal como figura en el banco, y soporte debe distinguir un error de nombre, un número incorrecto y una falla técnica. Un destino que no pasó la validación no se «corrige» poniendo a otro beneficiario.

La prueba práctica consiste en dos escenarios independientes: cancelar datos de depósito emitidos pero no pagados, y devolver un monto permitido después de un ingreso confirmado. Luego se revisan el reporte y el resultado real. Si el equipo solo demostró el primer escenario, su capacidad de hacer reembolsos de dinero todavía no está probada.

KakaoPay: volver con el token todavía requiere approve

En el pago único de KakaoPay primero se llama a ready con los datos del pedido y el CID, y se guarda el tid. Tras la autenticación del usuario llega el pg_token; el servidor llama a approve vinculándolo con tid, partner_order_id y partner_user_id. Las respuestas distinguen el tid del pago y el aid de cada solicitud concreta. Esto permite no perder el vínculo al cancelar y al investigar. Single-payment API.

Para el desarrollador no basta con el happy path. El usuario puede cerrar la página, abrir un segundo pedido o volver con retraso. La asociación del token con el contexto guardado correcto debe hacerse en el servidor. No se puede elegir «el último pedido de este teléfono». El dispositivo y la sesión ayudan a la interfaz, pero no reemplazan un vínculo inequívoco entre el intento financiero y el pedido.

El contrato define los métodos disponibles y la liquidación

KakaoPay describe una revisión del comercio antes de asignar el código de comercio. Toss Payments también remite a verificar los métodos habilitados por contrato. Tener credentials de prueba y el SDK instalado no significa que la empresa tenga derecho a activar cualquier método. En el mapa de lanzamiento se registran la persona jurídica, la categoría permitida, el MID/CID, los métodos y la cuenta de liquidación.

Un settlement report propio es necesario incluso con webhooks impecables. La API de Toss Payments ofrece información sobre liquidaciones y pagos al comercio; el calendario real y las retenciones se verifican según su contrato. Concilie pedidos, ingresos exitosos, cancelaciones y el neto a pagar. Así se distingue una compra técnicamente completada de una obligación del PSP que aún no se saldó con una transferencia bancaria.

El mercado de pagos coreano no es un permiso general para las apuestas

La legislación penal de la República de Corea regula por separado los juegos de azar y la organización de lugares o espacios para ellos. La legalidad de un casino en línea concreto no puede deducirse de la posibilidad de obtener una cuenta virtual o de procesar un pago con KakaoPay. Una licencia extranjera no sustituye la base local aplicable ni la aprobación del proveedor; disfrazar la categoría no es una solución aceptable.

Un buen checkout coreano exige menos conjeturas, no más botones. El comprador debe entender el siguiente paso, el operador debe ver un estado autoritativo, el contador debe encontrar la liquidación, y el reembolso debe completarse con un fundamento verificado y hacia los datos acordados. Eso es lo que distingue una aceptación comercial gestionada de un conjunto aleatorio de transferencias.