Чтобы дойти до этой настройки мне понадобилась помощь старших товарищей. Потому как запрятана она в такой жопе, куда нормальный человек и не полезет ее искать.
Я тут какое-то время назад оплачивал покупку на сумму в 165$.
С меня удержал комиссию Пейпал, вместе с ней с меня списали 171.74$. Плюс, когда Пейпал общался с банком, он запросил не доллары (напоминаю, карта долларовая), а рубли по своему курсу. И банк с меня в итоге взял 5330.18 рубля.
А, вот ты о чем.
Ну так оплата товаров со счета в ДМР тоже с нулевой комиссией.
И даже пополнение картой в момент маркетинговых мероприятий бывает с нулевой комиссией. Но у пэйпала на самом деле не все так гладко за счет курса.
Вот сейчас я специально проверил:
совершаю перевод в 100 долларов, с моей долларовой карты (!) предлагают взять 3032 рубля с копейками. Мало того, что вообще не понятно на кой мне эта конвертация, так и относительно курсов моего банка и ЦБ это получается 1-2.3% потерь только на этом.
Нет, я имею ввиду, что пейпал может брать комиссию с отправителя.
И комиссия эта весьма и весьма солидная по меркам российских ПС.
А с учетом конвертации с карты по дикому курсу вообще достигает 10%.
Если вам нужны веберы, то можно вообще не обращать внимание на то, что там написано про оракл
Если мне нужен разработчик с хорошими знаниями баз данных, как же не обращать?
если уж вам понадобится серьезный ораклоид — то наверное, вы его не станете собеседовать лично?
DBA — не стану, не смогу, да. Разработчика — вполне.
Надеюсь, у вас не ДБА запросы пишет? ;-)
Из например, Java Server-Sider-ов… не все сходу ответят. И не все скажут, например, про то, из каких частей состоит SGA
Ну да, а плюсовик вряд ли расскажет что-то про виртуальную машину Java.
И вряд ли его будут спрашивать какие-то тонкости Java на собеседовании, правда?
Зачем спрашивать вещи, которые прописаны в документации?
Представил себе автора, (руководителя отдела веб-разработки?), рассуждающего на собеседовании о тонкостях настройки Oracle
Указанный вопрос не относится к тонкостям настройки. Это базовые знания, которые можно подчеркнуть, прочитав единожды Oracle Database Concepts.
Вы — т.н. «универсальный специалист»?
Упаси Бог. У меня есть немного знаний о разных областях веб-разработки, но специалистом ни в одной из них я себя не могу называть. Разве что, в базах данных разбираюсь немного лучше, чем, скажем, в программировании на Perl. Но даже базовых знаний хватает, чтобы вывести на чистую воду большинство тех, кто приходит на собеседования.
А если так, то зачем же вообще городить работу по «второй схеме»? Для чего?
Во-первых, для большей гибкости.
Архитектурно первый способ от второго отличается только отсутствием диспетчера.
И там, и там придется реализовывать остальные 5 компонентов.
Первая — частный случай второй. Но не наоборот.
Соответственно, реализовав описанную схему, мы сразу же фактически реализуем первую.
Но реализовав первую, вторую придется реализовывать отдельно.
Хорошо, если при этом пустят на единые рельсы, а не добавят костыль сбоку, как это часто случается.
Во-вторых, не все функции платежных систем доступны только по первой схеме.
Например, выставление счета (в терминологии платежной системы) пользователю возможно только, если инициатор — магазин. Это и для Пэйпала, и для ОСМП, и для Манимэйла и для других платежных систем характерно.
По сути, первая схема может применяться, если магазину не нужны расширенные функции платежной системы, а вполне достаточно базовых.
Если у магазина уже подключена
Во вступлении к статье я указал, что платежных систем по условиям задачи не подключено вообще.
Под «невозможно» имелось в виду без переделок. Новые статусы, новые фунции — это всё переделки.
Статус по умолчанию при создании заявки — это 6 байт в модуле работы со счетами:
$status ||= <код_по_умолчанию>
Новые функции нужны только для модуля работы с конкретной платежной системой, а его и так в каждом случае реализовывать. В целом же они ровно те же — сформировать параметры для передачи в платежную систему / разобрать ответ платежной системы.
Доделки минимальны, они не влияют на архитектуру в целом.
Резюмируя:
1. отличия первой схемы от второй — минимальны.
2. вторая — общий случай первой.
3. Нужна простота — первая. Нужна гибкость — вторая.
Моментально — это не выходить из дома при покупке.
И в случае смс, и в случае карт, и в случае денег, конечно, есть случаи, когда выходить придется:
sms — пополнить счет, если баланс нулевой
карта — пополнить счет, если баланс нулевой, или получить новую карту, если старая проэкспайрилась
деньги — пополнить счет, если баланс нулевой.
Но если со счетом всё хорошо, выходить никуда не потребуется, в отличие от ОСМП или Сбербанка, где выходить придется всегда.
Какие из платёжных систем на рынке сейчас работают по первой схеме
Работают только по второй или умеют работать и так, и так?
Если последнее, то это и PayPal, и MoneyMail, и OSMP, например.
Заточив на сайте систему работы с платежами под работу с ПС «второго рода» подключить ПС «первого рода» невозможно.
Это не так. Чтобы началась работа с ПС «первого рода» достаточно:
1. Добавить новый статус а-ля «Пользователь ушел в ПС, но проверять статус не надо», который не будет обрабатываться диспетчером.
2. Добавить в БПС функцию разбора HTTP-запроса от ПС «check» и «pay» фаз с выдачей номера заявки в нашей системе и формированием корректного ответа этой ПС.
3. Добавить в веб-интерфейс функцию обращения к ОБ для получения номера из 2.
В этом случае на check определяем номер заявки, получаем статус заявки, если ее можно оплатить, возвращаем ПС ответ «Бери деньги с пользователя», сгенерированный в БПС.
На pay — определяем номер заявки и меняем статус, если это возможно.
Это гораздо более простой случай, поэтому я его не рассматривал.
Но он прекрасно ложится на описанную схему.
И по сути получается, что такая ПС перекладывает затраты на разработку на плечи своих клиентов, как мне кажется…
Так это смотря какая гибкость нужна сайту для работы с ПС.
Если она не нужна — имеем работу «первого рода» без диспетчера и с 2-3 статусами.
Если нужна — второй род, диспетчер, 10 статусов.
Архитектура одна и та же
По сути, диспетчер действительно просто объединяет в себе все части кроме веб-интерфейса.
Плюс делает какие-то доп.вещи, например, пишет логи ответов от платежных систем в едином формате.
В качестве аналогии приведу пример: есть наковальня, есть молот, есть изделие. Диспетчер — это кузнец. Или кузнецы, в зависимости от нагрузки.
С меня удержал комиссию Пейпал, вместе с ней с меня списали 171.74$. Плюс, когда Пейпал общался с банком, он запросил не доллары (напоминаю, карта долларовая), а рубли по своему курсу. И банк с меня в итоге взял 5330.18 рубля.
Курс ЦБ на тот день был 30.16.
5330.18 / 165 * 30.18 * 100% = 107%
Да, не 10%. Но и далеко не 0.
Ну так оплата товаров со счета в ДМР тоже с нулевой комиссией.
И даже пополнение картой в момент маркетинговых мероприятий бывает с нулевой комиссией. Но у пэйпала на самом деле не все так гладко за счет курса.
Вот сейчас я специально проверил:
совершаю перевод в 100 долларов, с моей долларовой карты (!) предлагают взять 3032 рубля с копейками. Мало того, что вообще не понятно на кой мне эта конвертация, так и относительно курсов моего банка и ЦБ это получается 1-2.3% потерь только на этом.
Вот тебе и нулевая комиссия.
И комиссия эта весьма и весьма солидная по меркам российских ПС.
А с учетом конвертации с карты по дикому курсу вообще достигает 10%.
рублемдолларами и выплатить мне всю комиссию, которую я оплачивал, совершая переводы через пейпал другим пользователям?Покажите, где это бесплатно в русской части Пэйпала?
А, да. Считайте, что речь идет о «серверсайдах».
У вас на Жабе, у нас на Перле, суть-то та же.
Ну да. СУБД в веб-разработке OLTP-систем достаточно узкое место, чтобы убивать его еще и кривыми запросами, неработающими индексами итп.
Вас огорчает Ваше представление о разделении труда у нас ;)
Если мне нужен разработчик с хорошими знаниями баз данных, как же не обращать?
DBA — не стану, не смогу, да. Разработчика — вполне.
Надеюсь, у вас не ДБА запросы пишет? ;-)
Ну да, а плюсовик вряд ли расскажет что-то про виртуальную машину Java.
И вряд ли его будут спрашивать какие-то тонкости Java на собеседовании, правда?
Зачем спрашивать вещи, которые прописаны в документации?
Указанный вопрос не относится к тонкостям настройки. Это базовые знания, которые можно подчеркнуть, прочитав единожды Oracle Database Concepts.
Упаси Бог. У меня есть немного знаний о разных областях веб-разработки, но специалистом ни в одной из них я себя не могу называть. Разве что, в базах данных разбираюсь немного лучше, чем, скажем, в программировании на Perl. Но даже базовых знаний хватает, чтобы вывести на чистую воду большинство тех, кто приходит на собеседования.
Что именно? Какие поля нужны в таблице очереди или что использовать для демонизации диспетчера?
Во-первых, для большей гибкости.
Архитектурно первый способ от второго отличается только отсутствием диспетчера.
И там, и там придется реализовывать остальные 5 компонентов.
Первая — частный случай второй. Но не наоборот.
Соответственно, реализовав описанную схему, мы сразу же фактически реализуем первую.
Но реализовав первую, вторую придется реализовывать отдельно.
Хорошо, если при этом пустят на единые рельсы, а не добавят костыль сбоку, как это часто случается.
Во-вторых, не все функции платежных систем доступны только по первой схеме.
Например, выставление счета (в терминологии платежной системы) пользователю возможно только, если инициатор — магазин. Это и для Пэйпала, и для ОСМП, и для Манимэйла и для других платежных систем характерно.
По сути, первая схема может применяться, если магазину не нужны расширенные функции платежной системы, а вполне достаточно базовых.
Во вступлении к статье я указал, что платежных систем по условиям задачи не подключено вообще.
Статус по умолчанию при создании заявки — это 6 байт в модуле работы со счетами:
$status ||= <код_по_умолчанию>Новые функции нужны только для модуля работы с конкретной платежной системой, а его и так в каждом случае реализовывать. В целом же они ровно те же — сформировать параметры для передачи в платежную систему / разобрать ответ платежной системы.
Доделки минимальны, они не влияют на архитектуру в целом.
Резюмируя:
1. отличия первой схемы от второй — минимальны.
2. вторая — общий случай первой.
3. Нужна простота — первая. Нужна гибкость — вторая.
Но вообще, да, спасибо
И в случае смс, и в случае карт, и в случае денег, конечно, есть случаи, когда выходить придется:
sms — пополнить счет, если баланс нулевой
карта — пополнить счет, если баланс нулевой, или получить новую карту, если старая проэкспайрилась
деньги — пополнить счет, если баланс нулевой.
Но если со счетом всё хорошо, выходить никуда не потребуется, в отличие от ОСМП или Сбербанка, где выходить придется всегда.
Это уже не моментально.
Работают только по второй или умеют работать и так, и так?
Если последнее, то это и PayPal, и MoneyMail, и OSMP, например.
Это не так. Чтобы началась работа с ПС «первого рода» достаточно:
1. Добавить новый статус а-ля «Пользователь ушел в ПС, но проверять статус не надо», который не будет обрабатываться диспетчером.
2. Добавить в БПС функцию разбора HTTP-запроса от ПС «check» и «pay» фаз с выдачей номера заявки в нашей системе и формированием корректного ответа этой ПС.
3. Добавить в веб-интерфейс функцию обращения к ОБ для получения номера из 2.
В этом случае на check определяем номер заявки, получаем статус заявки, если ее можно оплатить, возвращаем ПС ответ «Бери деньги с пользователя», сгенерированный в БПС.
На pay — определяем номер заявки и меняем статус, если это возможно.
Это гораздо более простой случай, поэтому я его не рассматривал.
Но он прекрасно ложится на описанную схему.
Так это смотря какая гибкость нужна сайту для работы с ПС.
Если она не нужна — имеем работу «первого рода» без диспетчера и с 2-3 статусами.
Если нужна — второй род, диспетчер, 10 статусов.
Архитектура одна и та же
Плюс делает какие-то доп.вещи, например, пишет логи ответов от платежных систем в едином формате.
В качестве аналогии приведу пример: есть наковальня, есть молот, есть изделие. Диспетчер — это кузнец. Или кузнецы, в зависимости от нагрузки.