impact.com y PartnerStack: prueba la plataforma antes de elegir

La pregunta útil es si una plataforma puede reproducir los acontecimientos reales de tu programa de socios. Un clic registrado no demuestra que un pedido devuelto deje de generar comisión. Una operación marcada como ganada tampoco acredita el cobro de una suscripción. Comparar esas transiciones permite decidir mejor que comparar la longitud de dos listas de funciones.

Esta guía entrega un expediente de aceptación para impact.com y PartnerStack: requisitos, dos escenarios, registro de conciliación y decisión. Fuentes oficiales comprobadas el 25 de octubre de 2026. El caso de Canva lo publica el proveedor; la tienda, el servicio y las fichas cumplimentadas son ejemplos didácticos, no resultados de clientes. Acceso, país, admisibilidad del producto y funciones contratadas deben confirmarse aparte.

Empieza por los acontecimientos que debes poder explicar

Escoge un producto, un mercado permitido y un modelo de colaboración. Designa a un responsable del programa, un técnico con acceso al sistema de pedidos o facturación y un revisor financiero. Prepara las condiciones de comisión, las reglas de devolución, la definición de cliente existente, la ventana de atribución y algunos registros seudonimizados. Separa la fecha del acontecimiento de la fecha de recepción: una entrega tardía no debe convertirse silenciosamente en otra venta.

Si tu tarea inmediata es preparar una oferta para una red CPA, nuestra AffiliateCore es una posible vía inicial: regístrate como anunciante y prepara la propuesta. Los recursos del anunciante contemplan borradores de ofertas y consulta de registros de conversiones. Las hojas de esta guía siguen siendo documentos propios. No afirmamos que AffiliateCore se integre con estos proveedores, contabilice automáticamente suscripciones, registre operaciones comerciales o importe sus socios.

Para esta comparación suponemos que ya necesitas software para tu propio programa. Pide a ambos proveedores que demuestren las mismas entradas y salidas esperadas en un entorno autorizado. No generes pedidos ficticios remunerados ni envíes datos de demostración a pagos reales. Si falta un entorno seguro o una función esencial, anota «no demostrado» y aplaza esa prueba. Una diapositiva comercial no equivale a una aceptación.

Compara modelos de datos, además de nombres

impact.com: acción y corrección. Una conversión atribuida se convierte en una acción. Las acciones pendientes pueden modificarse o revertirse antes de su fecha de bloqueo; el bloqueo fija la obligación de comisión. Por eso el periodo de devoluciones y el límite para corregir son elementos centrales de la prueba. Comprueba las fechas de tus condiciones, sin suponer un número universal de días. impact.com: action life cycle

impact.com: cadenas de acontecimientos. Las chained actions vinculan un acontecimiento principal con otros posteriores mediante un identificador común de cliente. El principal debe registrarse primero; una configuración existente puede necesitar intervención del soporte. Es una vía documentada para comprobar prueba gratuita, pago y renovación, pero no demuestra que tu facturación envíe todos los datos necesarios. impact.com: chained actions

PartnerStack: ventas gestionadas por socios. El registro de operaciones depende del plan y se habilita por grupos de socios. La documentación describe aprobación manual de operaciones declaradas Closed Won por el socio y creación de clientes para comisiones sobre transacciones posteriores. La compatibilidad con tu CRM debe confirmarse con el proveedor. La fase comercial, el cliente y la transacción pagada son objetos diferentes. PartnerStack: deal submission

PartnerStack: revisión de comisiones. Antes de generar la factura se pueden aprobar, rechazar o retener comisiones. Las comisiones New que cumplan los requisitos pueden aprobarse automáticamente al generarla. Una comisión ya aprobada no se cambia simplemente de estado en esa pantalla; la corrección documentada pasa por la factura. Programa la conciliación antes de ese límite. PartnerStack: commission review

Estas diferencias orientan el orden de la demostración: correcciones de pedidos primero en impact.com, flujo comercial del socio primero en PartnerStack. No significa que el otro producto sea incapaz de atender ese caso. Ambos candidatos deben superar el recorrido obligatorio. Los directorios, el tamaño del marketplace y los logotipos sirven para descubrir opciones, no para demostrar socios disponibles ni ventas.

Caso público: convertir distintas colaboraciones en reglas comprobables

impact.com describe contratos configurables para Canva tras comenzar en septiembre de 2019. Fecha de publicación no disponible; auditoría independiente y evidencias individuales de cancelación no disponibles. Nuestra propuesta editorial es convertir cada variante contractual necesaria en un acontecimiento, una regla de atribución y un procedimiento de excepción. Una recomendación y una venta gestionada por un socio pueden afectar al mismo cliente: el piloto debe explicar a quién se reconoce el resultado y por qué. Ejecuta el mismo registro de ejemplo con la regla acordada previamente y conserva la justificación. Un logotipo conocido no sustituye esta prueba. Los datos que siguen son ejemplos propios de aprendizaje, no una reconstrucción del programa de Canva. El caso sirve para formular preguntas, no para acreditar la aceptación ni declarar un ganador. impact.com — Canva

Una ficha de requisitos que permita suspender

Copia esta plantilla para cada capacidad obligatoria: «Acontecimiento comercial: ___. Sistema de origen e ID: ___. Socio esperado: ___. Estado comercial esperado: ___. Estado esperado de comisión: ___. Fecha límite y zona horaria: ___. Evidencia: ___. Dependencia de plan o configuración: ___. Responsable: ___. Resultado: superado / fallido / no demostrado». Separa el estado comercial de los términos del proveedor.

Ejemplo cumplimentado: «Pedido O-104 totalmente reembolsado; devolución R-104; socio original P-A; ninguna venta conservada; ninguna comisión pagadera; corrección recibida antes del bloqueo contractual; pruebas: registro de devolución y acción vinculada». Una captura de un total menor en el panel no basta porque no identifica el pedido corregido. Añade una exportación o vista de registro que permita a otra persona conciliar el mismo ID.

Confirma aparte los módulos necesarios, responsabilidades de implantación, soporte, acceso y condiciones de exportación. Anota quién puede autorizar una corrección y quién lo sustituye. Una configuración prometida sigue siendo un requisito pendiente hasta su demostración; no la incluyas entre las pruebas superadas.

Escenario 1: una tienda comprueba pedidos, duplicados y devoluciones

Brief y materiales. Una tienda didáctica vende accesorios corrientes de escritorio mediante socios editoriales autorizados. Prepara guía de compra, página de producto y enlace por socio. La regla exige una comisión por pedido aceptado y un procedimiento documentado de reembolso completo. O-101 será el pedido normal, O-102 la retransmisión, O-104 la devolución completa y O-109 una moneda discordante. Son registros sintéticos del entorno autorizado, no clientes.

Usa este registro: «ID pedido | socio | hora del acontecimiento | hora de recepción | importe original y moneda | ID reembolso | importe final aceptado | ID plataforma | decisión de comisión | motivo». O-101 debe producir una venta aceptada. Reenvía O-102 y espera un único resultado comercial. Reembolsa O-104 por completo y espera la cancelación del resultado original. Para O-109 introduce una moneda discordante: debe abrirse una investigación, no improvisarse una conversión.

Demostración. Acuerda la regla de atribución y el recorrido seguro. Envía los registros iniciales, relaciona cada ID de origen con su registro de plataforma y verifica el socio. Reenvía O-102 mediante el método admitido conservando el identificador comercial. Compara antes y después: un campo de API por sí solo no garantiza deduplicación. Un segundo resultado pagadero suspende la prueba. Antes de repetir, el técnico debe determinar si falló el mapeo de identidades o la lógica de entrega.

En impact.com muestra la acción pendiente y su fecha de bloqueo, y aplica después la reversión completa antes del límite. La referencia de campos distingue identificadores de acción de la combinación pedido/tipo de acontecimiento y describe modificaciones por pedido o artículo. Utiliza los identificadores requeridos por tu método. No sustituyas una transacción por un importe negativo sin verificar el procedimiento. impact.com: action and conversion fields

En PartnerStack exige que el pedido de origen pueda seguirse por cliente, transacción y comisión. Concilia primero la transacción y demuestra después la decisión de revisión. Rechazar una comisión no demuestra que haya desaparecido la transacción de origen. La existencia de un webhook de pagos no acredita gestión automática de devoluciones. Registra el procedimiento de corrección mostrado y el trabajo manual restante.

Resultado didáctico cumplimentado. O-101 sigue aceptado. O-102 remite al resultado original después de retransmitirse. O-104 queda vinculado al reembolso R-104 y deja de generar una comisión admisible según las reglas del ejemplo. O-109 sigue pendiente con un técnico asignado: no es una venta aceptada ni un cliente fallido. El ensayo no supera la aceptación mientras falte una resolución documentada de O-109. La prueba son los registros relacionados y sus motivos, no un total menor en el panel.

Detener o ampliar. Detente ante duplicados pagaderos, reembolsos sin enlace de origen, cambios de moneda inexplicados o vencimiento de revisión antes de conciliar. Guarda el registro fallido y la versión de configuración. Tras corregir, repite ese registro y un pedido normal de control. Amplía al resolver todas las filas obligatorias, completar la observación de devoluciones y permitir que otro revisor reproduzca el registro. Un ensayo pequeño correcto acredita preparación operativa, no ingresos incrementales.

Escenario 2: software B2B comprueba operaciones y pagos recurrentes

Brief y materiales. Un proveedor hipotético de software de agendas trabaja con consultores que presentan empresas y a veces ayudan a cerrar ventas. El piloto diferencia una presentación de una operación gestionada por el socio. Los materiales son un brief de demostración y un formulario con código seudónimo de organización, socio, producto, fase, fecha prevista de cierre, importe y referencia al tratamiento autorizado del contacto. Los datos privados de clientes no se incluyen en un paquete público de demostración.

La regla de aceptación es: «Una oportunidad cualificada todavía no es una venta pagadera; el pago verificado determina la comisión didáctica». Plantilla de relación: «Código de organización → ID de lead/operación → ID cliente → ID factura → ID transacción → ID comisión». Añade el responsable de cada transición y una regla para dos socios que reclamen la misma organización. Pide que se demuestre el conflicto; no supongas que el marketplace lo resuelve.

Demostración de PartnerStack. Confirma acceso a operaciones para el grupo de prueba, configura el formulario permitido y activa aprobación manual de victorias comunicadas por socios si has elegido ese control. Haz que se presenten una operación normal y una declaración de cierre sin pruebas. Comprueba que la validación comercial sea independiente de la declaración. Después muestra cómo la operación aceptada se convierte en cliente y cómo una transacción posterior válida genera la comisión prevista. PartnerStack: deal submission

La API de transacciones exige una referencia de cliente, un importe en centésimas de la moneda indicada y su código; también dispone de identificador de suscripción. Mapea expresamente esos campos. La guía de webhooks requiere clientes existentes, identificadores coincidentes y trabajo de desarrollo. El nombre de un proveedor compatible no demuestra que tu cuenta esté bien configurada. Prueba una referencia de cliente ausente y documenta cómo se detecta y recupera. PartnerStack: transaction API PartnerStack: payment webhooks

Demostración de impact.com. Solicita un acontecimiento principal configurado, por ejemplo una prueba aceptada, y un pago posterior con el mismo customer ID. Envía primero el principal. Presenta después, dentro del flujo autorizado, un acontecimiento dependiente sin el enlace adecuado: el técnico debe detectar el problema y demostrar una recuperación admitida. Comprueba que devolver una renovación no borre silenciosamente la adquisición original válida. La documentación permite revertir por separado acontecimientos principales y dependientes; confirma la configuración efectiva. impact.com: chained actions

Secuencia didáctica de suscripción cumplimentada. ORG-DEMO se atribuye a P-A tras revisar la titularidad. D-DEMO sigue sin validar hasta revisión comercial; una prueba gratuita sola no genera comisión admisible según esta regla. El cliente C-DEMO y la suscripción S-DEMO enlazan el primer pago verificado I-FIRST con la renovación I-RENEW. Si se reembolsa I-RENEW, anula la admisibilidad de esa renovación conservando el primer pago válido y la historia de captación. Otra operación abierta sigue abierta con responsable. Cancelar futuras renovaciones no equivale a reembolsar una factura pasada.

Detener o ampliar. Detente si un cierre sin validar genera remuneración pagadera, dos socios reciben el mismo derecho exclusivo, una transacción pierde su cliente o una renovación reembolsada sigue pagadera. Prueba los cambios a un nivel superior o inferior como transiciones propias: conserva la relación cliente-suscripción, identifica el acontecimiento efectivo y aplica la regla acordada sin inventar una nueva captación. Amplía después de un ciclo completo de facturación y correcciones superado, manteniendo operaciones abiertas visibles y asignadas. Añade un grupo de socios o variante de facturación cada vez.

Matriz de aceptación y hoja de decisión para copiar

Utiliza la misma hoja para cada candidato y compara las evidencias. Los estados siguientes son expectativas comerciales del piloto didáctico, no nombres universales de las plataformas. Anota al lado el estado observado en pantalla o exportación. Un resultado ausente significa «no demostrado», nunca aprobado. Puedes utilizar la hoja aquí sin descargarla.

Descargar la hoja como texto UTF-8

HOJA DE ACEPTACIÓN DEL PILOTO
Campos vacíos — copiar para cada candidato
Candidato / versión de configuración: ___
Producto / mercado permitido / modelo de colaboración: ___
Responsable / técnico / segundo revisor: ___
Entorno autorizado / evidencia de aislamiento de pagos: ___
Sistema de origen / ID comercial / ID plataforma: ___
ID cliente / suscripción / factura / reembolso: ___
Socio esperado / versión de regla de atribución: ___
Estado comercial antes → después: ___
Comisión esperada / estado observado del proveedor: ___
Hora del acontecimiento / recepción / zona horaria: ___
Límite de revisión / bloqueo o generación de factura: ___
Evidencia / responsable de excepción / fecha de repetición: ___
Resultado: SUPERADO / FALLIDO / NO DEMOSTRADO

MATRIZ — aplicar a ambos candidatos
PEDIDO: aceptado → un resultado comercial trazable.
REPETICIÓN: mismo acontecimiento → ninguna comisión admisible adicional.
REEMBOLSO: completo antes del límite → resultado original no admisible, motivo conservado.
TARDÍO: corrección posterior al límite → escalado documentado, sin reescritura silenciosa del historial final.
PRUEBA: sin pago verificado → ninguna comisión admisible según esta regla.
PAGO: primero verificado → mismo cliente, socio acordado, factura vinculada.
RENOVACIÓN: siguiente pago → misma suscripción, identidad propia de factura/acontecimiento.
CAMBIO: nivel superior/inferior → transición registrada, sin nueva captación inventada.
CANCELACIÓN: detener renovación futura → sin venta futura supuesta; factura histórica válida conservada.
DEVOLUCIÓN: renovación reembolsada → renovación corregida, captación inicial conservada.
FALTA: cliente sin enlazar → excepción visible y recuperación admitida.
CONFLICTO: otro socio reclama el cliente → decisión de titularidad antes de aprobar.

EJEMPLO DIDÁCTICO CUMPLIMENTADO — sintético, no resultado de un proveedor
Candidato: demostración A; configuración DEMO-v1.
Origen: registro sintético de facturación; revisor: función de control.
Enlaces: C-DEMO / S-DEMO / I-RENEW / R-RENEW; socio P-A.
Antes: renovación pagada, comisión pendiente de revisión.
Entrada: reembolso completo R-RENEW antes del límite acordado.
Esperado: renovación reembolsada, comisión no admisible.
Conservar: I-FIRST y captación inicial.
Observación didáctica: renovación vinculada corregida; registro inicial conservado.
Evidencia: fila sintética y registro de demostración relacionado.
Resultado: SUPERADO para esta fila, no aceptación de la plataforma.
Pendiente: corrección tardía no demostrada; responsable técnico.
Decisión global: DETENER hasta obtener evidencia y repetir la corrección tardía.

COMPROBACIONES Y DECISIÓN
[ ] Recorrido seguro y exclusión de pagos reales confirmados.
[ ] Mismos registros y reglas para ambos candidatos.
[ ] Cada fila obligatoria tiene evidencia y revisor.
[ ] Sin duplicados admisibles, registros huérfanos ni cancelaciones inexplicadas.
[ ] Excepciones abiertas visibles; límite y responsable de escalado registrados.
[ ] Exportación permite reproducir el mapeo de forma independiente.
SUPERADO solo al superar todas las filas obligatorias.
Una discrepancia es FALLO; DETENER ampliación si falta demostrar o superar una fila obligatoria.
Tras corregir, repetir el registro fallido y un control normal.
Decisión / límites / siguiente paso permitido / revisor / fecha: ___

Elegir por evidencias y limitar el siguiente paso

Los controles obligatorios tienen poder de veto: socio correcto, un resultado comercial, reversión explicable, aprobación controlada y conciliación utilizable. Clasifica el resto como demostrado, configurable con trabajo confirmado o no comprobado. Una función obligatoria sin demostrar bloquea la elección para este alcance, pero no acredita su ausencia universal. Entre los candidatos aprobados compara trabajo manual, dependencias, calidad de exportación y responsabilidad de recuperación. Guarda una decisión fechada y la configuración exacta que cubre.

Comprobación final: otra persona puede reproducir ambos registros; monedas y plazos están claros; los datos de prueba quedan fuera de pagos reales; los objetos pendientes son visibles; el plan está confirmado; acceso y exportación están documentados; existe una persona autorizada para detener la ampliación. Conserva evidencias y fechas de configuración. Repite los casos afectados después de cambiar comisiones o integración de facturación.

Para una vía separada mediante red CPA, lleva la definición del acontecimiento y las condiciones de oferta a la cuenta de anunciante de AffiliateCore. Confirma el proceso adecuado para el producto antes de empezar. Ni la comparación ni el registro del piloto migran automáticamente. La cuestión organizativa cercana se trata en la guía sobre transferencia de responsabilidades del programa; aquí el resultado es una decisión de aceptación de producto.