Integrate Authorize.net con Gravity Forms en 2026

Para integrar Authorize.net con Gravity Forms necesitás instalar el add-on oficial desde el dashboard de WordPress, configurar tu API Login ID y Transaction Key en los ajustes del plugin, y crear un feed que mapee los campos del formulario a los datos de pago. El proceso completo lleva menos de 30 minutos si tenés las credenciales a mano.

WordPress es un sistema de gestión de contenidos de código abierto creado por Matt Mullenweg y desarrollado por Automattic para crear y administrar sitios web y blogs sin necesidad de conocimientos técnicos avanzados.

Qué es la integración Authorize.net con Gravity Forms

Authorize.net es un gateway de pagos de Visa que procesa transacciones con tarjeta de crédito, débito y pagos digitales para sitios de e-commerce. Gravity Forms es el plugin de formularios premium más usado en WordPress para crear flujos de pago, registros y checkout. La integración entre ambos te permite cobrar directamente desde cualquier formulario WordPress sin redirigir al usuario a una página externa de pago.

Esta combinación la uso en varios clientes que no quieren WooCommerce completo pero sí necesitan cobrar algo concreto: una consulta, un producto digital, una membresía simple. El add-on oficial existe hace años y, aunque no tiene todas las características avanzadas de Stripe, cumple bien si tu procesador bancario ya es Authorize.net (muy común en clientes con cuentas merchant en Estados Unidos).

Requisitos previos para integrar Authorize.net con Gravity Forms

Antes de tocar cualquier ajuste, revisá que tenés todo esto:

• Gravity Forms 2.3.0 o superior con licencia Elite (el add-on de Authorize.net no está disponible en la licencia Basic).
• Certificado SSL activo en tu dominio. Sin HTTPS no podés procesar pagos, punto. Si tu hosting no te lo da por defecto, Let’s Encrypt lo resuelve gratis.
• Cuenta de Authorize.net con acceso al Merchant Interface. Si estás probando, podés crear una cuenta sandbox gratuita en su sitio.
• PHP con extensión cURL habilitada. Casi cualquier hosting decente la tiene, pero en setups muy restrictivos puede fallar.
• API Login ID y API Transaction Key. Los obtenés desde el Merchant Interface de Authorize.net bajo Account > Settings > Security Settings > API Credentials and Keys.

Ojo: el API Login ID y la Transaction Key son distintos a tu usuario y contraseña del Merchant Interface. Es un error clásico meter las credenciales de login ahí. (Sí, me pasó con un cliente a las 11 de la noche antes de un lanzamiento.)

Instalación del add-on oficial de Authorize.net

Entrá a tu WordPress, navegá a Forms > Add-Ons. Si tenés licencia Elite vas a ver el add-on de Authorize.net en la lista. Cliqueás «Install» y después «Activate».

Si no aparece, verificá que el plugin base de Gravity Forms esté actualizado. A veces la lista de add-ons no se refresca con versiones viejas del core del plugin.

Una vez activado, aparece una nueva sección en Forms > Settings > Authorize.net. Ahí es donde vas a cargar las credenciales. La diferencia entre la versión Basic y Advanced del add-on que mencionan algunas guías viejas ya no aplica: desde la documentación oficial actualizada, hay un único add-on unificado que maneja tanto pagos únicos como recurrentes.

Configuración de credenciales API de Authorize.net

En Forms > Settings > Authorize.net vas a ver dos campos: API Login ID y Transaction Key.

Para obtenerlos, entrá al Merchant Interface de Authorize.net (login en su sitio) y navegá a Account > Settings > Security Settings > API Credentials and Keys. El API Login ID lo ves directamente. La Transaction Key la tenés que generar (o regenerar si ya existe): hacés clic en «New Transaction Key», confirmás con tu contraseña, y te lo muestra una sola vez, así que copialo enseguida.

Guardás esas credenciales en Gravity Forms y el plugin intenta validarlas automáticamente. Si hay un error de conexión acá, casi siempre es cURL mal configurado o firewall del servidor bloqueando salida a los endpoints de Authorize.net. Más contexto en al crear una landing page con formularios.

Sobre el entorno: hay dos modos. Producción conecta a la API real y cobra tarjetas reales. Sandbox conecta al entorno de pruebas. Para sandbox necesitás credenciales específicas de sandbox, que son distintas a las de producción. No mezcles las dos.

Creación y mapeo del feed en el formulario

Configurar las credenciales globales es el paso uno. El paso dos es crear un feed para cada formulario que va a procesar pagos. Un feed es la conexión entre un formulario específico y Authorize.net.

Abrís el formulario, vas a Settings > Authorize.net, y hacés clic en «Add New». Ahí configurás:

• Transaction Type: Products and Services (pago único), Subscription (recurrente), o Donate.
• Payment Amount: puede ser un campo del formulario (para que el usuario elija) o un monto fijo que hardcodeás vos.
• Card Fields: mapeás qué campo del formulario corresponde al número de tarjeta, fecha de vencimiento y código de seguridad. Gravity Forms tiene campos de tarjeta de crédito integrados específicamente para esto.
• Billing Information: nombre, dirección, ciudad, código postal. Estos campos alimentan la verificación AVS (Address Verification System), que es lo que previene el error 27.

Los campos de dirección son técnicamente opcionales a nivel de formulario, pero si tu cuenta de Authorize.net tiene AVS habilitado y la dirección no coincide con la que tiene registrada el banco del cliente, la transacción se rechaza con código 27. Mi recomendación: siempre mapeá al menos código postal para reducir rechazos innecesarios.

Según la documentación oficial de Gravity Forms, también podés configurar condiciones condicionales en el feed: que solo se procese el pago si cierto campo tiene cierto valor. Útil si en el mismo formulario tenés opciones de pago y opciones de consulta gratuita.

Configuración de pagos únicos y recurrentes

Para pagos únicos, con el feed de tipo «Products and Services» alcanza. El cliente llena el formulario, se procesa la tarjeta en el momento, y si todo va bien, Gravity Forms marca el entry como pagado.

Para suscripciones, Authorize.net usa su sistema de Automated Recurring Billing (ARB). En el feed seleccionás Transaction Type: Subscription y configurás:

• Billing Cycle: diario, semanal, mensual, anual.
• Recurring Amount: puede ser el mismo campo de monto o uno diferente.
• Start Date: cuándo arranca la primera facturación.
• Total Occurrences: si la suscripción tiene fin (ponés el número de cobros) o si es indefinida.

ARB funciona del lado de Authorize.net: una vez que la suscripción queda creada, Authorize.net se encarga de cobrar en cada ciclo sin que WordPress tenga que hacer nada. El tema es que el manejo de cancelaciones queda medio en el aire si no configurás bien los webhooks o no usás un plugin complementario que gestione el estado. Para algo más robusto con membresías, la integración con MemberPress sobre Gravity Forms es más sólida, pero eso ya es otro nivel de setup.

Pruebas en ambiente sandbox

Antes de habilitar producción, probá el flujo completo en sandbox. Activate el modo sandbox en los ajustes globales del add-on y cargá las credenciales de tu cuenta sandbox de Authorize.net.

Authorize.net tiene números de tarjeta de prueba específicos. El más usado para aprobar transacciones es 4111111111111111 (Visa), con cualquier fecha futura y cualquier CVV. Para simular un rechazo, podés usar 4222222222222. Complementá con prueba la integración en staging primero.

Hacé el flujo completo: llenás el formulario como si fueras un cliente real, submitís, verificás que Gravity Forms registra el entry con estado «Paid», y revisás en el Merchant Interface sandbox que la transacción aparece. Si las dos cosas coinciden, el setup está bien.

Después de aprobar en sandbox, cambiás a producción, reemplazás las credenciales por las de producción, y listo. No hay que reconfigurar los feeds.

Troubleshooting y errores comunes

Error 33: campo requerido vacío

El código de error 33 de Authorize.net indica que falta un campo obligatorio en la transacción. Casi siempre es que el mapeo del feed quedó incompleto: revisá que el número de tarjeta, fecha de vencimiento y código de seguridad estén mapeados a campos reales del formulario, no a campos vacíos o inexistentes.

Error 27: AVS mismatch

El código 27 significa que la dirección que mandaste no coincide con la que tiene el banco del cliente. Tres causas posibles: el cliente escribió mal su dirección, el formulario no manda dirección (y tu cuenta de Authorize.net requiere AVS), o la configuración AVS en el Merchant Interface está muy estricta. Podés ajustar la política AVS en Account > Settings > Address Verification Service para ser más permisivo, aunque eso tiene implicaciones de seguridad.

Conexión fallida o credenciales inválidas

Si el plugin no puede validar las credenciales, verificá tres cosas en orden: que copiaste el API Login ID y la Transaction Key correctamente (sin espacios), que estás usando las credenciales del entorno correcto (sandbox vs producción), y que el servidor puede hacer llamadas salientes al endpoint de Authorize.net. En servidores con firewall muy restrictivo, a veces hay que whitelistear las IPs de Authorize.net.

Monto cero procesado

Si las transacciones se aprueban pero con monto $0.00, el campo de monto en el feed no está correctamente mapeado. Revisá que «Payment Amount» apunte a un campo que realmente contiene el valor, o que el monto fijo esté configurado. Un error clásico es tener un campo de «total» calculado en el formulario y mapear el campo de precio individual en vez del campo de total.

Consideraciones de seguridad y compliance PCI-DSS

Authorize.net con Gravity Forms puede operar en dos modos respecto a los datos de tarjeta: directo (los datos pasan por tu servidor) o tokenizado via Accept.js.

Con Accept.js, los datos de tarjeta nunca tocan tu servidor de WordPress: el JavaScript de Authorize.net los tokeniza en el browser del cliente antes de que el formulario haga submit. Esto reduce drásticamente tu scope de compliance PCI-DSS, porque no sos vos quien maneja el PAN (Primary Account Number).

Según los requisitos del add-on, el add-on oficial ya usa Accept.js por defecto en las versiones actuales. Pero confirmalo en tu instalación: en los ajustes del add-on debería aparecer la opción de tokenización activa.

SSL es no-negociable. Si tu sitio WordPress vive en un hosting que no tiene SSL incluido (o que te cobra extra), considerá cambiarte a algo que lo tenga por defecto, como el hosting WordPress de Donweb que ya incluye certificado en todos los planes.

Lo que no hay que hacer nunca: guardar números de tarjeta en metadatos de entries de Gravity Forms. Gravity Forms no lo hace por defecto, pero si tenés plugins de logging o custom code que loguea todos los campos del formulario, eso puede capturar datos de tarjeta. Revisá cualquier plugin de audit log que tengas activo. Esto se conecta con lo que analizamos en después de actualizar WordPress en producción.

Tabla comparativa: Authorize.net vs alternativas en Gravity Forms

Para clientes latinoamericanos, Authorize.net no suele ser la primera opción: no procesa en la mayoría de los países de la región y requiere cuenta merchant en EEUU o Canadá. Si estás en Argentina o México, Stripe o MercadoPago son más prácticos. Authorize.net brilla cuando ya tenés una merchant account establecida con algún banco norteamericano o procesador que lo requiere.

Qué está confirmado y qué no en 2026

Confirmado

• El add-on oficial de Authorize.net requiere Gravity Forms licencia Elite (no está en Basic ni Pro).
• Accept.js está integrado para tokenización y reduce el scope PCI-DSS.
• ARB para suscripciones recurrentes funciona nativamente desde el add-on.
• Gravity Forms 2.3.0 es la versión mínima requerida según documentación oficial.

A verificar según tu setup

• La disponibilidad de Authorize.net en tu país: el gateway tiene restricciones geográficas y no todos los procesadores lo soportan fuera de Norteamérica.
• Si usás un page builder que interfiere con los campos de tarjeta de crédito de Gravity Forms (algunos builders custom rompen el campo de CC).
• El comportamiento exacto de webhooks en cancelaciones de suscripción: el add-on oficial no siempre sincroniza estados de manera automática con Gravity Forms Entries.

Preguntas Frecuentes

¿Necesito licencia Elite de Gravity Forms para usar Authorize.net?

Sí. El add-on oficial de Authorize.net solo está disponible con la licencia Elite de Gravity Forms, que en 2026 cuesta USD 259/año. Las licencias Basic (USD 59) y Pro (USD 159) no incluyen los add-ons de pasarelas de pago avanzadas. Si tenés licencia Pro y querés evitar el upgrade, hay plugins de terceros que conectan Authorize.net con Gravity Forms, aunque la integración oficial es más estable y tiene soporte dedicado.

¿Cómo obtengo el API Login ID y la Transaction Key de Authorize.net?

Los encontrás en el Merchant Interface de Authorize.net bajo Account > Settings > Security Settings > API Credentials and Keys. El API Login ID está visible directamente. La Transaction Key hay que generarla haciendo clic en «New Transaction Key» e ingresando tu contraseña; solo se muestra una vez. Guardala en ese momento porque si la perdés hay que generar una nueva (lo cual invalida la anterior).

¿Por qué mis transacciones de Authorize.net están siendo rechazadas con error 27?

El error 27 es un AVS mismatch: la dirección enviada no coincide con la del banco del cliente. Podés resolverlo de dos formas: agregar campos de dirección obligatorios al formulario y mapearlos en el feed (especialmente el código postal), o relajar la política AVS en el Merchant Interface de Authorize.net bajo Account > Settings > Address Verification Service. La segunda opción es más rápida pero aumenta levemente el riesgo de fraude.

¿Cómo configuro suscripciones recurrentes con Authorize.net en Gravity Forms?

En el feed del formulario, seleccionás Transaction Type: Subscription. Después configurás el Billing Cycle (mensual, anual, etc.), el monto de la suscripción, y si tiene fecha de fin o es indefinida. Authorize.net gestiona el cobro recurrente desde su lado mediante ARB (Automated Recurring Billing), por lo que WordPress no necesita estar activo para procesar cada cobro. La cancelación, en cambio, requiere gestión manual o un plugin complementario que sincronice el estado.

¿Qué alternativas tengo a Authorize.net para Gravity Forms en Argentina?

Stripe es la alternativa más recomendable si procesás en pesos argentinos o tenés clientes en LATAM: el add-on oficial de GF está disponible con Elite y soporta más de 40 países. MercadoPago no tiene add-on oficial de Gravity Forms pero hay integraciones de terceros funcionales. Para ventas en Argentina específicamente, MercadoPago tiene la ventaja de ser el método de pago que más conocen los compradores locales, con cuotas incluidas.

Conclusión

Integrar Authorize.net con Gravity Forms es un proceso directo si tenés los prerrequisitos en orden: licencia Elite, SSL, y las credenciales API correctas. El add-on oficial hace bien su trabajo, cubre pagos únicos y suscripciones ARB, y la tokenización via Accept.js le saca presión al tema PCI-DSS.

Dicho eso, en 2026 Authorize.net sigue siendo una opción muy específica para clientes con merchant accounts norteamericanas. Si estás armando un proyecto nuevo para el mercado latinoamericano y no tenés un motivo concreto para usar Authorize.net, Stripe te va a dar menos fricción y más documentación disponible en español. El flujo de setup es casi idéntico, el add-on de GF es igual de maduro, y la cobertura geográfica es considerablemente mejor.

¿Cuándo sí tiene sentido Authorize.net? Cuando el cliente ya lo tiene, cuando su banco o procesador lo requiere, o cuando hay integraciones legacy que dependen de ese gateway específico. En esos casos, el add-on oficial de Gravity Forms hace lo que tiene que hacer sin dramas.

Fuentes

• Gravity Forms Docs – Configuración del Add-On de Authorize.net
• Gravity Forms Docs – Creación de feeds para Authorize.net
• Gravity Forms Docs – Requisitos del Add-On de Authorize.net
• Gravity Forms – Página oficial del add-on de Authorize.net
• Authorize.net – Directorio de partners: Gravity Forms