То есть PayPal, MoneyMail и OSMP прекрасно умеют работать по первой схеме, если я тебя правильно понял?
А если так, то зачем же вообще городить работу по «второй схеме»? Для чего?
Если у магазина уже подключена ПС «первого рода» (а это скорее всего вебмани, яндекс или какой-нить киберплат), то зачем ему городить огород, когда можно сказать новой ПС «— Включайте первую схему, будем работать по ней»???
Под «невозможно» имелось в виду без переделок. Новые статусы, новые фунции — это всё переделки.
Так это смотря какая гибкость нужна сайту для работы с ПС
Ты так и не ответил, какие системы могут работать только по «второй схеме» и не умеют по первой.
И вообще, в каком случае работа по второй схеме вообще нужна магазину?
Потому как, на мой взгляд, «первая схема» абсолютно прозрачна и логична: я (магазин) делаю счёт на оплату->человек идёт в ПС и платит->ПС мне говорит удалось оплатить или нет, и возвращает человека на соответствующий урл моего мазагина->profit!
«правильно спроектировав систему приема платежей, подключать каждую новую систему не составит труда»
Какие из платёжных систем на рынке сейчас работают по первой схеме («Счёт на сайте->Редирект на сайт ПС->...->платёж->Редирект обратно->ждём от ПС весточки про платёж»), а какие — по предложенной второй?
Меня терзают смутные сомнения, что первых больше и они шире распространены.
Заточив на сайте систему работы с платежами под работу с ПС «второго рода» подключить ПС «первого рода» невозможно.
При этом работа с ПС «второго рода» требует от сайта магазина наличия механизмов, которые позволят самому сайту инициировать подключение к внешнему ресурсу.
И по сути получается, что такая ПС перекладывает затраты на разработку на плечи своих клиентов, как мне кажется…
«Насколько я знаю там был жесткий копипаст»
То есть вы определённо знаете о, так сказать, никакой квалификации персонажа, и всё равно считаете это примером? :)
Крайне не показательный пример, не находите?
Если человеку для того, чтобы склеить в фотошопе сотню картинок понадобилось городить 200КБ скрипта, то это лишь пример его некомпетентности в данном вопросе, и не более того. К эффективности/удобству (и так далее) photoshop script это не имеет абсолютно никакого отношения.
Тематика блога и название статьи ни на какие мысли не наводит?
Потому как это уже клиника на уровне «…
— Мужики, мне бы тут картошку с дачи привезти…
— Бери Ferrari 599 — она всех на круге порвёт!!!
— Чувак, ему картошку с дачи привезти!
— Ладно, живите замкнувшись на своей картошке, не буду вам больше мешать.
…»
1. По какой вашей ссылке?
2. Вы и aleks_raiden — это один персонаж? Сам шучу, сам смеюсь?
3. «Конечно, сериализация отнимает ресурсы и она обычно всегда дольше обычной нативной, хотя на простых сообщениях (где несколько полей) это почти никак не заметно»
Die Schnittstelle — женский род.
А если так, то зачем же вообще городить работу по «второй схеме»? Для чего?
Если у магазина уже подключена ПС «первого рода» (а это скорее всего вебмани, яндекс или какой-нить киберплат), то зачем ему городить огород, когда можно сказать новой ПС «— Включайте первую схему, будем работать по ней»???
Под «невозможно» имелось в виду без переделок. Новые статусы, новые фунции — это всё переделки.
Ты так и не ответил, какие системы могут работать только по «второй схеме» и не умеют по первой.
И вообще, в каком случае работа по второй схеме вообще нужна магазину?
Потому как, на мой взгляд, «первая схема» абсолютно прозрачна и логична: я (магазин) делаю счёт на оплату->человек идёт в ПС и платит->ПС мне говорит удалось оплатить или нет, и возвращает человека на соответствующий урл моего мазагина->profit!
Так в какой же ситуации нужна «вторая схема»?
«правильно спроектировав систему приема платежей, подключать каждую новую систему не составит труда»
Какие из платёжных систем на рынке сейчас работают по первой схеме («Счёт на сайте->Редирект на сайт ПС->...->платёж->Редирект обратно->ждём от ПС весточки про платёж»), а какие — по предложенной второй?
Меня терзают смутные сомнения, что первых больше и они шире распространены.
Заточив на сайте систему работы с платежами под работу с ПС «второго рода» подключить ПС «первого рода» невозможно.
При этом работа с ПС «второго рода» требует от сайта магазина наличия механизмов, которые позволят самому сайту инициировать подключение к внешнему ресурсу.
И по сути получается, что такая ПС перекладывает затраты на разработку на плечи своих клиентов, как мне кажется…
То есть вы определённо знаете о, так сказать, никакой квалификации персонажа, и всё равно считаете это примером? :)
Если человеку для того, чтобы склеить в фотошопе сотню картинок понадобилось городить 200КБ скрипта, то это лишь пример его некомпетентности в данном вопросе, и не более того. К эффективности/удобству (и так далее) photoshop script это не имеет абсолютно никакого отношения.
Потому как это уже клиника на уровне
«…
— Мужики, мне бы тут картошку с дачи привезти…
— Бери Ferrari 599 — она всех на круге порвёт!!!
— Чувак, ему картошку с дачи привезти!
— Ладно, живите замкнувшись на своей картошке, не буду вам больше мешать.
…»
2. Вы и aleks_raiden — это один персонаж? Сам шучу, сам смеюсь?
3. «Конечно, сериализация отнимает ресурсы и она обычно всегда дольше обычной нативной, хотя на простых сообщениях (где несколько полей) это почти никак не заметно»