2009-10-23 5 views
2

Я ищу интеграцию платежного шлюза в приложение Ruby on Rails. Хотя я уже реализовал один, прежде чем я попытаюсь понять, как я могу реализовать тот, который будет обслуживать разные страны.Лучший подход к реализации интернационализированного платежного шлюза

Например, если бы это было только приложение в Великобритании, я мог бы использовать британский поставщик (например, CardStream), если бы это было только приложение в США, я мог бы использовать поставщика в США (например, BrainTree), но я не могу показаться найти поставщика, который обслуживает несколько стран.

Я обеспокоен тем, что мне придется иметь как британский шлюз, так и американский шлюз, работающий рядом друг с другом в одном приложении. Неужели это не так, и я ничего не теряю?

Заранее спасибо.

ответ

0

На самом деле существует довольно много PSP и/или приобретателей, которые поддерживают как США, так и Европу. Большинство из них будут иметь различные варианты API, такие как XML или SOAP. Проверьте Chase Paymentech Europe dot com.

С наилучшими пожеланиями

Стив

+0

Спасибо за ваш отзыв Steve – joshnesbitt

2

Элизабет прибила его. Поставщик платежных услуг должен пройти аккредитацию с каждым банком-эквайером, с которым они хотят выполнить авторизацию/расчет. Например, в Великобритании основными являются Barclays, Streamline, FirstData, HSBC, Amex, Diners. Для каждой аккредитации есть затраты и значительные инвестиции времени.

Я никогда не разрабатывал для покупателей в США, но я думаю, что существует большое количество. Прополощите и повторите для покупателей в других странах, и вы скоро увидите это.

Требования PA-DSS и PCI-DSS являются «глобальными», поэтому после их сертификации там не так уж плохо.

Вы можете просто пойти с британским провайдером и настроить клиентов на получение банковского счета в Великобритании? Все провайдеры будут выполнять авторизацию и расчеты по нескольким валютам, поэтому это довольно стандартная настройка. Мы разработали для американских клиентов эту систему.

+0

Имея каждую установку пользователя Великобритания основе учетной записи на самом деле не вариант здесь в качестве приложения в вопросе Программное обеспечение как услуга, так что это было бы огромным препятствием для подписания к приложению. – joshnesbitt

-3

Мой первый ответ был неправильным, поэтому я удаляю его. (Я ударил кнопку удаления, видимо, вы голосуете, чтобы удалить).

Magento - это решение для электронной торговли, которое поддерживает множественную валюту, интернационализацию и различные ставки налога. Мы использовали его раньше для Versatile Hangars. Основой для этого сайта является США, но Magento поддерживает несколько сайтов на одной установке. Я не играл с общим списком пользователей между сайтами, но я уверен, что это может быть испорчено.

Извините за быстрый ответ раньше. Надеюсь, это сработает для вас.

+0

Magento - это PHP. И Йошнесбитт говорит, что приложение - это рельсы. –

+0

Чувак, нет рельсовых решений. Не имеет значения, на каком языке он написан. Пользователю все равно, и с помощью простой простой конфигурации apache было бы легко сделать то и другое. И он сказал, что платежный шлюз * в * рельс приложение не написано * с * рельсами. Не будьте настолько быстрыми, чтобы спускаться вниз. Кроме того, если вы посмотрите на мой профиль, вы заметите, что меня не интересует PHP, поэтому тот факт, что я даже предлагаю его ... –

+0

Платежные шлюзы имеют API, к которым можно получить доступ через Rails, без проблем. Плюс, пытаясь объединить приложение Rails с Magento, было бы очень сложно. –

 Смежные вопросы

  • Нет связанных вопросов^_^