Tokenización de tarjetas de crédito y múltiples partes

3

Business B acepta la información de la tarjeta de crédito según las pautas de SAQ-A-EP y obtiene el token T del proveedor de servicios de pago P. El token ahora debe enviarse (por B) a los socios P1 o P2 o P3. para que cobren a los clientes de B, por los servicios prestados por los socios.

¿Es este un escenario viable? En otras palabras, ¿puede una empresa simplemente reenviar el token y hacer que el socio agregue la información de la transacción para su procesamiento? Si no es así, ¿de qué manera la empresa que esencialmente actúa como un intermediario procesa el pago a través de socios?

    
pregunta user9445 04.08.2016 - 23:08
fuente

3 respuestas

0

La solución que usaremos es enviar el token en un archivo EOD al proveedor de pagos con la información del socio. El socio debe tener una relación con el pago proporcionado también. El proveedor de pagos creará un nuevo token para el socio y se utilizará para el procesamiento de pagos.

    
respondido por el user9445 30.08.2016 - 12:47
fuente
1
  

¿Es este un escenario viable? En otras palabras, ¿puede un negocio simplemente avanzar?   el token y haga que el socio agregue información de transacción para   procesando?

En general, no , no porque DSS prohíba compartir un token, sino porque el token solo es útil en el contexto de la relación entre el procesador y el comerciante . Las partes aleatorias P1 - P3 no pueden presentar el token al procesador y hacer que el procesador haga algo con él; ellos mismos deben tener una relación comercial con ese procesador. Y los tokens proporcionados por un procesador a un comerciante pueden no ser transferibles a otros comerciantes que utilicen el mismo proveedor.

  

Si no, ¿cómo funciona la empresa que esencialmente actúa como intermediaria?   proceso de pago a través de socios?

Parece que está buscando algo como el Facilitator de pagos , o el modelo PayFac *, . Permite al comerciante B actuar como intermediario entre P1 / P2 / P3 (que son "sub-comerciantes" en este modelo) y el procesador P. El PayFac B generalmente trabajará para proporcionar interfaces para que los sub-comerciantes dirijan su flujo de pagos. el procesador P bajo los auspicios de B, y luego tomará la distribución monetaria agregada de P y distribuirá el desglose correcto a P1 / P2 / P3. Los datos de la Tarjeta y los tokens permanecerán con B; los clientes de P1 / P2 / P3 fluirán a través de B para futuras transacciones (generalmente sin que sea obvio que lo están haciendo).

" Payment Gateway " es uno de los términos que puede escuchar para describir a los Facilitadores de pagos, aunque advierto que "Payment Gateway" como frase también incluye muchas configuraciones diferentes que no son PayFac y significa diferentes cosas para diferentes personas.

Esencialmente, P1 / P2 / P3 están entregando la complejidad de tratar con las tarjetas al PayFac, B. Pero tienen la ventaja de habilitar su negocio al aceptar tarjetas.

* PayFac es el término Vantiv para este tipo de configuración; No sé si hay un término genérico o cuáles son los nombres de las ofertas en competencia. Revelación completa, soy un empleado de Vantiv. Limitar el ejemplo a Vantiv es un signo de mi ignorancia en lugar de sesgo per se :). Si alguien nombra equivalentes de la competencia en los comentarios, me complacerá resumir la respuesta en sí misma.

    
respondido por el gowenfawr 05.08.2016 - 15:59
fuente
-1

Desde mi experiencia en PCI y CC, diría que la respuesta es no en función de cómo describió el escenario por los siguientes motivos:

  1. El negocio B, no debería necesitar obtener un token, ya que debería ser manejado por un tercero basado en el SAQ-A-EP. Todo lo que B necesita es una aprobación de la transacción.
  2. La transferencia del token estará en conflicto tanto con el almacenamiento como con la transmisión de CHD, que falla según SAQ-A-EP.
  3. Creo que se trata de cláusulas de protección al consumidor sobre los datos que comparte con los socios.

En su escenario, si un consumidor ordena servicios que necesitan ser ejecutados por múltiples socios, estos deben:

  • Sea una transacción única, y sea una empresa financiera dividida entre empresas, o
  • El consumidor debe ser transferido a cada sitio para ejecutar transacciones individualmente.

Los tokens generalmente se derivan usando la ID del comerciante para fines de seguimiento.

Nota: Estoy tomando socios para referirme a compañías separadas que comparten un interés común / brindan servicios a los demás consumidores. Si de hecho tenía una sola entidad que fue identificada por el proveedor como el comerciante, su escenario se vuelve más plausible, pero creo que todavía se rompería el SAQ-A-EP.

EDITAR:

Sé que los Token no son CHD, y quería dar a entender que aún necesitaban estar protegidos y, dado que esto era específico del SAQ-A-EP, el token no sería transferible para cumplir con esa directriz. Bajo ese escenario, es probable que se coloque en SAQ-C o D.

    
respondido por el Shane Andrie 04.08.2016 - 23:49
fuente

Lea otras preguntas en las etiquetas