CactusPlay - Tienda de juegos con una red de colaboradores verificados

Recorrido por la infraestructura y las capacidades

Un recorrido por el sistema en funcionamiento: el escaparate en WooCommerce, el catálogo que el grabber mantiene lleno, el panel de administración donde se gestionan precios y pedidos, y cómo encajan las piezas. Comentarios en ruso.

Desafío

Los jugadores de la CEI que compraban títulos de PlayStation y Xbox se enfrentaban a un mercado fragmentado: los precios de las tiendas oficiales variaban significativamente según la región, los revendedores de tarjetas de regalo estaban dispersos por foros, y no había un único lugar para comparar y comprar. Cofundé CactusPlay para llenar ese vacío: una tienda de juegos y objetos dentro del juego con precios procedentes de fuentes oficiales, y con el cumplimiento abierto a una red de colaboradores en lugar de guardado dentro del equipo.

El reto técnico central: PlayStation Store y Xbox Store no exponen APIs públicas. Mantener miles de SKU con precios exactos casi en tiempo real requería construir desde cero una capa de scraping y sincronización.

Descubrimiento

La investigación inicial mapeó el recorrido completo del comprador: descubrir un juego, comparar el precio entre regiones, comprar la clave legítima más barata, canjearla. El dolor estaba en los pasos de comparar y comprar. Existían vendedores, pero estaban fragmentados; los compradores no tenían señales de confianza. Una tienda con datos de precios consistentes y un checkout limpio podía apropiarse de esa parte central del embudo, siempre que pudiera cumplir pedidos más rápido de lo que los fundadores podrían nunca.

Opciones consideradas

1. Entrada manual de precios por administradores: descartado. No escala; los precios cambian a diario, a veces cada hora durante las rebajas.
2. API de terceros para agregación de precios, existía ninguna para PlayStation/Xbox en la CEI en ese momento.
3. Scrapers personalizados en Node.js + tienda en WordPress/WooCommerce: elegido. Los scrapers dan propiedad real de los datos; WooCommerce aporta una capa de comercio probada en batalla sin construir el checkout desde cero.

Decisión

Scrapers en Node.js que se ejecutan según una programación cron consultan los endpoints de PlayStation Store y Xbox Store, analizan la respuesta y envían actualizaciones de precio y disponibilidad a WooCommerce a través de su API REST. WordPress + WooCommerce se encargan de la tienda, el carrito y las integraciones de pasarelas de pago. Extensiones personalizadas en PHP gestionan los flujos de incorporación de colaboradores que WooCommerce no soportaba de fábrica.

‹›

aA🔒cactusplay.ru/

⇧▢+

ГГлавнаяККаталог5Игры PS5ВВедьмак 3%Скидки@Контакты

cactusplay.ru, scrollable snapshot of the live storefront

Implementación

Se construyeron scrapers de ingeniería inversa para ambas tiendas, gestionando sesiones, cambio de región y medidas anti-bot. Se configuró un sistema de actualización diferencial: solo los precios que cambian disparan actualizaciones en WooCommerce, manteniendo baja la carga de la API. Un sistema de alertas de cambio de precio notifica a los administradores cuando un producto cae por debajo de un umbral, permitiendo decisiones de timing promocional.

Se integraron pasarelas de pago compatibles con métodos de pago de la CEI. Extensiones personalizadas de WooCommerce en PHP se encargaron de la entrega digital (códigos de clave) y la lógica de pagos a colaboradores. Desplegado en un VPS con despliegue automatizado mediante Git hooks.

Cualquiera con datos de pago turcos podía cumplir pedidos

Esta es la pieza que hacía funcionar la tienda. Nuestros productos se activan sobre la cuenta del comprador, lo que significa que alguien tiene que comprar de verdad el título en la región barata y dejarlo ahí, y ese alguien necesita datos de pago turcos operativos, que la mayoría en la CEI no tenía. Mientras el cumplimiento se quedara dentro del equipo, el techo de la tienda era lo que los fundadores alcanzaran a procesar en un día.

Así que el CRM se abrió. Cualquier colaborador podía postularse, pasar una verificación y a partir de ahí tomar pedidos de la cola, cumplirlos y ganar con cada uno. El techo dejó de ser un problema de plantilla para ser uno de capacidad: cuantos más colaboradores verificados en el CRM, más pedidos absorbía la tienda, sin una sola contratación nueva en nómina. Los flujos de incorporación y la lógica de pagos de «Implementación» de arriba existen precisamente por este modelo.

Preparación legal para aceptar pagos

Aceptar tarjetas de bancos rusos fue primero un problema de papeleo y solo después de plugins. Ningún proveedor da de alta una tienda sin forma legal, así que la forma fue lo primero: el conjunto completo de documentos (oferta pública, política de privacidad, consentimiento para el tratamiento de datos personales, condiciones de devolución y entrega), el registro en el registro estatal de operadores de datos personales y el alta como trabajador autónomo para poder facturar.

Solo entonces se montó el circuito de pago: adquirencia mediante el plugin de WooCommerce del banco Tochka y, junto a él, LifePay CloudPrint para emitir los tickets fiscales, que el plugin de adquirencia no generaba por sí mismo. Lo que ve el comprador es lo que cuenta: pagar directamente con una tarjeta de un banco ruso, en el sitio, y recibir el ticket que exige la ley.

El sistema detrás de la tienda

La tienda es solo una cara de un sistema mayor. Un grabber en Node.js recorre la PlayStation Store oficial, y la Xbox Store sobre la misma abstracción, extrayendo más de 20 000 posiciones cada hora. Itera juegos, DLC y servicios por separado, renombra las categorías a la taxonomía propia de la tienda y fusiona las etiquetas de las stores, de modo que el catálogo llega estructurado y no como un volcado plano.

El resto lo sostienen cinco plugins de WordPress a medida:

• slave-api. El motor de sincronización. Contiene la abstracción de plataformas (una única interfaz sobre las API de PlayStation y Xbox), los manejadores que cambian la visibilidad o retiran SKU, comandos CLI para sincronizaciones totales y parciales, y escenarios de actualización versionados: una regla de catálogo se despliega sobre una tienda viva sin una pasada manual.
• product-manager. El lado de precios de la tienda. Consulta a la PlayStation Store los precios vigentes en varias monedas, elige uno mediante una estrategia intercambiable (la incluida toma el precio regional legítimo más bajo), guarda el resultado en transients para que una ficha de producto nunca espere a una llamada externa, e inyecta los campos personalizados que el flujo necesita en el formulario de producto, el carrito, la compra y el pedido.
• product-code-manager. La mitad de la entrega digital. Genera y almacena códigos de producto, los resuelve y activa, y expone una API autenticada por JWT para que un pedido creado en cualquier parte del sistema se complete sin una persona de por medio. Los manejadores reaccionan a la creación del pedido y a los cambios de estado, y por eso el código llega justo después de la compra digital en lugar de tras un envío manual.
• aw-auth. El acceso. Coloca VK, Yandex, Steam y Discord en los formularios de WordPress y WooCommerce bajo un único contrato de proveedor: cada red nueva es un cliente, un servicio y una pantalla de ajustes, no una bifurcación del flujo. Steam se verifica contra firmas OpenID 2.0 y el resto mediante intercambio de código OAuth; a quien vuelve se le asocia su cuenta existente y solo se crea una nueva si no hay coincidencia. Como una devolución de llamada puede llegar dos veces, cada código se reserva en una tabla de bloqueo con contador: la segunda petición espera a la primera y sigue su redirección en lugar de duplicar la cuenta. Steam no entrega correo, así que esos usuarios pasan por un formulario de correo y teléfono antes de comprar. El acceso es solo por correo, la dirección debe estar en un dominio .ru por la normativa rusa de datos personales, y la caché privada se purga al entrar para que nadie vea una página obsoleta.
• mail-manager. El motor de campañas propio, para que el correo a clientes no dependiera de un proveedor externo. Las audiencias son categorías, las campañas se enlazan a categorías y la cola pendiente se deriva con un join: a quien ya tiene un registro de envío para una campaña no se le vuelve a elegir, de modo que una ejecución interrumpida continúa justo donde se cortó. Un cron envía un lote fijo con una pausa entre mensajes, manteniendo la tienda dentro del límite SMTP en vez de disparar una ráfaga que marca el dominio. Tras la activación el envío está desactivado y un interceptor registra los mensajes en vez de entregarlos, así una copia de la base de producción no puede escribir a clientes reales; el panel muestra pendientes, enviados y fallidos por campaña. Las columnas de aperturas y clics y el endpoint de seguimiento están esbozados: lo que llegó a producción es la entrega.

Yandex.Market: una cadena de precio de extremo a extremo

La integración con el marketplace cierra el círculo. Las ofertas se mapean al esquema de Yandex.Market mediante una capa de mappers dedicada, con configuración por tienda, y un servicio de precios las mantiene al día. La cadena funciona sin intervención humana en ningún paso: el precio cambia en la PlayStation Store oficial, el grabber lo recoge, se actualiza el sitio y después se actualiza la oferta en Yandex.Market. Los códigos se entregan lo bastante rápido como para que una compra digital en el marketplace se complete en la misma sesión, y las fichas llevan todos los atributos que Yandex.Market admite, no el mínimo para publicar.

Un número y todo el catálogo recalculado

Los precios seguían pidiendo una mano en la palanca de vez en cuando: se mueve el tipo de cambio, un socio cambia condiciones, hay que ajustar el margen. En lugar de tocar los productos, el multiplicador sobre el precio base ocupa su propia fila en la base de datos, RUB_MULTIPLIER con el multiplicador de p2p al lado. Cambias el valor y la siguiente sincronización reconstruye con él todos los precios del catálogo, tanto en el sitio como en el feed de Yandex.Market.

Los multiplicadores de precio, una fila cada uno

Un logotipo comprado en una feria

La marca de la tienda no es el dibujo de un cactus cualquiera, es uno concreto. Compré el colgante en una feria callejera de Recoleta, Buenos Aires, lo fotografié, lo grabé sobre fondo verde y calqué el recorte hasta convertirlo en la marca que hoy está en el sitio, en las portadas y arriba de cada ficha del marketplace.

El colgante de Recoleta

Recortado en Photoshop

Servicio de estilizado de portadas, hecho, no integrado

Un servicio aparte en Go componía portadas listas para el marketplace: el arte original, un fondo desenfocado para cubrir la proporción exigida, una cabecera con la marca de la tienda y distintivos de edición. Se terminó y produjo el resultado de abajo, pero la integración en la canalización del catálogo nunca se completó, las portadas salieron sin estilizar.

Los distintivos se dibujaron para la ficha del marketplace, no se tomaron prestados. Cada uno lee un campo de los metadatos del producto y lo convierte en una etiqueta que el comprador entiende de un vistazo: la región de la cuenta con su bandera, el tipo de edición, el idioma de la interfaz y la marca de la tienda encima. Después el servicio elegía el juego que correspondía al artículo y lo componía sobre la portada.

Distintivos generados a partir de los metadatos

Portadas de categoría, generadas como un juego

El catálogo tenía 33 categorías y ninguna con ilustración. En vez de encargarlas una a una, el juego entero se generó con Kie AI siguiendo un mismo estilo de prompt ajustado al sitio: trazo de neón, verde sobre casi negro, un solo motivo por pieza. La instalación también fue un script y no 33 viajes a la biblioteca de medios: WP-CLI importa cada archivo y lo vincula a su término como miniatura de la categoría, en una sola pasada dentro del contenedor LiteSpeed.

Las 33 portadas de categoría, un único juego generado

Soporte

La atención al cliente funciona sobre un FreeScout autoalojado en support.cactusplay.ru: chat web y Telegram en una sola bandeja, con los últimos pedidos del cliente cargados junto a la conversación para que el agente responda sin cambiar de sistema.

Correo en hierro propio

Los proveedores de correo externos cobran por buzón y por volumen, y la tienda necesitaba crecer en ambos. Un mailcow en servidor propio se quedó con todo: mail.cactusgames.ru envía por SMTP y recibe por IMAP para todas las direcciones, el soporte y el motor de campañas se autentican contra él, y la entrega ya no depende del plan ni de las condiciones de un tercero. Abajo, FreeScout conectado a él: envío por el 5587 con StartTLS y recogida de INBOX por el 993 con SSL.

Envío a través de mail.cactusgames.ru

Recogida por IMAP

El motor de correo propio de la tienda

mail-manager, el motor de campañas descrito más arriba, en funcionamiento. Está en CactusPlay y en los sitios de consultoría, que es lo que mantiene el correo a clientes fuera de un proveedor externo.

El formulario antes de la versión final

Tanto el formulario de activación como la guía se apoyan en product-code-manager, igual en CactusPlay que en 1gros. Esta es una versión anterior, intermedia, del formulario: se grabó para repasar el enfoque con el socio y confirmar que era el correcto antes de desarrollarlo del todo.

Otra toma de ese formulario temprano, esta vez con la vista previa: antes de confirmar, el comprador ve qué producto le dará el código. Los fallos de JS en pantalla se corrigieron más tarde.

Guía de activación del código

Un vídeo demostrativo colocado en el propio sitio que guía al comprador en la activación de su código. Está en CactusPlay y en 1gros, el sitio de consultoría. Ese onboarding dejó el proceso lo bastante claro como para que la gente dejara de reclamar a Yandex por él.

El sitio tenía un problema: después de comprar en Yandex.Market, los usuarios llegaban al formulario de activación del juego y se perdían ahí, sin entender cómo activarlo. Así que me hice un tiempo, escribí un guion y grabé este video. Los compradores lo veían directamente en el formulario de activación, y les ayudaba a no perderse, entender el proceso y terminar la activación.

Acceso con proveedores rusos

El módulo aw-auth, que existe por separado y aquí se reutiliza en CactusPlay y en los sitios de consultoría. Cubre el acceso OAuth con proveedores para los que entonces no había soluciones hechas: Yandex fue, que yo sepa, el primero disponible, además de VK y Discord. Pensado para el mercado ruso, con los requisitos legales de datos que eso implica.

Yandex ID, el primer proveedor conectado

Los papeles antes que los pagos

Vender productos digitales a compradores rusos es primero una cuestión legal y solo después técnica. La tienda pasó por la revisión completa de la documentación, no por una licencia de plantilla pegada en el pie: el acuerdo de licencia, la oferta pública, la política de devoluciones y las condiciones sobre cómo llega una activación a una cuenta. El negocio también se registró como operador de datos personales ante el organismo supervisor, con el almacenamiento y el tratamiento ajustados a lo que ese registro obliga. Antes de eso hubo una ronda de preguntas a un contable: cómo se declara la reventa de un título digital extranjero y en qué se diferencia vender por un marketplace de vender por tu propio sitio.

Con los papeles en regla, el acquiring quedó al alcance. Un proveedor no lo activa sin más: la tienda pasó antes por una moderación, y superarla es para lo que se había reunido todo el paquete de documentos. Una vez superada, la cuenta corriente fue a Tochka, cuyo plugin para WooCommerce cobra en el sitio, y LifePay cloudprint emite los recibos fiscales. Los compradores en Rusia pagan en rublos con MIR, Visa o Mastercard, o por SBP, sin salir del proceso de compra.

Pago en rublos con tarjeta o por SBP

El mismo montaje pasó a las tiendas asociadas. Abajo, el pago en 1gros: el subtotal en rublos, las marcas de tarjeta y SBP y la línea que nombra a Tochka como la plataforma tras los pagos.

El pago en una tienda asociada

Entrega inmediata para Yandex.Market

Entrar en el marketplace de Yandex.Market traía una restricción dura: tras la compra hay 15 minutos para entregar el producto digital. Nuestros productos se activan sobre una cuenta en lugar de entregarse como una clave suelta, y eso no cabe en 15 minutos.

La salida fue un formulario propio de activación de claves. Al comprar, nuestra API emite al comprador una clave que en realidad es una obligación diferida, con lo que se cumple la ventana de entrega de Yandex; la activación sobre la cuenta se realiza después en nuestra plataforma, cerrando el pedido del lado de Yandex.

La misma cadena funciona en las tiendas asociadas. Abajo, el escaparate de 1gros en Yandex.Market: las fichas las armó la automatización del catálogo, no una persona, y cada venta emite por su cuenta la clave de activación que el comprador canjea después en el sitio.

1gros en Yandex.Market, fichas armadas por la automatización

Cuando el trabajo superó a un solo par de manos

No todos los módulos valía la pena escribirlos yo. Para no perder ritmo, las piezas autocontenidas salían a plataformas de freelance como Kwork, y eso solo funciona si la especificación es lo bastante cerrada como para entregarla sin una conversación adjunta. Abajo, una de esas especificaciones: un plugin de FreeScout que trae los chats de pedidos de Yandex.Market a la misma bandeja que el chat web y Telegram, con el endpoint nombrado para cada operación, carga perezosa de hilos largos, adjuntos y los mensajes de chat y de arbitraje diferenciados.

Especificación de un módulo externalizado

El volumen de pedidos también superaba lo que el equipo podía absorber, así que hubo tramos del proyecto dedicados a seleccionar personal en vez de a programar: redactar las ofertas, filtrar, probar a la gente con tickets reales. Buena parte terminaba como suele terminar, con un buen candidato rechazando el trabajo por motivos que no tienen nada que ver contigo.

Una candidata que se retira

Y cuando sencillamente no había manos, la respuesta era asumir yo la operativa: responder a los compradores en los chats de pedidos, insistir en los que se quedaban parados, cumplir pedidos a mano. Había mucho de eso. La bandeja de abajo es una tarde normal: cuatro avisos de Yandex.Market en dos horas de una sola tienda, sobre un recuento de correo sin leer que va por miles.

Un chat de pedido, atendido a mano

Una tarde normal en la bandeja

La coordinación iba por chats de servicio y no por un tablero de tareas. Cada tienda tenía el suyo, y un bot escribía en él en cuanto el CRM registraba un pedido - número, tienda, estado, hora - de modo que quien estuviera libre lo tomaba en lugar de que todos refrescaran el panel.

El chat de servicio, con el bot del CRM publicando pedidos

Consultoría para otras tiendas

El grabber y lo construido a su alrededor también salieron en forma de consultoría. Los apliqué en 1gros.ru, ps-store.ru, playstaionplus.ru y xbox-store.ru: sincronización de la base del catálogo con mi propio parser, integración de tiendas de terceros, ajuste de su WordPress y mantenimiento continuo. El vídeo muestra uno de esos sitios, 1gros.

Banners para las portadas de las tiendas asociadas

El trabajo en esos sitios no era solo fontanería. Sus portadas necesitaban algo con lo que abrir, así que la suscripción de PlayStation Plus tuvo su propio banner, nivel por nivel, en dos tratamientos entre los que la tienda podía elegir.

Variante oscura

Variante en degradado

Mantenimiento desde donde tocara

Esas tiendas venden a cualquier hora, así que el mantenimiento no esperaba a un escritorio. Buena parte ocurrió por SSH desde el móvil: editar el crontab de sincronización en el VPS de 1gros, revisar las bases de playstationplus.ru y ps-store.ru, vigilar la carga del servidor de la API de Xbox. Nada elegante, pero una sincronización de precios que se para a medianoche se arregla a medianoche.

Crontab de sincronización en el VPS de 1gros

Bases de datos de las tiendas atendidas

Carga en el servidor de la API de Xbox

El grabber en acción

Recogida de los listados estáticos de productos del sitio de PlayStation, la materia prima con la que se arma el catálogo.

La otra mitad del mismo trabajo: ajustar el coeficiente de precio que convierte el precio de la tienda oficial en el precio al que vende el shop.

Resultado

El grabber sostiene más de 20 000 posiciones por hora, y los cambios de precio llegan tanto a la tienda como a la ficha de Yandex.Market sin que nadie los toque. La plataforma manejó transacciones reales desde el lanzamiento, y la infraestructura de scraping sobrevivió a varios rediseños de front-end de PlayStation y Xbox Store mediante actualizaciones puntuales de selectores.

Soporte: carga de los rastreadores de LLM

Durante el soporte técnico continuo el sitio mostró una carga anormalmente alta que no cuadraba con el tráfico real. Los logs señalaron a los rastreadores de los proveedores de LLM populares, ClaudeBot entre ellos, recorriendo el catálogo. Se ajustó la configuración y sus agentes se añadieron a las reglas de exclusión: no traían visitantes ni pedidos, solo carga.

Soporte: la portada que no era nuestra

El hosting también recibió ataques. Una de las tiendas atendidas amaneció un día con la portada sustituida por completo, mostrando un listado de drogas ilegales en lugar de juegos. Se resolvió el mismo día. Una parte de mí se sintió halagada de que nuestra tiendita atrajera tanta atención.