Какой лучше сделать интерфейс для подключения платёжных систем? 2 варианта есть.

ты так говоришь, как будто у тебя на руках есть такая железка, есть договора с платежными системами и у тебя кто-то что-то хочет купить :)

man фискальный накопитель

кстати в тему, тут как раз изменения назревают

ну и по вопросу и купюроприемник и терминал, ну и дуй в банк заключать договор, там тебе скажут какого ужа с каким ежом ты будешь разводить :))))

в школе русскому для начала поучиться лучше языку

ты так говоришь, как будто у тебя на руках есть такая железка, есть договора с платежными системами и у тебя кто-то что-то хочет купить :)

Я так говорю, потому что «у меня на руках нет такой железки». И прибивать программу гвоздями к какому либо типу платёжных устройств, я не хочу. Нужно сделать так что бы разработку плагина конкретной платёжной системы, клиент мог заказать у сторонних программистов. Я хочу сделать простой API для плагинов платёжных систем, поэтому и спрашиваю совета. Как его лучше реализовать?

ну и по вопросу и купюроприемник и терминал, ну и дуй в банк заключать договор, там тебе скажут какого ужа с каким ежом ты будешь разводить :))))

Какой лучше сделать интерфейс для подключения платёжных систем? 2 варианта есть. (комментарий)

Нужно сделать так что бы разработку плагина конкретной платёжной системы, клиент мог заказать у сторонних программистов.

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

Я хочу сделать простой API для плагинов платёжных систем, поэтому и спрашиваю совета. Как его лучше реализовать?

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

к слову, этих агрегаторов и так пруд пруди, просто ты видимо не особо в теме и не знаешь этого :)

Ну обычно это делают на СУБД Оракл или ДБ2. В частных случаях возможны варианты, но в твоем случае я бы не стал заниматся упреждающей оптимизацией.

Как лучше будет сделать? На файлах? Через TCP? Или стоит как то по другому сделать?

оно конечно не про ПС, но так, в среднем, если ты очень хочешь понравится на рынке всем и сразу, интеграция делается систем этак под 45-50. самое крутое я видел под 80, но там была какая-то адовая экзотика и все равно пришлось писать еще одну, свою ))

поэтому, если ты задался таким вопросом, у тебя нет знакомств, у тебя есть одна харя и ты даже не ИП --- не взлетит. увы.

Никого не слушай, делай на файлах, я знаю, тебе хочется.

На гамбасе.

Этот вопрос даже не поднимается.

Никого не слушай, делай на файлах, я знаю, тебе хочется.

На файлах проще конечно, но мне кажется что это не достаточно надёжно.

ммм, прикольно и в чем тогда автоматизация? релюшкой щелкать удаленно? прикольно, я то грешным делом подумал запиливают под ключ, а тут сторонние погромисты)))))))))

Думаю, для начала стоит ознакомиться с существующими решениями (перед тем, как воплощать комикс про 16-й стандарт)/требованиями. Того и гляди - окажется, что 1 вариант отпадает.

[fat-troll] Раз именно плагин, то очевидно :

Как сторонним программистам будет предпочтительнее писать плагины для подключения различных платёжных систем

Ну очевидно же - обмениваться данными со специальной софтиной в заданном формате через консольный ввод-вывод. А та софтина пусть работает как угодно её быдлокодеру. [/fat-troll]

А, такое ли уж fat-troll...

Как лучше будет сделать?

Если купюры принимать, это делают на стороне платежного клиента. На сервер уходит готовая транзакция.

Если ридер карт, то транзакция идет через софт ридера. Опять же результат на платежном клиенте.

Посмотри сначала в новый закон о ККМ и онлайн посылании чеков в налоговую. Там всё серьёзно.

господи это 12 из 10, пробежался глазами по треду, гносподи это блеск, это платина, это золото, это палладий.это плагины пишущие в файлы чеков, файлы платежей. это платежные системы, транзакционность, это все, регрессия дичайшая в башорк, коллеги, простите мою опечатку, вызывайте пожарных.

результат на платежном клиенте, здесь полон тред организовывавших прием платежей. даю мизинец на отсечение что 99,9% людей здесь присутствующих даже откажутся на сайт робокассу ставить. потому-что ссыкотно, ДЕНЬКИ ВЕТЬ.

афтар забыл дописать что это плагины для платежных систем его игорей на гамбасе, прозреваю?

афтар забыл дописать что это плагины для платежных систем его игорей на гамбасе, прозреваю?

Что ты несёшь поехавший?

Скоро благодаря Светочу у ЛОРа появится своя космическая программа. На Марс полетим. Управлять нашим полётом, конечно, будет софт на gambas.

Ну подумал человек, что ты игорю (тому, который тонет) приделываешь платёжку (лол, при чём тут терминалы-то тогда), а не автомойке (она же, раз уж речь о железках)?

Какой лучше сделать интерфейс для подключения платёжных систем (купюроприёмник или терминал для карт) ? Есть 2 варианта.

Третий вариант: возьми готовый протокол для готовой железки http://www.kiosksoft.ru/devices/cashcode-sm

Ты же не будешь ещё и купюроприёмник свой делать?

да не ну че ты дядь, не мешай детям развиваться, пусть на фаийлах делают. =хочу протокол чеков блеать.

Ты же не будешь ещё и купюроприёмник свой делать?

кстати, у _всех_ имеющихся на сегодня купюроприемников есть один фатальный недостаток... :(

Рыбалка?

у _всех_ имеющихся на сегодня купюроприемников есть один фатальный недостаток

Надо просто сделать ещё один.

Реальные пацаны пишут на Gambas!

купюроприёмник

ему может быть и удастся

YOBA-купюроприемник!

Я так понял есть уже контракты с крупными банками и платёжными системами.

Осталось дело за самым главным - решить как проводить транзакции, через куроприёмник или через https по tcp-ip с реплицируемой БД?

Я так понял есть уже контракты с крупными банками и платёжными системами.

Нет. Я задал вопрос о том какой интерфейс для плагинов поддержки платёжных систем, будет удобнее для сторонних программистов.

В большинстве случаев, что я встречал, используется передача xml файла, и xml же в ответ на подтверждение транзакции.

В итоге, конечно, это всё парсится на сервере и кладётся в БД.

Очень редко используют вариант на протоколе SOAP, по сути те же xml файлы, только стандартизировано и поддерживается почти всеми средами разработки и языками и парсится автоматически.

Пару раз видел использование JSON вместо XML.

Припоминаю упоротых, которые используют HTML.

У многих банков, например, описание их API лежит в открытом доступе для программистов.

Пошерстите ознакомтесь с вариантами.

Вобщем, что вам больше по душе то и юзайте.