¿Qué es Secure Remote Commerce (SRC)?

Secure Remote Commerce (SRC) es la especificación de EMVCo que define cómo funcionan los pagos online con tarjeta sin que el comprador tenga que teclear su número de tarjeta en el formulario de checkout de cada comercio. SRC describe los roles, los flujos de mensajes, las señales de autenticación y los formatos de datos que permiten a cualquier red participante compartir el alta y tokenizar los datos de tarjeta camino del comercio. Click to Pay es la marca de cara al comprador construida sobre SRC: el botón, la experiencia de usuario, el marketing. SRC es la capa técnica de debajo, propiedad y publicada por EMVCo (el mismo organismo de estándares que dio al mundo el chip y PIN). Para la mayoría de los compradores, la distinción no importa. Para los comercios, los ingenieros de pasarela y los adquirentes, importa bastante.

La versión corta: SRC es la especificación, Click to Pay es el producto. EMVCo redactó la especificación SRC para que cada red de tarjetas implementara el checkout online de la misma forma. Las cuatro grandes redes —Visa, Mastercard, American Express y Discover— operan cada una su propio SRC System, pero todas se ajustan a las mismas reglas de EMVCo, y comparten el estado de alta entre sí para que un comprador no tenga que dar de alta la misma tarjeta cuatro veces. Si has estado buscando «qué son los pagos SRC» y las respuestas solo dicen «es Click to Pay», eso no está mal, pero salta la parte que explica por qué el botón se ve igual en un sitio Mastercard y en uno Visa, y por qué los datos que fluyen por debajo son consistentes entre redes.

Los roles que define SRC

SRC describe un pequeño ecosistema de roles con nombre. Cuando tienes claros estos, el resto de la especificación cae por su peso.

El SRC System es el operador central, uno por red. Visa opera un SRC System, Mastercard otro, lo mismo Amex y Discover. El SRC System guarda las tarjetas dadas de alta, ejecuta las comprobaciones de autenticación y emite tokens de red a los comercios.

El SRC Initiator es el checkout del comercio (o el proveedor de servicios de pago del comercio actuando en su nombre). Es lo que en el sitio del comercio llama al SRC System y dice «este comprador quiere pagar, aquí está su correo, dame las tarjetas disponibles».

El Digital Card Facilitator (DCF) es la pieza de UI que gestiona la interacción del comprador: la caja para introducir el correo, el aviso de código de un solo uso, la pantalla de selección de tarjeta. Puede alojarlo el SRC System o estar embebido en la página del comercio. En cualquier caso, el DCF es lo que el comprador toca de verdad.

Y la Payment Account es la tarjeta dada de alta por el comprador. A SRC en realidad no le importa si es una tarjeta de débito, una de crédito o una prepago: solo necesita un PAN emisor de tokens detrás.

SRC frente a Click to Pay

Esta es la pregunta con la que la mayoría de la gente aterriza en esta página queriendo respuesta. La forma más limpia de plantearlo:

SRC es el estándar. Click to Pay es la marca.

EMVCo publica la especificación SRC. Cualquiera que implemente checkout online cumpliendo con ella sigue esa especificación. Las cuatro redes de tarjetas implementan SRC bajo la marca compartida Click to Pay y el logo compartido de cuatro pájaros. Así que desde el punto de vista del comprador hay un producto de cara al consumidor: Click to Pay. Desde el punto de vista de la integración del comercio, contra lo que se integra de verdad es la API de SRC (normalmente envuelta por su pasarela), y la especificación que debe leer si quiere entender qué está pasando es la especificación SRC de EMVCo, no la página de marketing de ninguna red concreta.

Existen otras marcas que usan SRC, sobre todo en regiones donde las cuatro redes globales no dominan: redes domésticas en algunos mercados han construido sus propios botones de checkout compatibles con SRC. Pero globalmente, Click to Pay es de lejos la marca SRC dominante.

Cómo funciona el flujo de datos

Esto es lo que pasa cuando un comprador hace clic en el botón Click to Pay en el checkout de un comercio, en términos SRC.

El sitio del comercio (el SRC Initiator) llama al SRC System e identifica al comprador, normalmente por dirección de correo. El SRC System comprueba si ese correo tiene tarjetas dadas de alta en las redes. Si las tiene, devuelve una señal de reconocimiento al comercio. El DCF se abre entonces —ya sea como un overlay sobre la página del comercio o como un popup alojado por el SRC System— y el comprador se autentica. Eso puede ser un código de un solo uso por correo, una passkey en navegadores compatibles, o en algunos mercados un paso de 3D Secure dentro del mismo flujo.

Una vez autenticado el comprador, elige una tarjeta de la lista de opciones dadas de alta. El SRC System emite entonces un token de red para esa tarjeta, con alcance ese comercio, más un criptograma de un solo uso. El comercio recibe el token y el criptograma, no el PAN real, y envía la solicitud de autorización estándar a su pasarela de pagos con el token en lugar del número de tarjeta. El sistema de autorización del emisor des-tokeniza al entrar, ejecuta sus comprobaciones habituales y aprueba o rechaza.

Los datos que tocaron al comercio: una dirección de correo, una confirmación de alta, un token de red, un criptograma. Los datos que no tocaron al comercio: el número real de la tarjeta.

Por qué SRC importa a los comercios y a los PSPs

La consecuencia práctica más importante de SRC es la misma que la de Click to Pay: el comercio no maneja el PAN. Desde el punto de vista de PCI DSS, un comercio que integra SRC a través de su PSP está en la misma categoría que uno que usa una página de pago totalmente alojada o tokenización: los datos de tarjeta fluyen por la red, no por el comercio. Eso es una carga a nivel de SAQ A en lugar de un SAQ D completo.

La segunda consecuencia es sobre las tasas de autorización. Los emisores ven las transacciones SRC como autenticadas y tokenizadas, así que las señales de riesgo que entran con la solicitud de autorización son más ricas. En la práctica, eso produce una mejora pequeña pero consistente en las tasas de aprobación frente al e-commerce con PAN en claro: Visa y Mastercard publican cifras en el rango del 2-4 %, según geografía y cesta.

Y la tercera —relevante si estás construyendo un checkout— es que integrar contra SRC una vez te da las cuatro redes a la vez, en lugar de construir cuatro integraciones separadas de una sola red como hacían antes los comercios con Visa Checkout, Masterpass y Amex Express Checkout. Esa convergencia es la razón por la que existe SRC.

Lo que SRC no hace

SRC no es un esquema de pagos en sí mismo. No sustituye a Visa ni a Mastercard: se sitúa sobre ellas. Una vez que el comercio tiene el token de red, la autorización sigue fluyendo por el modelo habitual de cuatro partes (titular de la tarjeta, comercio, adquirente, emisor). SRC tampoco sustituye a 3D Secure: donde aplican las reglas de SCA, 3DS se incorpora al flujo SRC en lugar de saltarse. Y SRC no es un monedero en el sentido de Apple Pay; es un estándar de checkout basado en navegador, no una credencial vinculada al dispositivo.

Dónde leer la especificación

EMVCo publica la especificación SRC en emvco.com. La versión actual en el momento de escribir es SRC 1.3, que establece los formatos de mensaje, los requisitos criptográficos y el programa de certificación. La mayoría de los comercios no necesitarán leerla directamente —los proveedores de pasarelas y los PSPs ya han hecho el trabajo— pero si estás construyendo un checkout desde cero, o construyendo tú mismo un SRC Initiator, ahí es donde empezar.