soap - developer - portal paypal

Documentación de PayPal(REST, Clásico: SOAP y NVP) ¿Qué elegir?

Question

Necesito desarrollar una solución de pago usando las API de PayPal. En realidad, comencé la fase de documentación (en http://developers.paypal.com )

Encontré que las API REST son comprensibles, todavía no tengo una idea de cómo implementarlas con SpringMVC, así que solo estoy usando cURL para probarlas. (¿Alguna ayuda sobre esto?)

Por otro lado, las API clásicas son confusas. (por ejemplo, qué podemos hacer con las cuentas adaptables y cuál es la diferencia entre Express Checkout y Adaptive Payments, etc.).

Otra cosa es que debemos elegir entre crear un formulario oculto (html) o usar API. (Necesito una explicación)

La documentación es muy larga y estoy realmente confundido, no sé qué elegir (obviamente, las API REST son mejores para pagos simples, pero realmente quiero saber más sobre SOAP y NVP ...)

Soy novato, ¿alguien puede ser voluntario y ayudarme en esto?

Gracias !

Answer 1

Después de haber hecho PayPal-integration-dance un par de veces (aunque hace algunos años) permítanme resumir mis pensamientos (y tengan en cuenta que las cosas pueden haber cambiado un poco)

El motivo de la profusión de API / métodos de integración de PayPal se debe a la amplia gama de lugares que desean que puedan ofrecerle el pago de asistencia técnica:

• Si todo lo que tiene es un blog, alojamiento de HTML estático, sitio de comercio electrónico estándar o alguna otra tecnología web "primitiva", enviar formularios HTML ocultos es bastante, la única opción. Sospecho que este es el mecanismo original que usó PayPal, y aunque tienen que seguir manteniéndolo para siempre , no querrá usar este enfoque hoy en día desde un marco web moderno como SpringMVC.

• La NVP API es otro esquema de integración duradero que fue apropiado en un momento en el que unir efectivamente los parámetros en una URL era lo único que podían hacer sus clientes. No hay una buena razón para usar esta API en estos días cuando la API REST JSON está disponible; la mayoría de las personas considera que JSON es mucho más fácil de leer que los parámetros codificados por URL.

• Cronológicamente presentado a continuación, sospecho, la API SOAP refleja un momento en que XML iba a gobernar el mundo. En algunos (muy estrictos y / o tradicionales) lugares, todavía lo hace. Una vez más, en estos días, es probable que no siga este camino si tiene otra opción: el uso con Java generalmente implica una estrecha integración con un SOAP Framework como Apache CXF y montañas de archivos .java generados por la .java .

• La API REST es la más moderna y (IMHO) más agradable de usar de Java-land, y es la opción que recomiendo. Parece que es lo que PayPal preferiría que usara también, por lo que pasaré el resto de esta respuesta hablando.

Como desarrollador de Java, cuando selecciona la API REST obtiene una opción adicional de usar el SDK de PayPal o implementar su propio esquema de integración. Considere usar el SDK si:

• Puede prever que su integración de PayPal será muy grande y / o utilizará funciones API avanzadas

• No tiene ningún otro punto de integración HTTP y, por lo tanto, no tiene infraestructura para llamar a los métodos HTTP desde su código (por ejemplo, Apache HttpClient o la funcionalidad RestTemplate integrada en Spring 3)

• No tiene (o no quiere) un analizador JSON disponible

Como ya has estado usando la API a través de cURL y entiendes las llamadas y su secuencia, probablemente estés indeciso sobre esto. Si no tienes demasiada presión de tiempo, te recomendaría ir por el camino propio usando (y aprendiendo) Apache HttpClient junto con una biblioteca JSON como Jackson : son herramientas valiosas en tu arsenal y podrás casi seguramente los usaré nuevamente en futuras integraciones.

Otro consejo de desarrollo, que se aplica a la opción API REST: si usa un "servidor stub" como este para simular el final de la conexión de PayPal, registrará los detalles de cada solicitud que reciba y responderá de manera adecuada. Esto puede ser una bendición para depurar exactamente lo que está saliendo "por el cable" y / o probar cosas repetidamente.

Answer 2

La API REST es bastante nueva y no está cargada de funciones como Classic. Todavía recomiendo Classic, ya que no tiene nada de malo ni obsoleto. PayPal quería correr con los niños geniales como Facebook y crearon una API Oauth (sospecho que era más fácil para dispositivos móviles pero también puedes implementar otra API fácilmente).

Classic NVP (Name Value Pairs) es fácil de entender y uno de los mejores documentados con los que he trabajado. Sus llamadas son todas cadenas de consulta que PUBLICA al punto final API.

METHOD=DoDirectPayment&AMT=1.00&EXPDATE=012015

No iría a la ruta SOAP a menos que duerma debajo de una manta con WSDL impreso en ella. SOAP es solo un dolor para entender y trabajar.

Classic admite varias llamadas que REST aún no realiza (MassPay, Buttons API, la mayoría de las llamadas adaptables, etc.). Espero que PayPal se ponga al día con el tiempo, pero, por ahora, Classic es la única opción para algunas funciones.

En cuanto a todas las llamadas por ahí

• DoDirectPayment: procesa directamente una tarjeta de crédito. Requiere una suscripción a Payments Pro para usar, pero es un sistema completo de procesamiento de tarjetas
• Pago exprés - Gratis para usar. Le permite aceptar cuentas de PayPal como forma de pago. Básicamente llamamos a la API, obtenemos un token, redirigimos al usuario, ellos inician sesión, PayPal te redirecciona y luego usas el token para que te paguen.
• Pagos adaptativos : aquí es donde puede hacer algunas cosas interesantes para crear sistemas de pago creativos. Supongamos que tiene un tercero para el que ejecuta tarjetas, pero desea una reducción de sus ventas. Los pagos encadenados hacen eso.

La mayor diferencia en la solución estándar de HTML Payments y la API es que con la API debe cumplir con PCI. En general, eso significa que no registra datos confidenciales (como CVV2), tiene seguridad en su sitio y tiene un certificado SSL, pero podría haber otros requisitos en el camino. Lo bueno es que tienes control total sobre el proceso. Payments Standard no le permite ningún control, pero tampoco tiene PCI.

Answer 3

Bueno, he estado leyendo la mayoría de las API clásicas de PayPal

En mi humilde opinión: puedo decir que Express Checkout es parte de Adaptive Payments (en Adaptive Payments, los clientes tienen la posibilidad de iniciar sesión con PayPal y pagar un artículo para que no necesiten poner su dirección de envío, detalles de la tarjeta de crédito , etc. porque ya están registrados en su cuenta de PayPal) En realidad, tengo algunas notas que contar:

• Mass Payments le permite enviar dinero a varias cuentas y Adaptive Payments hace lo mismo, entonces, ¿cuál es la diferencia entre ellos? (¿La función encadenada tal vez?)
• Acerca de la API de facturación: ¿en qué momento del proceso de pago los clientes pueden verla? (¿antes de la confirmación del pago?), todavía no sé su utilidad.

Finalmente, debo decirle que mi jefe desea desarrollar una solución de pago sin el inicio de sesión con la función de PayPal (en otras palabras, quiere que los clientes completen directamente los detalles de su banco / tarjeta de crédito, no necesitaremos información de envío ya que están vendiendo productos digitales) por lo que creo que la mejor solución para elegir será la API Adaptive Payments (tenemos que considerar el hecho de que no somos desarrolladores estadounidenses)

Qué piensas ?