Новый API платежей вконтакте
 

Для тех, кто еще не в теме http://vk.com/developers.php?oid=-1&p=Payments_API

Сам пока еще не перешел на новый API, но уже вижу одну сложность - адрес обратного вызова.
В примере указан адрес скрипта PHP. С сокет серверами явно будте сложнее.
Похоже прийдется писать сцециальный класс для обработки именно http запросов из контакта.. Задача походит на костыль )

Кстати, там банально нельзя указать адрес вида http://127.0.0.1:8080, работает только с 80 портом...Хрень какая-то, только перенес работу с БД на Java, думал что забыл этот PHP как страшный сон...У кого-то что-то получилось на сокетах?

А что, на яве уже нельзя веб сервер написать?

Порт указать действительно нельзя. Мне в суппорте ответили, что из-за настроек безопасности их серваки могут делать запросы только к 80 и 443 портам.
Но это не проблема. Я перевесил у себя апач отдающий ресурсы на 9009, а для сокет сервера написал класс, который слушает запросы на 80 порту. Все работает. Сервак тоже на джаве кстати, особой разницы не вижу, джава, пхп или что-то еще

А что nginx не используете? Нагрузка в разы упадет. Да и порты можно будет убрать, кстати

В моем случае - это избыточно.

Можно, хотя с netty я пока не особо знаком, но все равно нужно переписывать свой дохрена-поточный сервер на нормальную реализацию :) . Просто тогда надо будет на нескольких серверах сносить apache, ставить ngnix и настраивать прокси, в чем у меня опыта, увы, нету...а свободного времени сейчас не очень. Само-собой, в итоге так и сделаю, но пока буду использовать заглушку на PHP.

Зачем? По-моему это костыль. Сервер на джаве займет строчек 100 - 200, никакие заглушки на php не нужны.
Нетти - это тоже перебор для таких целей. Я посмотрел и вариант с нетти, и вариант с nginx, в итоге отсновился на собственном микро сервере, который заточен только под зачаду обмена данными с контактом.

Собственно, он и отдельным сервером то не является. Это просто небольшое расширение для существующего.

2caseyryan
Да мне основу срвера надо будет переписать, Netty кажется для этого подходящим решением, а раз её использовать - то почему бы и http-сервер на ней же не сделать. Я свой сервер начал писать не зная толком ни Java, ни принципов организации клиент-серверного взаимодействия, потом уже правил и наращивал функционал. Например, сначала обработка данных происходила так: десериализация AMF-объекта, определение в switch-case типа сообщения, вызов обработчика - ну это скорее от желания поскорее сделать нечто работающее в самом начале. Теперь сделал нечто вроде стратегии - массив анонимных реализаций интерфейса-обработчика, где индексы - типы сообщений(целочисельные константы), такая же система и на стороне клиента, только там вызываются события. В итоге оно работает согласно парадигме "один клиент - один поток", в нем есть несколько некрасивых костылей...ну что поделаешь, хреновый я программист, чего в гугле нашел, то и сделал :)

Пхп может и без апача уже, по-моему в 5.4 это вышло из бета-теста в релиз.

А смысл? Хотя может я просто не особо часто работаю с php, чтобы это понять

В джаве даже циклы в отдельных потоках выполняются

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

То есть, если мне нужно 10К пользователей онлайн держать - нужно расчитывать на сервер с 8 гигами оперативной памяти? У меня при меньшем количестве банально не инциализируется пул потоков - JVM выдает сообщение, что мало памяти. Кроме того, время от времени бывает что сервер падает с ошибкой вроде "The crash happened outside the Java Virtual Machine in native code". Пошарился на формуах - говорят, что либо использую слишком много памяти, либо кончились свободные порты - последнее навряд ли, но так уж мне ответили :) .
А что касается платежей - написал сейчас класс для чтения http запросов на сокетах, и хочу протестировать одну фичу. При помощи iptables можно настроить редирект с одного порта на другой. Может кто-то знает, как при этом указать диапазон IP-адресов, для которых будет выполняться это правило? Чтобы все, кроме ВК, работало нормально с веб-интерфйесом, а запросы от ВК перенаправлялись уже Java-серверу.

P.S. Вроде нашел решение:
-A PREROUTING -s 188.0.64.152/32 -p tcp -m tcp --dport 801 -j DNAT --to-destination :80
-A POSTROUTING -s 188.0.64.152/32 -p tcp -m tcp --dport 801 -j SNAT --to-source :80

В примере данные для 188.0.64.152 с 801 порта перенаправляются на 80 - сделал так для теста, поставил свой IP, при обращении к 801 порту увидел веб-интерфейс. Теперь осталось только узнать, с одного ли IP приходят запросы информации о товаре с ВК. А картинку для товара, как я понимаю, будет запрашивать уже клиент, со своим IP.

Добавлено через 7 часов 32 минуты
Вопрос к тем, кто уже сделал/разобрался. Я верно понял алгоритм(рассмотрим простой случай - перевод голосов):
1. Приходит order_status_change
2. Смотрим статус, если chargeable идем дальше
3. Проверяем, нет ли этого order_id в нашей БД, если нет - добавляем и отправляем подтверждение, если есть - просто отправляем пакет с подтверждением(в документации написано, что оно может приходить несколько раз)?

Интересно, где в такой схеме лучше всего производить покупку товара, то есть модификацию записи о наличии товара/размере счета пользователя в БД. По прибытии пакета chargeable явно не вариант - пользователь может нажать на кнопку "Оплатить", и быстро закрыть окно оплаты - в итоге клиенту придет только onOrderCancel, и все. Скорее всего, нужно после отработки на стороне клиента onOrderSuccess отправлять на сервер подтверждение с order_id и app_order_id(возможно - еще и UID пользователя), опять смотреть в БД - есть ли там такой платеж, и только после этого переводить игровую валюту/выдавать товар. Верно ли я понял, или нужно все делать не так?

Вопрос по сабжу.

У кого-нибудь наблюдаются тормоза при работе с новым платежным API?

Да. Система жутко тормозная. Иногда секунд по 40 висит окно.

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

Не знаю. Мое в каталогах присутствует. И до добавления все так же тормозило. Причем в опере и огнелисе нормально открывает почти всегда, в хроме тормозит

Угу. У клиента отключили электричество. Поэтому деньги вам контакт со счета клиента переведет, а товар клиенту вы не поставите. Потрясающе. Или контакт платеж не проведет (если вы ему на chargeable чем-нибудь приличным не ответите), но тогда и клиент уведомление об успешном платеже вообще не сможет получить. Или сервера контакта протормозят и захолдированные на счету средства придут вам через несколько часов, когда игрок все успел закрыть. Так что тут вариант один - выполнять покупку на уведомление о chargeable. А клиенту полагаться на уведомления от сервера о состоявшемся платеже.

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

В общем, наша проблема (зависание системы на этапе "Получение информации о товаре"), как оказалось, решается включением кэширования на стороне сервера ВК.

http://vk.com/developers.php?oid=-1&...B0%D1%80%D0%B5

Надо задать необязательный параметр в ответе сервера - expiration.
После этого сервер ВК начинает показывать форму моментально или около того.

Отлично ) Добавлю у себя тоже

Появилась проблема с платежами. Причем саму систему новую подключили давно, но внезапно перестала работать. Приходит такая ошибка:
{"error":{"error_code":1, "error_msg":"error @ 165 {\"error_code\":3,\"error_msg\":\"Unknown method passed\",\"request_params\":[{\"key\":\"action\",\"value\":\"charge\"},{\"key\":\"api_id\",\"value\":\"2759105\"},{\"key\":\"format\",\"value\":\"JSON\"},{\"key\":\"method\",\"val ue\":\"orders.changeState\"},{\"key\":\"order_id\",\"value\":\"57214\"},{\"key\":\"random\",\"value\":\"9642738\"},{\"key\":\"test_mode\",\"value\":\" 0\"},{\"key\":\"timestamp\",\"value\":\"1354455621\"},{\"key\":\"v\",\"value\":\"2.0\"},{\"key\":\"sig\",\"value\":\"7a9***********42b\"}]}", "critical":"true"}}

Никто не сталкивался?

Борис Бритва, только что проверил. У меня все нормально работает. Никакой ошибки не приходит.
Может у вас проблема на сервере?

Да, вроде нет. Сервер не трогали давно. Платежи были, потом просто переатали проходить и все.
В теме во Вконтакте тоже заметил есть такая проблема у людей:
http://vk.com/topic-1_27042222?offset=380

Сервер на чем написан? Может какой-то эксепшен вылетел и модуль лёг?

Точно так же без объявления войны внезапно платежи заработали снова. Видимо вконтактовская внутренняя проблема была. Так что елси кто столкнеться -- пишите в техподдержку, они не ответили но что-то починили.

На сервере php. Сервер перезагружали, проверяли все запросы и подписи. все по протоколу было.

пару дней назад тоже сталкивался с глюком их api. В запросе информации о пользователе приходили только поля last_name, first_name и uid
Проблема так же внезапно исчезла, как и появилась. Наверное какие-то работы ведут с api