PayPal

PayPal es un método de pago y una billetera, no solo una pasarela de tarjetas. Del lado de PayPal están la cuenta del comprador, los objetos de orden y de captura detrás de cada transacción, las suscripciones o acuerdos de facturación que haya, los reembolsos y el proceso propio de PayPal para disputas y protección al comprador. Del lado de AppBO están el contacto, el registro del pedido, el pipeline y los flujos de trabajo que actúan sobre un pago confirmado.

Lo agregas junto con las tarjetas, no en su lugar. Algunos compradores no escriben el número de su tarjeta en una página que no reconocen, pero hacen clic sin problema en un botón de PayPal, y en varios mercados esa preferencia es tan fuerte que marca la diferencia entre un checkout abandonado y una venta. El sentido de la integración es que un pago con PayPal produzca las mismas consecuencias que un pago con tarjeta (el mismo flujo de trabajo de entrega, las mismas etiquetas, el mismo movimiento de la oportunidad), para que el resto de tu automatización no tenga que fijarse en qué botón presionó el cliente.

El problema de la conciliación es la parte interesante. Dos procesadores significan dos fuentes de verdad sobre el dinero, dos procesos de reembolso, dos procesos de disputa y dos calendarios de liquidación. La integración solo está terminada cuando una persona que mira un contacto en AppBO puede ver qué se pagó sin importar el método, y cuando tu proceso de finanzas puede cuadrar ambos con el banco sin una hoja de cálculo de excepciones. Para eso hay que decidir a propósito qué campo registra el método y qué identificador se guarda dónde.

1. Confirma que la cuenta de PayPal sea del tipo correcto y esté verificada por completo: una cuenta de empresa, con la cuenta bancaria vinculada, el nombre del negocio confirmado y cualquier revisión de identidad terminada. Los pagos que entran a una cuenta sin verificar pueden quedar retenidos.
2. Decide para qué es PayPal. ¿Va a aceptar solo pagos únicos o también cobros recurrentes? Los cobros recurrentes por PayPal se comportan distinto de las suscripciones con tarjeta, y decidirlo después significa rehacer el checkout.
3. En la subcuenta de AppBO, abre la configuración de pagos e inicia la conexión con PayPal, autorizando con la cuenta de empresa que debe recibir los fondos. Después confirma a qué cuenta de PayPal quedó apuntando la conexión.
4. Si la conexión pide credenciales de API en lugar de una autorización alojada, créalas en el panel para desarrolladores de PayPal para el entorno correcto y guárdalas en la configuración de pagos de la plataforma, no en ningún otro lugar.
5. Mantén el entorno de pruebas (sandbox) y el de producción estrictamente separados. El sandbox de PayPal tiene sus propias cuentas, sus propias credenciales y sus propios accesos de comprador; construye y prueba todo en sandbox antes de tocar las credenciales de producción.
6. Configura la experiencia de checkout: dónde aparece el botón de PayPal respecto a los campos de la tarjeta, en qué moneda y si se permite pagar como invitado sin cuenta de PayPal. Esconder el botón anula el propósito de agregarlo.
7. Configura el nombre de marca y el comportamiento de regreso para que el comprador reconozca la página a la que lo redirigen y vuelva a un lugar que tenga sentido. Una página intermedia sin marca aumenta el abandono en el peor momento posible.
8. Decide la clave de identidad. PayPal devuelve el email de la cuenta de PayPal del comprador, que muchas veces no es el email que escribió en tu formulario. Elige si la búsqueda de contacto usa el email del formulario o el de PayPal, y aplícalo de forma consistente, o vas a crear un segundo contacto por cada comprador que use PayPal.
9. Agrega un campo personalizado en el contacto para registrar el método de pago y otro para guardar el identificador de la transacción o de la captura de PayPal. Estos dos campos son los que hacen posible la conciliación después.
10. Arma la automatización sobre el evento de pago confirmado, no sobre el regreso del comprador a tu página. Una redirección de PayPal se puede abandonar después de que el dinero se movió, y que el navegador regrese no prueba que hubo captura.
11. Arma de forma explícita las rutas de reversión: el reembolso y, por separado, el proceso de disputa o reclamo de PayPal, que tiene su propio ciclo de vida y sus propios plazos. Todo lo que otorgó un pago exitoso tiene que poder revocarse.
12. Verifica de principio a fin en sandbox con una cuenta de comprador de prueba: completa un pago, confirma que la plataforma lo registra, que el flujo de trabajo corrió y que se llenaron los campos de método e identificador.
13. Prueba en sandbox el caso de abandono: inicia un pago con PayPal y cierra la pestaña después de aprobarlo. Confirma qué cree tu sistema que pasó y corrígelo si la respuesta es incorrecta.
14. Cambia a las credenciales de producción y haz una transacción real pequeña con una cuenta real de PayPal, de principio a fin; después reembólsala y confirma que se dispara el flujo de reversión y que los fondos regresan.
15. Establece la conciliación como una rutina, no como una reacción: una comparación periódica de la actividad de PayPal con los registros de la plataforma, con alguien responsable de las excepciones. Configura alertas para los pagos que aparecen en un sistema y faltan en el otro.

De la plataforma a PayPal

• Los detalles del pedido para el pago previsto: monto, moneda, descripción del artículo y tus propios identificadores de referencia.
• Los destinos de regreso y de cancelación a los que vuelve el comprador después de aprobar o abandonar.
• Las solicitudes de captura, cuando el flujo primero autoriza y después captura.
• Las solicitudes de reembolso sobre una captura anterior, cuando se inician desde la plataforma.

De PayPal a la plataforma

• Los resultados de la aprobación y la captura del pago: completado, pendiente, rechazado o que requiere una acción adicional.
• Los identificadores de transacción, orden y captura, que son las claves para cualquier conciliación o reembolso posterior.
• Los datos del pagador tal como los tiene PayPal. El nombre, el email de la cuenta de PayPal y la dirección de envío registrada en su cuenta de PayPal.
• Las confirmaciones de reembolso y los avisos de disputas, reclamos y contracargos.
• Los resultados de los pagos recurrentes cuando se usa una suscripción o un acuerdo de facturación.

Lo que no se mueve

• Los datos de la tarjeta o de la fuente de fondos. El instrumento de pago del comprador se queda por completo dentro de PayPal.
• El proceso de protección al comprador y de disputas de PayPal. Los casos se manejan en el centro de resoluciones de PayPal, no en la plataforma.
• Los movimientos de liquidación y de saldo. Cuándo salen los fondos del saldo de PayPal hacia el banco es un asunto de PayPal.
• Las transacciones históricas de PayPal de antes de que existiera la conexión.
• Un libro contable unificado entre procesadores. Nada combina automáticamente las transacciones de PayPal y de tarjeta en un único total confiable. Ese es un trabajo de reportes que tienes que hacer tú.

Escenario: una página de checkout ofrece tarjeta y PayPal lado a lado. Una compradora elige PayPal, paga con un email distinto al del formulario y después abre una disputa.

1. La compradora llena el formulario del paso de checkout con jane.smith@company.com, lo que crea el contacto en AppBO o lo relaciona con uno existente.
2. Hace clic en el botón de PayPal en lugar de ingresar una tarjeta y la redirigen a PayPal para aprobar el pago.
3. Inicia sesión en PayPal con jsmith.personal@example.com (una dirección distinta) y aprueba.
4. PayPal confirma la captura y devuelve el identificador de la transacción junto con el email de PayPal de la pagadora.
5. La plataforma registra el pago en el contacto que ya se había creado con el email del formulario, porque la integración se configuró para buscar por el email del formulario y no por el de la pagadora. El email de la pagadora se escribe en un campo personalizado aparte para que soporte pueda encontrar a la compradora en PayPal más adelante.
6. Se dispara el flujo de trabajo de pago confirmado: escribe PayPal en el campo de método de pago, escribe el identificador de la transacción en su campo personalizado, le pone al contacto la etiqueta comprado, mueve la oportunidad a Ganada y envía el recibo y el email de entrega.
7. El navegador de la compradora nunca vuelve a la página de agradecimiento porque cerró la pestaña. El pedido se completa de todos modos, porque la automatización corrió sobre el evento de pago y no sobre la visita a la página.
8. Al final de la semana, el proceso de finanzas exporta la actividad de PayPal y compara los identificadores de transacción con el campo personalizado de la plataforma. Cada pago de PayPal tiene su registro correspondiente; la única excepción es un pago pendiente que espera acreditarse, que se anota y se vuelve a revisar la semana siguiente.
9. Tres semanas después, la compradora abre una disputa en PayPal. Llega un aviso y un flujo de trabajo le pone al contacto la etiqueta pago-en-disputa, le quita la etiqueta comprado, revoca el acceso a la descarga y crea una tarea para finanzas con el identificador de la transacción.
10. Finanzas presenta la evidencia en el centro de resoluciones de PayPal (el único lugar donde se puede trabajar el caso) usando el registro de entrega que la plataforma guarda en el contacto.
11. PayPal resuelve a favor del comercio. La tarea se cierra, se quita la etiqueta de disputa, se restaura la etiqueta comprado y se restablece el acceso, con toda la secuencia visible en la línea de tiempo del contacto.

Límites de uso

PayPal aplica sus propios límites de API y varían según el endpoint; consulta la documentación vigente de PayPal en lugar de suponer una cifra, y agrega espera progresiva ante las respuestas limitadas. Para la mayoría de las cuentas de AppBO, la restricción práctica no es el límite de la API sino la carga de trabajo de conciliación, que crece en proporción al volumen de transacciones a menos que se automatice desde el principio.

Reintentos e idempotencia

PayPal admite un identificador de solicitud en las llamadas de orden y de captura para que una solicitud reintentada no se trate como un pago nuevo. Úsalo, y revisa el nombre vigente del campo en la referencia de PayPal en lugar de adivinarlo. Los avisos se entregan al menos una vez y se reintentan, así que elimina duplicados por el identificador de la transacción o del evento. El reintento más riesgoso es el de una captura: reintentarla sin el encabezado de idempotencia puede cobrar dos veces, y reembolsar una captura duplicada es una peor experiencia para el cliente que un checkout fallido.

Trampas en el mapeo de campos

El email del pagador es la trampa más grande de las integraciones con PayPal: es la dirección de la cuenta de PayPal del comprador, no necesariamente la de tu formulario, y tratarlas como si fueran lo mismo crea contactos duplicados a gran escala. Los códigos de moneda tienen que coincidir con lo que la cuenta de PayPal está configurada para aceptar. El formato de los montos y la precisión decimal son estrictos. La dirección de envío que devuelve PayPal es la de la cuenta de PayPal del comprador, que puede no ser donde espera recibir el pedido: decide qué dirección manda y dilo en el checkout.

Estados pendientes y demorados

A diferencia de una autorización con tarjeta, un pago con PayPal puede quedar en estado pendiente de forma legítima. En revisión, esperando un cheque electrónico o retenido por un paso de verificación. Tratar un pendiente como pagado envía productos que no te han pagado; tratarlo como fallido pierde ventas. Manéjalo como un estado propio con su propio flujo de trabajo, y ten una ruta que complete el pedido cuando se acredite.

Creación de duplicados

Hay dos causas: la diferencia de email del pagador que se describió arriba, y los compradores que abandonan y vuelven a intentar la redirección de PayPal, lo que produce dos órdenes para una sola intención de compra. Identifica las órdenes con tu propio identificador de referencia enviado dentro de la orden de PayPal, y revisa si ya existe un pago completado con esa referencia antes de capturar otro.

Pruebas frente a producción

El sandbox de PayPal es un mundo completamente aparte, con sus propias cuentas de comprador y de comercio y sus propias credenciales. Las credenciales de sandbox en un checkout en producción fallan en silencio y de formas confusas; las credenciales de producción en una prueba generan cobros reales. Nombra las credenciales sin ambigüedad y confirma el entorno como parte de la salida a producción, no después.

Vencimiento de la autenticación

Las credenciales de API se pueden rotar o revocar en PayPal, y la conexión también se puede romper por restricciones en la cuenta después de una revisión. El síntoma es que el botón de PayPal falla en el checkout, lo que cuesta ventas sin que nadie lo note, así que vigila la tasa de éxito del checkout por método y no solo en total.

Lo que suele fallar

• La entrega disparada por el regreso del comprador a la página de agradecimiento, así que los pagos con la pestaña abandonada nunca se entregan.
• Los pagos pendientes tratados como completados.
• Contactos duplicados por la diferencia en el email del pagador.
• Credenciales de sandbox olvidadas en una configuración de producción.
• Reembolsos hechos en PayPal sin la reversión correspondiente en la plataforma, lo que deja el acceso otorgado.
• Disputas atendidas tarde porque nadie es responsable del aviso.
• Diferencias de moneda o de decimales que rechazan pedidos que por lo demás son válidos.