Документация PayPal (REST, Classic: SOAP & NVP) Что выбрать?

Мне нужно разработать платежное решение с использованием API PayPal. Фактически я начал фазу документации (на http://developers.paypal.com)

Я нашел REST APIs понятным, я до сих пор не знаю, как реализовать их с помощью SpringMVC, поэтому я просто использую cURL для их тестирования. (любая помощь на этом?)

С другой стороны, классические API запутывают. (например, что мы можем сделать с адаптивными учетными записями и какова разница между Express Checkout и Adaptive Payments и т.д.).

Другое дело, что нам нужно выбирать между созданием скрытой формы (html) или использованием API. (Мне нужно объяснение)

Документация очень длинная, и я действительно смущен, я не знаю, что выбрать (очевидно, что API REST лучше для простых платежей, но я действительно хочу узнать больше о SOAP и NVP..)

Я новичок, может кто-то быть волонтером и помочь мне в этом?

Спасибо!

ОТВЕТЫ

Ответ 1

Проведя пару-тройку танцев PayPal-интеграции (хотя и несколько лет назад), позвольте мне подвести итог моим мыслям (и помните, что все могло немного измениться)

Причина использования методов API/интеграции в PayPal объясняется огромным количеством мест, которые они хотят, чтобы заставлять вас оплатить поддержку с помощью:

  • Если у вас есть блог, статический HTML-хостинг, готовый сайт электронной коммерции или некоторые другие "примитивные" веб-технологии, отправка скрытых HTML-форм - это ваш единственный вариант. Я подозреваю, что это оригинальный механизм PayPal, и, хотя они должны поддерживать его навсегда, вы не захотите использовать этот подход сегодня из современной веб-структуры, такой как SpringMVC.

    /li >

  • API NVP - еще одна давняя схема интеграции, которая была подходящей в то время, когда эффективно сшивание параметры в URL-адрес были все, что могли сделать ваши клиенты. Нет большой причины использовать этот API в наши дни, когда доступен REST JSON API. Большинство людей находят JSON гораздо более легким для чтения, чем параметры, закодированные URL.

  • В хронологическом порядке, представленном ниже, я подозреваю, что SOAP API отражает время, когда XML собирался управлять мир. В некоторых (очень строгих и/или традиционных) местах это все равно. Опять же, в эти дни вы, вероятно, не пойдет по этому пути, если у вас есть выбор - использование с Java обычно связано с тесной интеграцией с SOAP Framework, например Apache CXF и горы машинных файлов .java.

  • REST API является самым современным и (IMHO), наиболее удобным для использования с Java-land, и это вариант, который я рекомендую. Похоже на то, что PayPal предпочла бы вам использовать тоже, поэтому я расскажу о том, о чем я расскажу остальную часть этого ответа.

Как разработчик Java, когда вы выбираете REST API, вы получаете дополнительный выбор либо с помощью PayPal SDK, либо с помощью собственной схемы интеграции. Рассмотрите возможность использования SDK, если:

  • Вы можете предвидеть, что ваша интеграция с PayPal становится очень большой и/или с использованием расширенных функций API.

  • У вас нет других точек интеграции HTTP, поэтому у вас еще нет инфраструктуры для вызова методов HTTP из вашего кода (например, Apache HttpClient или RestTemplate, встроенная в Spring 3)

  • У вас нет (или не хотят иметь) доступный парсер JSON

Как вы уже использовали API через cURL, и вы понимаете вызовы и их последовательность, вы, вероятно, не знаете об этом. Если вы не подвергаетесь слишком сильному давлению, я бы рекомендовал спуститься по своему собственному пути с помощью (и обучения) Apache HttpClient вместе с библиотекой JSON, например Jackson - они являются ценными инструментами в вашем арсенале, и вы почти наверняка будете использовать их снова в будущих интеграциях.

Еще один совет разработчика, который применяется к опции REST API - если вы используете "сервер-заглушку", например этот, чтобы имитировать PayPal конец соединения, он будет регистрировать сведения о каждом запросе, который он получает, и реагировать соответствующим образом. Это может быть находкой для отладки именно того, что происходит "по проводам" и/или тестирования вещей несколько раз.

Ответ 2

API REST довольно новый, а не как функция, нагруженная как классика. Я по-прежнему рекомендую Classic, потому что там нет ничего плохого или устаревшего. PayPal хотел работать с классными детьми, такими как Facebook, и поэтому они создали API oauth (я подозреваю, что это было проще для мобильных устройств, но вы также можете легко реализовать другой API.).

Классический NVP (пары значений имени) легко понять и один из лучших документированных, с которыми я работал. Ваши вызовы - это все строки запроса, которые вы отправляете POST в конечную точку API.

METHOD=DoDirectPayment&AMT=1.00&EXPDATE=012015

Я бы не пошел по SOAP-маршруту, если вы не спите под одеялом с WSDL, напечатанным на нем. SOAP - это просто боль, чтобы понять и работать.

Classic поддерживает несколько вызовов, которые REST все еще не выполняет (MassPay, API кнопок, большинство адаптивных вызовов и т.д.). Я ожидаю, что PayPal наверняка наверстает упущенное, но на данный момент Classic является единственным вариантом для некоторых функций.

Как и во всех вызовах там

  • DoDirectPayment - Непосредственно обрабатывать кредитную карту. Требуется подписка на Payments Pro для использования, но это полнофункциональная система обработки карточек.
  • Express Checkout - Бесплатно. Позволяет принимать учетные записи PayPal как форму оплаты. В основном вы вызываете API, получаете токен, перенаправляете пользователя, регистрируетесь, переадресовываете PayPal, а затем используете токен для оплаты.
  • Adaptive Payments - Здесь вы можете сделать некоторые интересные вещи, чтобы создавать творческие платежные системы. Скажем, у вас есть третья сторона, за которой вы запускаете карты, но вы хотите сократить их продажи. Связанные платежи делают это.

Самая большая разница в стандарте HTML Payments Standard и API заключается в том, что с API вы должны быть совместимы с PCI. В основном это означает, что вы не регистрируете конфиденциальные данные (например, CVV2), имеете безопасность на своем сайте, и у вас есть сертификат SSL, но на вас могут быть другие требования. Потенциал роста - это полный контроль над процессом. Стандарт "Платежи" не дает вам контроля, но у вас также нет соответствия PCI.

Ответ 3

Хорошо, что я читал большинство API-интерфейсов PayPal Classic

В моем скромном undestanding: я могу сказать, что Express Checkout является частью Adaptive Payments (в Adaptive Payments клиенты имеют возможность войти в систему с PayPal и оплатить товар, поэтому им не нужно указывать свой адрес доставки, данные кредитной карты и т.д., поскольку они уже записаны в их учетной записи PayPal) На самом деле, у меня есть несколько замечаний:

  • Массовые платежи позволяют вам отправлять деньги на несколько аккаунтов, а Adaptive Payments делает то же самое, так в чем же разница между ними? (возможно, связанная функция?)
  • О API-интерфейсе Invocing: в какой момент процесса оплаты клиенты могут его увидеть? (до подтверждения оплаты?), я до сих пор не знаю его полезности.

Наконец, я должен сказать вам, что мой босс хочет разработать платежное решение без входа в систему с функцией PayPal (другими словами, он хочет, чтобы клиенты напрямую заполняли свои банковские/кредитные карты, нам не нужна доставка информация, поскольку мы продаем цифровые товары), поэтому я считаю, что лучшим решением для выбора будет Adaptive Payments API (мы должны учитывать тот факт, что мы являемся не-американскими разработчиками)

Как вы думаете?