По заголовку может показаться, что я внезапно начал стартапить стартапы, но тут ситуация немного другая. Начну по порядку и всё станет понятно.
Более пяти лет назад
Я был молод и полон сил, и как-то по воле судьбы начал общаться с одним композитором, проживающим в Германии много-много лет. Познакомились мы забавно, через мою группу в ВК (да, когда-то и такой ерундой страдал по юности, они тогда только появились). Свела нас, короче, музыка и любовь к конкретным музыкальным коллективам 😀
Спустя год-другой, мы начали обсуждать одну безумную идею – а не создать ли нам совместный продукт, посвящённый продаже royalty-free музыки.
Что это? Зачем это?
Такая музыка нужна, если вы хотите, например, музыкальный фон в фильме / игре / ролике / презентации и прочее-прочее-прочее. Короче говоря, музыка для коммерческого использования.
А нужен ли «ещё один сайт»?
Как оказалось – нужен. Во время разработки системы у топовых конкурентов (которые гребут денежки лопатой) с технической стороны всё было ну очень плохо: сайты старые, выглядели стрёмно, работали так себе. Брали они именно известностью, оборотами и т.д.
Проблемы, как я писал выше, были и с технической частью, и с отсутствием нормальной модерации контента, поэтому они превращались в мусорку.
Наша же идея была очень проста – сделать просто аккуратный сайт с контентом, который подбирался исключительно руками. Как показала практика последующих лет – это работает.
Увы, не всегда мы уделяли время рекламе, иначе вообще был бы здорово. Узнал я это в этом (2020) году, когда мой партнёр решил снова уделить время сайту и начать там разные рекламные компании, типа раздачи своих треков и т.д. Людей набежало очень много. Многие из них потом ещё и покупали треки, продажи взлетели, стало приятно.
Ну сайт сделали. Круто. А стартапер-то чего?
Для меня «стартапер», это когда сделал стартап, который взлетел (а не когда просто пытаешься и ничего не выходит). Но тут же нет взлёта – доходы скромненькие, хотя и окупили все затраты и текущие расходы. Где взлёт-то?
А вот со взлётом и самое интересное. У стартапов есть 2 варианта успеха:
- Вы стали очень популярны, деньги летят вам в лицо.
- Вы стали достаточно интересны, чтобы вас купил кто-то другой.
Так вот, у меня случился второй кейс – нас захотели купить. При этом, это не было в стиле «о, вы прикольные, за скок бизнесок отдадите?». Всё было совсем иначе. Как раз после буста продаж в конце 2020 с нами связалось агентство, которое занимается продажей онлайн-бизнесов (актуальненько для 2020, не так ли?) и предложили выставить наш бизнесок на продажу, да ещё и бесплатно, раз они сами на нас вышли (поизучав их платформу, мы узнали, что они берут деньги за размещение и % за сделку).
Немного подумав, мы пришли к выводу, что нет ничего плохого в том, чтобы выставить нормальный ценник за бизнес, вдруг кому-то нужно? В худшем случае при своём-то и останемся.
Продались! Скатились!
Как сказал мне уже на следующий день мой дорогой сопартиец, «никогда у меня не было столько непрочитанных сообщений». Начиная с этого момента мы поняли – продажа это не какая-т фантазия, а вполне реальная история, главное найти, кому не жалко передать.
Спустя всего два-три дня у нас уже было несколько желающих выкупить бизнес за ту цену, которую мы установили (довольно справедливую, я бы сказал, учитывая, как была реализована система). Так что выбор теперь был не «кто больше даст», а «кому продавать выгоднее».
Потенциальные покупатели совершенно по-разному подходили к сделке: кто-то погружался в техническую часть, кого-то больше волновала бизнесовая составляющая, другие хотели очень странные правила передачи прав и оплаты… В любом случае, на фоне начали маячить настоящие игроки – владельцы успешных медиа-компаний, которые, при желании, смогли бы очень неплохо раскрутить данный сервис, а ещё они были не против в каком-то формате продолжить сотрудничество с нами и после продажи.
Однако, решение было выбрано в пользу покупателя, кто был готов максимально быстро всё провести и согласился на то, чтобы сделать платёж максимально удобным для нас. А дальнейшее сотрудничество… ну… может оно и правда не так и нужно, не факт, что я нашёл бы время на то, чтобы переписать приличную часть сайта.
Переезд
Собственно, о чём речь-то? Да всё просто. Мало «отдать» бизнес на бумажке, нужно же и все аккаунты передать, а где нельзя, то передать сервисы. Короче говоря, мне нужно было:
- Переместить сайт на новый хостинг (клиента).
- Переместить 300ГБ+ музыки с моего Amazon S3 на аккаунт клиента (а это геморно).
- Настроить Amazon S3 на сайте, чтобы интеграция заработала.
- Настроить Amazon SES (рассылка писем), чтобы письма уходили как надо.
- Перевести части админской системы, которая исторически была частично на русском.
- Перенастроить сайт на новый платёжный аккаунт PayPal.
Казалось бы, всё фигня! Я и сам так думал. Однако, как я часто говорю, со мной просто не бывает…
Что пошло не так
Ну, то, что хостинг так себе (SiteGround), особенно после моего (Beget) это прямо факт. Матерился я много, но сайт запустил. Это самое простое, я бы сказал. С переводом тоже всё было ожидаемо и планомерно, сиди да проглядывай весь кастомный код и проверяй, нет ли чего лишнего. Рутина, короче.
Неприятное началось с перевода S3 на S3, где концептуально понятно что делать, но путей есть много. Итого я на аккаунте клиент запустил микро-инстанс EC2, создал в IAM аккаунт и дал ему право стучаться в оба S3 аккаунта. В Source на чтение, в Target на запись и чтение. Ну а дальше… Рекурсивное перемещение всех объектов. Что-то вроде CP на Linux. Так что тут «долго читаем», «немного готовимся» и «долго ждём, пока всё перенесётся».
Ну, скопировали хранилище, а дальше? А тут небольшая архитектурная гадость. Ну, как сказать гадость… изначально всё разрабатывалось под хранение треков ещё на Dropbox (и работало отлично), однако со временем всё перевели на S3. Но Вышло так, что каждый файл хранил полную ссылку до ресурса, так что пришлось делать SQL REPLACE в нескольких таблицах, а не красиво поменять значение в 2-3 полях в конфигах. Но это скорее потратило время, чем было хоть сколько-нибудь сложным. Как итог, все музыкальные превью и файлы для загрузки теперь ссылаются на хранилище клиента (меньше оплачиваемого траффика мне!).
С настройкой SES всё упиралось в то, чтобы саппорт Amazon перевёл учётную запись в статус production. Я каждый раз забываю, что после регистрации аккаунта SES он находится в песочнице и с ним нельзя работать, пока его не активируют. В этот раз это затянулось аж на сутки (обычно сильно быстрее). Однако, подключившись по SMTP я не смог отправлять письма, что немного расстраивало, ведь это основная задача SES… Потратив кучу времени, оказалось, что проблема опять же в регионах (ух, этот Amazon), только в этот раз дело было в том, что пользователь для SES был создан в одном регионе, а для отправки нужен был второй. В любом случае, создав пользователя и выдам ему нужные права… всё решилось.
Отлично идём, не так ли? А вот нет. На почту я потратил час-полтора, на переезд S3 часа 3-4, хотя там больше в фоне шла передача, так что тут я мог другим заниматься. НУ с хостингом ещё часа 4 любился (при том дважды, сначала тестовый разворачивал, потом продакшн перекидывал, чтобы оффлайн сайт не висел. А я ничего не забыл? А, да, точно. Такая мелочь как… ПЛАТЁЖНАЯ СИСТЕМА.
Вот с ней и самая БОЛЬ. Почему? А всё просто. Так исторически сложилось, что мой партнёр на момент старта бизнеса (да и регистрации) проживал в Германии, так что по его просьбе оплата была через сервис PayPal plus, который на тот момент позволял с минимумом усилий платить через аккаунт палки или просто вбивая кредитку. Удобно для покупателей, удобно для продавца. Продавец определяется 3мя сущностями:
- ClientID — длинный ключ, идентифицирующий клиента.
- ClientSecret — ещё более длинный криптостойкий ключ (private key, если хотите)
- Email — тут всё понятно.
Следовательно была мысль, что поменяю три значения и пойду в очередь за денежкой. А вот фигульки! Как оказалось, PayPal Plus работает только в Германии, да нескольких странах Латинской Америки. Бум! А клиент-то из США. Вот подстава.
Самым близким аналогом оказался PayPal Business, который использовал 1-2 тех же endpoint’ов, однако процесс оплаты немного отличался. Чтобы дойти до того, что API не подходит тоже потребовались часы, я всё пытался понять, чего оплата после смены ключей падает партнёру, а не клиенту (поэтому не бежал читать маны по плюсу — ведь не ошибка была, а деньги уходили не туда). Я перелопатил весь код покупки и долго не мог понять, что за магия.
Ответ был прост и глуп (как и я), всё как обычно. Я не сразу заметил, что все запросы о создании транзакции идут с Bearer-токеном, а он, зараза-такая, живёт минимум 3 часа, а то и больше… ну и как следствие посылался старый токен, который и определял продавца. Стоило мне его обновить… как всё посыпалось и я получил ту самую ошибку, что не туда лезу, регионом не ошибся, фраерок?
Не буду рассказывать, как я переделывал оплату, но скажу, что ушло очень много времени, в основном на изучение старого кода сайта и построения в голове процесса оплаты и формирования всех необходимых сущностей, а потом ещё нужно было изучить и выбрать самый простой способ внедрения новой системы оплаты (не слишком заморачивался, ведь клиент будет с большой вероятностью уходить от палки в будущем). После долгих ковыряний и попыток оставить процесс, похожий на тот, что уже был реализован я плюнул на это и пошёл по самому простому пути. В текущей версии PayPal Business по-умолчанию оплата идёт через фронт (когда нужно просто получить деньги, и не нужно ничего рассылать-проверять). Там было 2 события:
- Подготовка платежа.
- Подтверждение платежа.
Я плюнул на то, чтобы переносить шаг 1 на сторону сервера и просто начал передавать на страницу выбора способа оплаты (кредитка или палка) ID транзакции сайта (из которой можно было вытянуть вообще всё, что нужно для верификации позже) ну и сумму для оплаты.
Когда оплата проходила, ответ прилетал на эту же страницу в JS, откуда при срабатывании соответствующего события, вызывался запрос на сервер о валидации покупки, куда передавался ответ от PayPal, а именно:
- PayPal Transaction ID — по этому параметру можно потом проводить проверку на сервере.
- Website Transaction ID — внутренний ID покупки.
Из этих двух параметров можно достать всё необходимое. Обратившись по первому в PayPal узнавался статус оплаты, сумма, а также внутренний ID покупки. Далее стоило лишь вытянуть из БД те же данные и сверить их. Если всё совпадает, то мы меняем статус покупки в БД и радостно шлём Emailы всем причастным. Profit.
Оставалось только всё накодить, протестировать и переключить в production. К счастью, всё это, начиная с разработки концепции, получилось разработать за один день (ну точнее до отхода ко сну часа в 4 утра). Хорошо, что на следующий день был выходной!
Финал
На этом, я думаю, историю можно и закончить. Остался только вопрос получения финансов, которые в данный момент были отправлены через transferwise от фирмы-посредника моему партнёру. Дальше всё просто – взять, да получить своё! 😉