Cómo responder a una RFP de un cliente que exige una opción de pago cripto

La respuesta debe convertir una exigencia amplia en una decisión operativa

Una RFP puede resumir el requisito en una sola línea: «el proveedor debe ofrecer una opción de pago cripto». Responder con un sí, una lista de activos o una descripción comercial deja sin resolver lo importante. Compras necesita comparar propuestas; ventas debe proteger el alcance contratado; tesorería necesita saber qué importe reconocerá y cómo conciliará; el equipo técnico debe entender qué estados intercambiará. Una respuesta sólida transforma esa línea en condiciones verificables.

El primer paso es separar tres objetos que suelen mezclarse. La obligación comercial nace del contrato, pedido o factura. La instrucción de pago indica importe, activo, red, dirección o página, referencia y vencimiento. La evidencia de pago demuestra qué ocurrió y permite aplicar el cobro a la obligación correcta. Un movimiento visible en una red no modifica por sí solo el contrato ni explica qué factura liquida.

La respuesta ejecutiva puede abrir con cinco declaraciones:

1. el caso de uso cubierto: cobro de facturas, pedidos, anticipos o renovaciones;
2. las entidades que contratarán, facturarán, pagarán y prestarán el servicio;
3. el modelo de integración propuesto, sujeto a validación técnica;
4. los campos que todavía debe decidir el cliente;
5. las evidencias que el proveedor entregará durante la evaluación.

Este enfoque evita prometer una configuración antes de conocerla. Una solicitud de pago vinculada a una factura puede ser adecuada para operaciones asistidas, mientras que una integración mediante API puede encajar cuando el cliente necesita crear solicitudes y recibir estados desde sus sistemas. La respuesta no debe asumir una modalidad: debe relacionarla con volumen operativo, frecuencia, sistemas implicados y tratamiento de excepciones.

Incluya una matriz de propiedad con cuatro columnas: requisito, decisión del cliente, documentación del proveedor y responsable de aceptación. El proveedor puede describir el flujo disponible y aportar documentación vigente. El cliente debe decidir su política contable, el alcance contractual, los activos aceptables para su tesorería y quién autoriza excepciones. Si una decisión depende de ambas partes, no la esconda bajo «estándar»: conviértala en un punto de diseño con fecha y aprobador.

Requisitos comerciales, roles y unidad de cuenta

La sección comercial debe comenzar por la obligación que se pretende liquidar. Identifique el documento de origen, la entidad acreedora, la entidad pagadora, la referencia del pedido, el impuesto aplicable según la documentación del cliente y el evento que habilita la entrega. No corresponde al proveedor de pagos decidir cuándo una factura se considera jurídicamente satisfecha; sí puede explicar qué estado técnico genera y qué datos lo acompañan.

La RFP debería resolverse con una tabla como esta:

La divisa contractual y el activo utilizado para pagar no son equivalentes. Una propuesta puede estar denominada en euros, dólares u otra unidad de cuenta, mientras la instrucción solicita una cantidad de un activo concreto. La respuesta debe indicar cuál es la fuente contractual del importe, cuándo se obtiene una cotización, durante cuánto tiempo se mantiene y qué ocurre al vencer. Si esos parámetros no se han acordado, deben figurar como campos por confirmar, no como capacidades prometidas.

La misma disciplina se aplica a activos y redes. No basta con escribir «USDT» o «Bitcoin». Para cada opción deben confirmarse el activo, la red, la combinación admitida para ese flujo y la instrucción que verá el pagador. La página de activos admitidos sirve como inventario de consulta, pero la respuesta a la RFP debe limitarse a la disponibilidad validada para la entidad, el producto y la integración evaluados. La elección de red para pagos en USDT muestra por qué activo y red deben tratarse como campos separados.

Añada un anexo de decisiones abiertas. Para cada campo registre opciones, propietario, fecha límite y consecuencia de no decidir. Así compras puede comparar una respuesta condicionada de forma transparente en vez de interpretar silencios como compromisos.

Cotización, vencimiento y evidencias para cada estado de pago

Una respuesta útil describe el ciclo completo de la instrucción. Debe explicar cómo se crea, qué importe muestra, qué referencia conserva, cuándo vence y qué estados puede emitir el sistema. Evite términos como «pagado» sin definición: tesorería, soporte y el sistema del cliente pueden atribuirle significados distintos.

Para cotización y vencimiento, detalle los campos que estarán en el diseño final:

• unidad de cuenta e importe comercial;
• activo y red seleccionados;
• cantidad solicitada del activo;
• momento de creación y momento de expiración;
• identificador único de la solicitud;
• referencia de pedido o factura;
• estado actual y marca temporal del cambio;
• regla prevista cuando el pago se observa después del vencimiento.

El proveedor puede documentar qué campos y eventos ofrece. El cliente debe decidir la duración comercial aceptable, si una solicitud vencida puede reabrirse y quién asume la revisión de una diferencia. Una guía sobre facturación B2B en USDT puede ayudar a alinear factura, solicitud y referencia, pero no reemplaza la regla contractual acordada.

La evidencia no debería reducirse a una captura de pantalla. Defina un expediente mínimo por operación: identificador interno, referencia comercial, activo, red, importe solicitado, importe observado, marcas temporales, identificador de transacción cuando corresponda, historial de estados y registro de intervenciones manuales. Indique qué evidencia llega por interfaz, API, evento o exportación, sin afirmar formatos que todavía no se hayan comprobado.

Los pagos incompletos, excedidos o tardíos necesitan reglas separadas. Ante un importe inferior, el sistema puede detectar una diferencia si dispone de ambos valores; el cliente decide si solicita el saldo, rechaza la operación, la mantiene pendiente o aplica otra política. Ante un importe superior, el cliente define si existe devolución, crédito o revisión. Ante un pago posterior al vencimiento, debe decidir si conserva la cotización anterior, recalcula, devuelve o escala. El proveedor documenta datos y mecanismos disponibles; no debe atribuirse una decisión financiera que pertenece al comercio.

También conviene diferenciar «detectado», «en proceso», «confirmado para el flujo acordado», «vencido» y «requiere revisión», siempre que esos estados existan en la solución finalmente validada. La RFP debe exigir un diccionario de estados y transiciones, no una promesa genérica de confirmación instantánea.

Conciliación, pagos excepcionales y devoluciones

La conciliación empieza por una clave estable. Cada solicitud debe poder relacionarse con la obligación correcta sin depender de buscar importes parecidos o copiar direcciones manualmente. La respuesta debe mostrar el recorrido de la referencia desde el ERP, CRM o sistema de pedidos hasta la solicitud y de vuelta al registro financiero. El artículo sobre conciliación de pagos cripto amplía este principio operativo.

Proponga una matriz de conciliación con estos datos: identificador comercial, identificador de solicitud, unidad de cuenta, importe comercial, activo, red, cantidad solicitada, cantidad recibida, estado, marcas temporales y causa de excepción. Si algún campo no está disponible, declárelo. Si requiere transformación o desarrollo, ubíquelo en el plan de integración, con responsable y prueba.

La política de excepciones pertenece al cliente, pero el proveedor debe demostrar que la operación puede investigarse. La respuesta debería cubrir, al menos:

• pago por debajo o por encima de la cantidad solicitada;
• pago recibido después del vencimiento;
• activo correcto enviado por una red distinta;
• transacción observada sin referencia comercial suficiente;
• solicitud duplicada o intento repetido;
• reversión comercial solicitada después de la entrega;
• discrepancia entre el estado del proveedor y el sistema del cliente.

Para cada caso indique señal de detección, datos disponibles, cola responsable, plazo de revisión que se propondrá para el SLA y autoridad para resolver. No prometa recuperación automática de fondos ni resolución universal. Algunas combinaciones erróneas pueden requerir investigación y su resultado depende de las circunstancias técnicas y operativas.

Las devoluciones merecen un flujo propio. El cliente decide motivos permitidos, aprobadores, relación con notas de crédito, activo de devolución, tratamiento de diferencias y controles de dirección. El proveedor puede explicar el mecanismo disponible, los datos requeridos y la evidencia generada. La guía de reglas de devolución ayuda a ordenar esas decisiones sin confundir devolución comercial con reversión de una transacción en red.

Exija segregación entre quien solicita, quien aprueba y quien ejecuta una devolución cuando la política interna lo requiera. La propuesta debe decir cómo se registran usuario, motivo, referencia, fecha y resultado. Si esa capacidad no ha sido validada, debe quedar como requisito sujeto a demostración, no como afirmación.

Seguridad y cumplimiento: evidencia del proveedor, decisiones del cliente

La sección de seguridad debe responder con documentos y controles verificables, no con adjetivos. Una RFP seria puede pedir arquitectura relevante para la integración, autenticación, gestión de credenciales, protección de eventos, registro de actividad, control de acceso, gestión de incidentes, continuidad, dependencias y ciclo de cambios. El proveedor debe indicar qué evidencia puede compartir, bajo qué condiciones y con qué vigencia.

No declare certificaciones, auditorías, licencias ni niveles de disponibilidad que no estén confirmados documentalmente para la entidad y el servicio evaluados. Si compras solicita una certificación concreta, responda con uno de tres estados: evidencia adjunta; evidencia disponible bajo proceso acordado; requisito no confirmado. Sustituir la respuesta por «seguridad de nivel empresarial» impide evaluar y crea riesgo contractual.

Para la integración, solicite o entregue —según corresponda— descripción de autenticación, permisos, rotación y revocación de credenciales; validación de mensajes; protección frente a repetición; correlación de eventos; registros y procedimiento de notificación de incidentes. La respuesta debe distinguir el entorno de prueba del entorno operativo y definir quién puede autorizar el paso entre ambos.

En cumplimiento, el proveedor puede documentar su proceso aplicable de incorporación, la información que solicita y las restricciones que comunica. El cliente debe determinar sus obligaciones legales, fiscales, contables, sectoriales y de contratación para sus entidades y mercados. No basta con trasladar toda la cuestión al proveedor. Tampoco procede afirmar cumplimiento universal. La sección debe identificar jurisdicciones, entidades, actividad, pagadores previstos y revisores internos antes de cerrar el alcance.

Las preguntas frecuentes de Cryptoway sobre operación de pagos cripto pueden aclarar conceptos generales, pero la evidencia de una RFP debe ser específica del servicio evaluado. Del mismo modo, una lista de errores de lanzamiento sirve para preparar la revisión, no para sustituir el análisis de seguridad o cumplimiento del cliente.

SLA, criterios de aceptación y formato final de la respuesta

Un SLA útil define eventos medibles y responsabilidades. Separe disponibilidad del servicio, recepción de solicitudes, entrega de notificaciones, respuesta de soporte y resolución de incidentes. Cada métrica necesita punto de inicio, punto de fin, fuente de medición, exclusiones, canal de escalado y periodo de reporte. Si los valores aún están en negociación, presente el método y marque los objetivos como decisiones contractuales pendientes; no invente cifras para completar la tabla.

Incluya una matriz RACI para operación normal y excepciones. Ventas responde por el alcance comercial; compras, por el proceso de selección y condiciones; tesorería, por unidad de cuenta y política de aceptación; contabilidad, por aplicación y cierre; seguridad y cumplimiento, por sus revisiones; tecnología, por integración y observabilidad; el proveedor, por su servicio documentado y soporte acordado. Los nombres pueden cambiar, pero ninguna tarea crítica debe quedar asignada a «el negocio».

Los criterios de aceptación convierten la propuesta en una prueba. Un conjunto razonable, sujeto a acuerdo, puede exigir que:

1. una solicitud conserve la referencia comercial correcta;
2. el pagador vea importe, activo, red y vencimiento sin ambigüedad;
3. los estados acordados lleguen al sistema del cliente y puedan correlacionarse;
4. tesorería reproduzca la conciliación con la evidencia entregada;
5. un pago incompleto y uno tardío sigan la ruta aprobada;
6. una devolución de prueba respete autorización y registro;
7. credenciales y eventos superen las pruebas de seguridad definidas;
8. soporte ejecute un escalado de prueba con evidencia temporal.

Cada caso necesita precondición, pasos, datos, resultado esperado, responsable de ejecución y firmante. La guía sobre criterios de experiencia de pago ayuda a incluir la perspectiva del pagador sin olvidar conciliación y control interno.

Cierre la respuesta a la RFP en este orden: resumen de alcance; supuestos y exclusiones; matriz requisito-respuesta-evidencia; flujo comercial y técnico; activos y redes por confirmar; estados y excepciones; conciliación y devoluciones; seguridad y cumplimiento; SLA propuesto; plan de prueba; criterios de aceptación; decisiones abiertas; anexos documentales. Para cada requisito use «cumple», «cumple condicionado», «requiere desarrollo» o «no confirmado», con explicación y evidencia.

La mejor respuesta no es la que promete más. Es la que permite a compras comparar, a ventas contratar sin ambigüedad y a tesorería operar sin decisiones ocultas. Si un dato depende del cliente, debe aparecer como decisión. Si depende del proveedor, debe sostenerse con documentación. Si depende de una prueba conjunta, debe convertirse en un criterio de aceptación.