Guía de preautorización y reembolsos para la carga de vehículos eléctricos

1. Por qué la carga de vehículos eléctricos a veces utiliza una retención de pago

Al inicio de una sesión de carga, el operador puede desconocer la cantidad final de energía suministrada o su duración. La preautorización es una forma de verificar la disponibilidad de fondos antes de prestar un servicio con un importe variable. No es el único modelo: las billeteras digitales, los saldos prepago y la facturación de cuentas siguen flujos de trabajo diferentes.

El importe de la autorización debe reflejar una política comercial documentada. Una retención excesivamente alta puede frustrar a los conductores, mientras que un importe demasiado bajo para la sesión prevista puede generar riesgos de impago. El enfoque adecuado depende de su público objetivo, el proveedor de pagos, la duración media de la sesión y las opciones de captura compatibles.

Para la distinción básica, consulte Documentación de Stripe sobre autorización y captura por separadoDicha documentación describe los métodos elegibles y la caducidad de la autorización. Esto no significa que todas las pasarelas de pago o métodos de pago locales utilicen las mismas reglas.

2. Mantén separadas la autorización, la captura, la cancelación y el reembolso.

Estos términos son importantes porque la siguiente acción depende del estado actual. Una sesión que nunca se inició podría requerir una cancelación de autorización. Una sesión completada y registrada con un cargo incorrecto podría requerir un reembolso parcial. Llamar a ambas situaciones "reembolsadas" hace que los conductores se pregunten por qué su extracto bancario se ve diferente.

El estado del pago debe mantenerse separado del estado del cobro. "Cobro completado" no prueba que la recaudación se haya realizado correctamente, y "pago autorizado" no prueba que se haya suministrado electricidad. Sus registros deben vincular ambos procesos sin tratarlos como un mismo evento.

3. Diseñar el flujo normal de la sesión.

Antes del pago, muestre la tarifa, los cargos adicionales y la retención propuesta en un lenguaje claro. Explique que la autorización es temporal y que el cargo final depende de la sesión. Incluya esta información donde el conductor toma la decisión de pago, no solo en una página de términos y condiciones.

Tras la autorización, solicite el inicio de la carga y espere la documentación correspondiente del cargador. Guarde el identificador de sesión y la referencia de pago. Si el cargador no se inicia según el flujo de trabajo acordado, muestre un estado útil y siga el proceso de cancelación o investigación definido.

Al finalizar la sesión, calcule la tarifa a partir de los datos registrados y la tarifa aplicable. Envíe la acción de captura compatible, registre su resultado y emita un recibo con el importe final. El recibo debe identificar el sitio, el conector, el período de tiempo, el importe facturado y la vía de soporte.

En un ejemplo simplificado, un operador autoriza $30 y la tarifa de sesión verificada es de $8.40. Si el proveedor admite el flujo de trabajo de captura parcial acordado, el sistema cobra $8.40 y gestiona la autorización no utilizada según las reglas del proveedor. Esta es una transacción ilustrativa, no un monto de retención recomendado.

4. Define qué sucede cuando el viaje se interrumpe.

Consideremos el caso en que la autorización se realiza correctamente, pero el cargador rechaza la solicitud de inicio. La plataforma no debe interpretar la aprobación del pago como un servicio de carga completado. Debe vincular el inicio fallido con el pago correspondiente y seguir la política de cancelación documentada.

Otro caso común es la interrupción de la conexión al finalizar la carga. El valor final del contador puede llegar más tarde de lo previsto en el flujo de pago. Defina cómo el sistema espera, reintenta o escala el problema sin generar un importe final ficticio. Si se pueden recuperar datos locales, utilice esa información mediante el proceso de conciliación acordado.

Una sesión también puede costar más que la autorización inicial. No dé por sentado que la plataforma puede simplemente cobrar cualquier cantidad mayor. Es posible que se requiera una autorización adicional, una autorización incremental o un método de cobro diferente, según el soporte del proveedor y la configuración comercial. Defina este comportamiento antes del lanzamiento.

Si la autorización caduca antes de la captura, trátela como una excepción específica con un responsable. Los periodos de validez admitidos varían, por lo que la integración debe utilizar el estado de pago y la información de caducidad del proveedor, en lugar de una fecha límite fija universal.

5. Otorgar a los reembolsos su propio flujo de trabajo auditable.

Un reembolso comienza con un pago ya cobrado. El operador necesita un motivo, un importe aprobado y un enlace a la transacción original. El sistema debe registrar quién lo solicitó, quién lo aprobó (cuando corresponda) y si el proveedor aceptó, completó o rechazó la solicitud.

Los reembolsos parciales son útiles cuando solo se necesita corregir una parte del cargo. Por ejemplo, el cargo por energía puede ser válido, pero se debe devolver un cargo por inactividad aplicado incorrectamente. Conserve el recibo original y registre el ajuste en lugar de modificar el historial de la transacción sin previo aviso.

Documentación de reembolsos de Stripe Distingue entre cancelar pagos incompletos y reembolsar pagos exitosos, y describe los resultados pendientes o fallidos. Establezca procedimientos de soporte en función de los estados del proveedor. Una solicitud de reembolso enviada no debería convertirse automáticamente en un mensaje que indique que el dinero ha llegado al conductor.

Evite prometer un plazo fijo para la liberación o el reembolso, a menos que las condiciones del proveedor y del banco emisor lo permitan. Explique el procedimiento que ha seguido su sistema y proporcione al cliente una referencia de pago para su seguimiento.

6. Hacer que la integración sea resistente a eventos repetidos o retrasados.

Las notificaciones de pago forman parte del diseño operativo, no del funcionamiento interno. Un conductor puede cerrar el navegador, la conexión móvil puede interrumpirse y el proveedor de pagos puede enviar una notificación incluso después de que la pantalla de carga visible haya dejado de actualizarse. El sistema backend aún necesita alcanzar el estado financiero correcto.

Utilice notificaciones de proveedores verificados y compruebe el objeto de pago actual cuando sea necesario. Registre los identificadores de eventos, proteja las acciones contra el procesamiento duplicado y tenga en cuenta los eventos que llegan fuera de secuencia. Una notificación repetida no debe generar una segunda captura ni un segundo reembolso.

Documentación de webhooks de Stripe Explica el manejo asíncrono de eventos, la verificación de firmas y las consideraciones de entrega. Su implementación debe cumplir con los requisitos del proveedor seleccionado. Desde el punto de vista operativo, el personal también necesita una cola de casos sin resolver en lugar de un panel de control verde que oculte las notificaciones faltantes.

El existente Guía de integración de la API de carga de vehículos eléctricos Proporciona un contexto más amplio para conectar la plataforma con los sistemas de pago y de negocio. Defina explícitamente el modelo de estado de pago en el alcance del proyecto.

7. Conciliar los registros de sesión, pago y liquidación.

Un útil resumen diario conecta tres aspectos: lo que entregó el cargador, lo que se le cobró al conductor y lo que informa el proveedor para la liquidación. Compare los registros usando identificadores estables, no solo un monto y un tiempo aproximado. Dos conductores diferentes pueden tener sesiones con precios idénticos.

Se deben marcar las sesiones sin pago completado, los pagos sin sesión correspondiente, las capturas duplicadas y los reembolsos pendientes de resolución. Asigne cada excepción al equipo que pueda investigarla. El departamento de finanzas también debe comprender cómo se visualizan las comisiones de los proveedores y los ajustes de liquidación.

Los pagos directos con tarjeta y la liquidación en roaming son relaciones diferentes. Si el conductor cobró a través de un proveedor de movilidad externo, la conciliación comercial puede depender de los registros y facturas del socio. Para ese flujo de trabajo, lea La guía para la conciliación de roaming desde los CDR hasta la liquidación. en lugar de aplicar un procedimiento de tarjeta directa sin cambios.

8. Pruebe los casos incómodos antes del lanzamiento.

Ejecuta pruebas controladas para autorización rechazada, autorización exitosa seguida de un inicio fallido, captura parcial normal, devoluciones de llamada duplicadas, registro de sesión final retrasado y autorización caducada. Agrega reembolsos totales y parciales, incluyendo un reembolso que queda pendiente o falla.

En cada caso, verifique cuatro aspectos: el mensaje del conductor, el estado de la sesión de carga, el estado del pago del proveedor y el registro financiero. Los cuatro deben reflejar información coherente. Una solicitud a la API que sea técnicamente exitosa aún puede generar una experiencia confusa para el cliente si la redacción describe el evento incorrecto.

Haga que el personal de soporte ensaye la explicación de la retención pendiente. Deben poder encontrar la autorización, el cargo final y la referencia correspondiente sin solicitar información bancaria innecesaria al cliente.

Preguntas frecuentes

¿La retención del pago de la carga del vehículo eléctrico supone un cargo adicional?

Una retención reserva fondos; no necesariamente se trata de un cargo adicional completado. Los conductores deben verificar si el monto está pendiente o liquidado. Los operadores deben proporcionar el recibo final e investigar cualquier discrepancia entre el monto registrado y la tarifa de sesión verificada.

¿Pueden todos los métodos de pago utilizar la preautorización?

No. La compatibilidad depende del método, el proveedor, la configuración del comercio y la región. Algunos procesos de pago requieren un modelo de prepago, pago inmediato o facturación a cuenta. Confirme la integración real antes de promocionar una experiencia de pago específica.

¿Por qué puede estar pendiente un reembolso?

El resultado depende del proveedor y del estado de la transacción, y la finalización puede requerir la intervención del banco emisor. El equipo de soporte debe distinguir entre una solicitud de reembolso y un reembolso completado, y utilizar la referencia del proveedor al investigar el caso.