Типова задача для оплати в магазинах. Робили щось схоже, але ссилка на сторінку оплати формується на стороні back end і виводиться на екрані застосунка. +/- для основних платіжних систем(PAYPAL, WAY FOR PAY, LIQPAY, MONOBANK) є приклади в їх документації на різних мовах. Складнощі були лише PRZELEWY24 — це польська система оплати. А чому Ви не зробили формування оплати на стороні back end?

Хороша стаття, хороша добірка матеріалів.

Гарна візуалізація і розбір роботи Event Loop.

мені по візуалізації і розумінні Event Loop допомог latentflip.com/loupe

1С заборонили, створили BAS з реєстрацією в ЄС.
Обновлення на BAS конфігурації випускають постійно з врахуванням закондавства і т.д.
Вже сформована повністю спільнота користувачі, бухгалтера, програмісти і т.д. Кількість програмістів буде зменьшуватися, але ще на років 20 залишиться кому працювати, тому що перейти з фунціонального програмування на ООП з кучою технологій на ринку який падає, доволі важко, знаю підприємства які ще працюють на 7-ій версії 1с)
Навіть не уявляю чим можна це все замінити, якою системою обліку. Зрозуміло що для типового обліку підійдуть більшість CRM, але якщо в тебе обмін з різними сайтами, ти хочеш якісь свої нові колонки в документах, які динамічно щось показують (собівартість, ціни, залишок і т.д.), документи, налаштування специфічних прав користувачів (rls), зробити свої складні звіти чи друковані форми, друк етикеток, чеків, зробити за тиждень свій мобільний додаток і інтегрувати з CRM і ще кучу плюшок за мінімальні кошти то це не можливо...
Але дуже круто що появляються нові CRM системи замість 1С/BAS, Битрикс... Так що бажаю Вам вдачі і хорошого маркетингового плану!

Дякую за статтю, доволі цікаво і корисно. Було б цікаво, якби Ви ще поділилися самими корисними ресурасами, які допомогли вивчати з aws.

думаю в тебе все вдасться)

Дякую. На даному етапі ні, зараз в пріорітеті typescript і патерни. Але в подальшому треба буде мати загальні знання для проектування проектів...