Лучший подход к реализации интернационализированного платежного шлюза

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

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

Я обеспокоен тем, что мне придется иметь шлюз для Великобритании и шлюз для США, работающие вместе друг с другом в одном приложении. Конечно, это не так, и я что-то совсем упустил?

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


ruby-on-rails payment-gateway activemerchant
person joshnesbitt    schedule 23.10.2009    source источник

Ответы (3)


arrow_upward
0
arrow_downward

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

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

Стив

person ChaseP    schedule 27.10.2009

arrow_upward
2
arrow_downward

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

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

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

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

person PaulG    schedule 23.10.2009
comment
Настройка каждым пользователем учетной записи в Великобритании на самом деле не вариант, поскольку рассматриваемое приложение представляет собой программное обеспечение как услугу, поэтому это было бы огромным препятствием для регистрации в приложении. - person joshnesbitt; 25.10.2009

arrow_upward
-3
arrow_downward

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

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

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

person Elizabeth Buckwalter    schedule 25.10.2009
comment
Мадженто — это PHP. И joshnesbitt говорит, что приложение — это рельсы. - person Damien MATHIEU; 27.10.2009
comment
Чувак, рельсовых решений нет. Неважно, на каком языке он написан. Пользователю все равно, и с помощью простой конфигурации Apache было бы легко сделать и то, и другое. И он сказал, что платежный шлюз в приложение rails не написано с rails. Не спешите минусовать. Кроме того, если вы посмотрите на мой профиль, то заметите, что мне наплевать на PHP, так что тот факт, что я даже предлагаю это... - person Elizabeth Buckwalter; 27.10.2009
comment
Платежные шлюзы имеют API, к которым можно без проблем получить доступ через Rails. Кроме того, попытка объединить приложение Rails с Magento будет очень сложной. - person Jon Winstanley; 29.06.2011
comment
Должен согласиться, что это совершенно обратный способ решения проблемы. - person Abe Petrillo; 30.01.2012