Authorize.net

Authorize.net es una pasarela de pagos y no un facilitador de pagos, y esa diferencia define toda la integración. Del lado de la pasarela están el identificador de inicio de sesión de la API y la clave de transacción, los tipos de transacción (autorizar, capturar, autorizar y capturar, anular, reembolsar), el almacén de perfiles de clientes para los métodos de pago guardados y los filtros antifraude propios de la pasarela. Detrás de la pasarela hay una cuenta de comercio separada con un banco adquirente o un procesador, que es donde de verdad se liquida el dinero. Del lado de AppBO están el contacto, el pedido, el pipeline y los flujos de trabajo.

La eliges cuando la cuenta de comercio ya existe. Los negocios establecidos suelen tener un acuerdo de procesamiento negociado, una relación larga con un adquirente o una clasificación de industria que un facilitador de pagos no acepta, y en todos esos casos la pasarela es el componente que se cambia y el procesamiento de fondo se queda donde está. También es común en mercados y sectores donde la pasarela de siempre lleva años instalada y el costo de migrar no es solo técnico.

Lo que pierdes frente a un facilitador moderno es amplitud y pulido: menos métodos de pago alternativos, una API más antigua, un modelo de liquidación basado en un lote diario en lugar de una captura continua y reportes que viven en la interfaz propia de la pasarela. Lo que ganas es continuidad con una relación bancaria existente. El trabajo de integración consiste en que la automatización de la plataforma sea exacta a pesar del modelo por lotes: en concreto, dejar de tratar una autorización como dinero recibido.

1. Antes de configurar nada, confirma que todas las piezas estén en su lugar: una cuenta activa de la pasarela Authorize.net, una cuenta de comercio activa detrás de ella y las dos vinculadas correctamente. Una pasarela sin una cuenta de comercio que funcione autoriza y nunca liquida.
2. Ubica las credenciales en la interfaz de la pasarela: el identificador de inicio de sesión de la API y una clave de transacción que generas ahí. Trata la clave de transacción como una contraseña: genérala, guárdala en la configuración de pagos de la plataforma y no guardes copias en otro lado.
3. Genera una clave de firma o de hash si piensas validar las notificaciones de la pasarela, y guárdala por separado. La verificación solo es posible si la configuras antes de necesitarla.
4. Usa el entorno de pruebas (sandbox) de la pasarela para todo el trabajo inicial. Tiene sus propias credenciales y su propio endpoint, y es el único lugar seguro para ensayar rechazos y condiciones de error.
5. En la subcuenta de AppBO, abre la configuración de pagos, elige Authorize.net e ingresa las credenciales del entorno en el que estás trabajando. Confirma que la plataforma informe una conexión exitosa en lugar de asumir que el silencio significa éxito.
6. Decide el tipo de transacción. Autorizar y capturar es el modelo más simple y sirve para entregas inmediatas. Autorizar y después capturar sirve para negocios que despachan más tarde, pero significa que tu automatización tiene que distinguir una autorización aprobada de un pago capturado.
7. Entiende y configura el lote diario. Authorize.net liquida en un lote a una hora de corte que tú defines; una transacción aprobada después del corte se liquida al día siguiente. Elige una hora de corte que coincida con tu jornada operativa y anótala donde tu equipo de finanzas la pueda ver.
8. Revisa los filtros antifraude de la pasarela antes de salir en vivo. Los filtros demasiado agresivos retienen transacciones legítimas para revisión, y una transacción retenida no está ni aprobada ni rechazada: tus flujos de trabajo necesitan un camino para ella.
9. Decide si vas a guardar los métodos de pago en el almacén de perfiles de clientes de la pasarela para cobros repetidos o recurrentes y, si es así, guarda el identificador del perfil en un campo personalizado de AppBO para que los cobros posteriores puedan hacer referencia a él.
10. Mapea los códigos de respuesta que te importan. La pasarela devuelve un código de respuesta más un código de motivo más específico, y la diferencia entre un rechazo blando que vale la pena reintentar y un rechazo duro que nunca va a pasar importa para cualquier lógica de cobranza. Tómalos de la referencia actual de la pasarela en lugar de deducirlos.
11. Arma la automatización sobre la señal de aprobado y capturado, y arma caminos separados para rechazado, retenido para revisión y anulado. Tratar igual todo lo que no es una aprobación es como se termina persiguiendo a clientes por pagos que en realidad nunca se intentaron.
12. Agrega campos personalizados para el identificador de transacción de la pasarela y, cuando se use, para el identificador del perfil del cliente. Sin el identificador de transacción, un reembolso o una anulación no se pueden rastrear.
13. Prueba a fondo en el sandbox con los números de tarjeta de prueba de la pasarela: una aprobación, un rechazo, una falla de verificación de dirección y una falla del código de la tarjeta. Confirma que cada una produzca el registro y el flujo que planeaste.
14. Pasa a las credenciales de producción y haz una transacción real pequeña de punta a punta. Confirma la aprobación, confirma el registro en la plataforma, después observa cómo se liquida en el siguiente lote y confirma que los fondos lleguen a la cuenta de comercio. Luego anúlala o reembólsala y confirma el camino de reversión.
15. Establece la conciliación contra los reportes de lotes de la pasarela y vigila las fallas silenciosas: transacciones aprobadas que nunca se liquidaron, transacciones atascadas en revisión y una tasa de rechazo en aumento, que normalmente significa que algo cambió en el procesador y no de tu lado.

De la plataforma a la pasarela

• Solicitudes de transacción: monto, moneda, tipo de transacción y la referencia del pedido.
• Los datos de pago capturados en el checkout, que se envían a la pasarela para su autorización.
• Nombre y dirección de facturación, y el código de seguridad de la tarjeta, cuando están activas la verificación de dirección y la del código de la tarjeta.
• La creación de perfiles de clientes y los cobros posteriores contra un perfil guardado, cuando se usa.
• Solicitudes de anulación y de reembolso, con referencia a un identificador de transacción anterior.

De la pasarela a la plataforma

• El resultado de la autorización: aprobada, rechazada, retenida para revisión o error.
• El código de respuesta y el código de motivo más específico, más el código de autorización cuando se aprueba.
• El identificador de transacción, que es la clave para cualquier anulación, reembolso o consulta posterior.
• Los resultados de la verificación de dirección y del código de la tarjeta.
• El identificador del perfil del cliente cuando se guarda un método de pago.
• El resultado de la liquidación, que sigue al lote diario y no a la autorización.

Lo que no se mueve

• Los números completos de tarjeta hacia el almacenamiento de la plataforma. La tarjeta se envía para autorización y la referencia que se guarda es un identificador de perfil, no una tarjeta.
• El detalle de la cuenta de comercio y de los depósitos. Qué deposita el adquirente, y cuándo, queda en manos del adquirente y del banco.
• La configuración de los filtros antifraude de la pasarela y su cola de transacciones retenidas, que se gestionan en la interfaz propia de la pasarela.
• Las transacciones de antes de que se configurara la conexión.
• Los métodos de pago alternativos y las billeteras digitales que la pasarela no admite. Si los necesitas, necesitas un segundo procesador en paralelo.

Escenario: un proveedor establecido con su propia cuenta de comercio vende un servicio en un formulario de pedido de AppBO, autoriza en el checkout y captura al despachar.

1. La conexión se configura con las credenciales de producción, el tipo de transacción en solo autorizar y la hora de corte del lote al inicio de la noche, para que coincida con la jornada del almacén.
2. Un cliente completa el formulario de pedido. La plataforma envía a la pasarela una solicitud de autorización con el monto, la dirección de facturación y el código de seguridad de la tarjeta.
3. La pasarela devuelve aprobada, con un código de autorización, un identificador de transacción y un resultado de verificación de dirección aprobado.
4. Con la aprobación se dispara un flujo de trabajo: escribe el identificador de transacción en un campo personalizado, le pone al contacto la etiqueta pedido-autorizado, mueve la oportunidad a Pendiente de despacho y envía una confirmación del pedido que tiene el cuidado de decir que la tarjeta se autorizó, no que se cobró.
5. Lo clave es que no arranca la secuencia de entrega completada, porque una autorización no es dinero. Esa diferencia es toda la razón por la que existen los dos caminos.
6. El almacén despacha a la mañana siguiente. Se envía una captura contra el identificador de transacción guardado y la pasarela la confirma.
7. Con la captura corre un segundo flujo: cambia la etiqueta a pedido-pagado, mueve la oportunidad a Ganada, envía el aviso de despacho con el recibo y arranca la secuencia posterior a la compra.
8. Esa noche se liquida el lote. Al día siguiente los fondos aparecen en la cuenta de comercio y finanzas concilia el reporte del lote con los registros de la plataforma por identificador de transacción.
9. El pedido de un segundo cliente se aprueba, pero un filtro antifraude lo marca y lo retiene para revisión. La plataforma registra un resultado retenido; un flujo le pone al contacto la etiqueta pago-en-revision, suprime el email de confirmación y crea una tarea para que finanzas tome una decisión en la interfaz de la pasarela.
10. Finanzas lo aprueba en la pasarela. La transacción sigue adelante, el camino de captura corre con normalidad y se quita la etiqueta de retenido.
11. La tarjeta de un tercer cliente se rechaza con un código de motivo que indica fondos insuficientes. Es un rechazo blando. El flujo de pago rechazado envía un enlace amable para reintentar en lugar de dar el pedido por perdido, y otro código de motivo que indica una tarjeta inválida lleva en cambio a un flujo que pide otro método de pago.

Límites de uso

La pasarela aplica sus propios límites de solicitudes y los documenta de su lado; revisa la referencia actual en lugar de suponer, y espera antes de reintentar en lugar de insistir a la fuerza. El límite con más consecuencias es operativo: el lote diario. Todo lo que se aprueba después de la hora de corte se liquida un día más tarde, así que las expectativas de flujo de caja y cualquier automatización que dependa de la liquidación tienen que tener en cuenta ese desfase.

Reintentos e idempotencia

Trata cada solicitud de pago como potencialmente no idempotente y protégela de tu lado: antes de enviarla, revisa si ya existe una transacción aprobada para esa referencia de pedido, y guarda el identificador de transacción en el momento en que lo recibas. Un reintento a ciegas después de un tiempo de espera agotado es como a un cliente lo autorizan dos veces. Las anulaciones y los reembolsos deben hacer referencia al identificador de la transacción original, y la elección entre uno y otro depende de si el lote ya se liquidó: anular una transacción sin liquidar es más limpio que reembolsar una liquidada, así que arma los dos caminos.

Trampas del mapeo de campos

Los códigos de respuesta y los códigos de motivo son dos campos distintos y los dos importan; juntarlos pierde la información que distingue un rechazo que se puede reintentar de uno permanente. Los resultados de la verificación de dirección y del código de la tarjeta están separados de la aprobación en sí, así que una transacción puede aprobarse aunque falle la verificación: define tu política a propósito. El formato de los montos y la precisión decimal son estrictos, y la pasarela perdona menos los datos mal formados que las API más nuevas. Los límites de longitud en los campos de nombre, dirección y descripción rechazan la transacción de plano en lugar de recortar el texto.

Autorización frente a captura

Esta es la trampa que define todo. Una autorización aprobada es una retención, no un pago, y vence. El plazo depende de la red de la tarjeta y del emisor, así que revísalo en lugar de suponerlo. Entregar con la autorización y nunca capturar significa despachar gratis; capturar después de que vence la retención significa una captura fallida en un pedido que ya despachaste. Automatiza el paso de captura y configura alertas para las autorizaciones que envejecen sin capturarse.

Creación de duplicados

La pasarela tiene un comportamiento de ventana de duplicados que puede rechazar una transacción idéntica enviada poco después de otra, lo que parece un rechazo misterioso cuando un cliente pide legítimamente lo mismo dos veces. Cambia la referencia del pedido en cada transacción para que las compras repetidas genuinas no se bloqueen, y no dependas de esa ventana como tu protección contra duplicados.

Entorno de pruebas frente a producción

El sandbox y producción tienen credenciales separadas y endpoints separados, y la falla clásica del día del lanzamiento es usar credenciales de producción contra el endpoint del sandbox, o al revés. Lo primero no cobra nada y no avisa; lo segundo cobra dinero real durante las pruebas. Verifica el entorno de forma explícita y conserva las credenciales del sandbox después para las pruebas de regresión.

Vencimiento de la autenticación

La clave de transacción se puede regenerar en la interfaz de la pasarela, y regenerarla invalida la anterior de inmediato, lo que rompe la conexión de la plataforma en el momento en que alguien lo hace por otro motivo. Registra quién tiene permiso para rotarla y haz que actualizar la plataforma sea parte de ese procedimiento. Vigila también la clave de firma, si validas notificaciones.

Lo que suele romperse

• La entrega se dispara con la autorización y no con la captura.
• Autorizaciones que se quedan sin capturar hasta que vence la retención.
• Una clave de transacción regenerada en la pasarela y nunca actualizada en la plataforma.
• Transacciones retenidas para revisión sin un camino en ningún flujo, lo que deja a los clientes sin respuesta.
• Rechazos blandos y duros tratados igual, así que se abandonan ventas recuperables.
• Una hora de corte del lote mal entendida, que produce diferencias de conciliación que en realidad son solo de tiempos.
• Credenciales de sandbox y de producción cruzadas en el lanzamiento.