EMV чип-ридер / платежный процессор с возможностями REST API - PullRequest
Новая
       8

EMV чип-ридер / платежный процессор с возможностями REST API

0 голосов
/ 14 февраля 2019

Я хочу внедрить решение для считывания / обработки платежей EMV-чипов с возможностями REST API и режимами проверки карт (CVM): чип-подпись для кредитных карт и чип-и-пин-код для дебетовых карт.

Вот процесс, который мне нужен:

  1. POS через Интернет отправляет транзакцию на сервер.

  2. Информация о транзакции сохраняется (заказколичество, номера продуктов, итого и т. д.).Сервер отправляет запрос API в EMV, чтобы начать процесс оплаты кредитной / дебетовой картой.Подключение к локальной сети HTTP.

  3. EMV получает запрос API от сервера через HTTP и начинает процесс оплаты.Подключается к платежному шлюзу для обработки платежа.ПРИМЕЧАНИЕ. EMV должен иметь возможности API REST.

  4. Платежный шлюз обрабатывает платеж и отправляет ответ обратно в EMV, который отправляет ответ обратно на сервер для обновления записи транзакции.

  5. Сервер отправляет ответ хосту для завершения транзакции в зависимости от полученного ответа.

Кто-нибудь реализовал этот тип решениядо?Если да, то какое решение (Квадрат, Клевер и т. Д.) Было использовано?

Ответы [ 2 ]

0 голосов
/ 15 февраля 2019

Ваш вопрос на самом деле не относится к stackoverflow - это не программирование, вы не показали ни кода, ни описали, что вы делаете, и что вы сделали до сих пор.

То, что вы описываете, является довольно общим описаниемпротокола Retail ECR.Существует множество вариантов и реализаций, некоторые могут выставлять REST.Некоторые могут работать с центральным сервером, выставляя REST API для POS, другие будут иметь порт прослушивания на стороне терминала EFT (обычно должны быть некоторые ограничения брандмауэра на количество подключений и источник подключения и т. Д.).Практически любой эквайер или PSP будет иметь некоторую реализацию (но не обязательно с REST через HTTP), поэтому вы можете начать с местных поставщиков услуг, поскольку они, вероятно, лучше всего соответствуют вашим потребностям в том, что касается методов приемки, поддерживаемых схем карт и т. Д..

0 голосов
/ 15 февраля 2019

Вы могли бы добавить простую иллюстрацию, чтобы сделать взаимодействие более понятным.EMV является спецификацией или стандартом FYI.

На шаге 2. Вы имели в виду, что у вас есть сертифицированный EMV терминал, который предоставляет API, который сервер может вызвать для инициирования транзакции с картой?В этом случае HTTP-соединение находится между сервером и терминалом, а соединение между чипом и терминалом является прямым.Правильный ?Это сделать в состоянии.

Шаг 3. Теперь, когда терминал уже связался с картой в APDU и имеет под рукой криптограмму (ARQC, требующую отправки запроса эмитенту для проверки - Onilne), необходимо связаться сприобретатель.Это сообщение зависит от вашей реализации.Вы можете сделать это с помощью SOAP, REST или любого другого.

Шаг 4. Если существует ARPC, его следует переслать на карту, которую карта проверит и убедится, что ответ получен от правильного эмитента.В противном случае он может отправить покупателю аннулирование (если ответ был утвержден).Если ARPC подтвержден, позвоните хосту для обновления платежа.

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

Вы еще не сообщили о своей проблеме.Вы пытаетесь выяснить осуществимость предложенной вами архитектуры?

...