Інтеграція Tpay з авторським додатком

Бюджет: 1800 PLN Термін: 4 дні

Доброго дня, можу зайнятися ремонтом інтеграції Tpay в додатку Base44. Оцінюю етап діагностики та впровадження виправлення на 1800 PLN і приблизно 4 дні, за умови, що буде доступ до панелі Tpay, логів вебхуків та конфігурації пунктів отримання в Base44.

Спочатку перевірю повний цикл підписки - перший платіж, запис аліасу BLIK, оновлення, вебхук з Tpay до додатку та реакцію додатку після невдалої спроби. Тут стандартно проблема полягає не в самому платежі, а в мапуванні аліасу, статусах транзакцій або в тому, що додаток не розрізняє першу транзакцію та циклічне стягнення.

Два питання перед точною оцінкою
> Чи надає Base44 можливість редагування власної серверної частини або тільки дії та інтеграції без повного сервера
> Чи є логи з Tpay на момент, коли підписка закінчується і плата не стягується повторно

Схожий досвід
> https://business.ingello.com/vorfahr - автоматизація та інтеграції процесів з платежами та логікою користувача
> https://business.ingello.com/prime-eva - електронна комерція, замовлення, інтеграції та контроль коректності даних
> https://systems-fl.ingello.com - Ingello Systems для проектів з архітектурою, інтеграціями та автоматизацією

Якщо після аналізу виявиться, що Base44 не дозволяє правильно обробляти циклічні вебхуки, запропоную маленький модуль API посередник. Можна не ускладнювати, але при платежах краще мати стабільний механізм, бо хто платить двічі за ту ж саму помилку, платить найдорожче =) Розгорнути

Бюджет: 2500 PLN Термін: 30 днів

Я проведу інспекцію логів і впроваджу правильну обробку поновлень через API Tpay (метод циклічний з використанням збереженого cli_auth), без залучення користувача до повторного введення коду BLIK. Банальні фінансові питання — в приватному повідомленні.

Проблема з циклічним BLIK-ом найчастіше виникає з того, що при наступній спробі списання (коли закінчується термін дії підписки) додаток надсилає запит як стандартний, одноразовий BLIK замість методу api/v1/transaction/execute-saved-alias, або сервер не обробляє правильно асинхронне повідомлення (Notification URL) від Tpay, що підтверджує реєстрацію псевдоніму користувача. Чи маєш ти наразі можливість переглянути, що саме повертає Tpay у логах у момент, коли додаток намагається автоматично поновити підписку?

Бюджет: 2000 PLN Термін: 7 днів

Привіт, я працював над інтеграцією Stripe з мобільним додатком для фітнес-студії, де налаштовував автоматичне списання щомісячної підписки з 95% успішністю транзакцій 150+ активних користувачів

Цікаво, чи проблема з webhook'ами виникає тільки для BLIK, чи інші методи оплати також мають проблеми з відновленням підписки?

Пропоную зв'язатися, я безкоштовно проконсультую вас з технічної сторони та складемо план розробки + розповім про мою команду!

Бюджет: 2000 PLN Термін: 6 днів

Зрозумів завдання: додаток, побудований компанією Base44 (no-code AI builder), опублікований у Google Play як Зона Перетворених. Tpay як платіжний шлюз, BLIK циклічний встановлений. Перше платежі проходять коректно, банк записує циклічне платежі, але при оновленні підписки аліаси BLIK не стягують плату — і виникає проблема на вебхуках (App↔Tpay).

За шаблоном Tpay та типовими помилками в BLIK recurring найчастіше винні три речі.

Перша — вебхук від Tpay приходить, але додаток або не підтверджує його статусом 200, або використовує інший endpoint, ніж зареєстрований у панелі Tpay. Tpay перевіряє відповідь — якщо додаток не відповість зі статусом 200 і правильним підписом md5/sha256, Tpay вважає вебхук недоставленим і кілька разів повторює, а потім перериває циклічне платежі. Треба перевірити в панелі Tpay url нотифікації та логах вхідних запитів зі сторони додатка.

Друга — аліас BLIK має обмежений термін дії. У BLIK recurring після першої транзакції аліас видається банком клієнта. Якщо клієнт не підтвердив циклічну згоду в банківському додатку (частина банків вимагає активного підтвердження recurring після першої платежі), аліас є одноразовим, і при спробі оновлення банк відхиляє операцію. Це потрібно перевірити на конкретному тестовому клієнті — чи в його банківському додатку видно активну циклічну згоду.

Третя — неправильний channel ID або group при виклику наступної циклічної транзакції. Перша транзакція може ініціюватися з channel BLIK_TRANSFER, а наступні циклічні повинні проходити через channel BLIK_LEVEL_ZERO з параметром recurrent=1 і правильним токеном клієнта. Якщо Base44 генерує код без цієї різниці, всі оновлювальні платежі будуть намагатися як нові і збоїти.

Що планую зробити. Перше — заходжу в панель Tpay і перевіряю логи вебхуків за останні 14 днів, ідентифікую, чи нотифікації виходять і з яким статусом повертаються. Друге — в додатку Base44 потрібно знайти частину, відповідальну за обробник вебхука, і перевірити код відповіді плюс верифікацію підпису. Третє — перегляд виклику циклічної транзакції в коді додатка (якщо маємо доступ до коду Base44 — питання, чи генератор дає експорт). Четверте — виправлення після ідентифікації конкретної причини, тестування на тестовому рахунку Tpay (sandbox) і потім на реальному рахунку з малою сумою.

Питання до Вас: чи дозволяє Base44 редагувати/експортувати код, чи виправлення може бути внесено тільки через їхній інтерфейс? Чи маєте Ви доступ до панелі? Розгорнути

Бюджет: 800 PLN Термін: 1 день

Доброго дня. Готов виконати даний проект маю великий досвiд розробки додаткiв

Бюджет: 1200 PLN Термін: 30 днів

Привіт! Я ознайомився з вашим завданням і вважаю, що зможу успішно його виконати. Буду радий співпраці, будь ласка, напишіть мені особисто для подальших деталей.

Бюджет: 1500 PLN Термін: 7 днів

Freelancehunt

Заявки для фрілансерів

Інтеграція Tpay з авторським додатком
Гібридні мобільні додатки, Програмування на Android — вказано неправильні категорії?
2 з 6
прийом пропозицій
Наступний крок: затвердження умов

Замовлю інтеграцію платіжної системи Tpay з моїм авторським додатком. Йдеться про правильну реалізацію, щоб підписка автоматично поновлювалася через циклічні платежі BLIK, які вже налаштовані, але є проблема з поновленням. Додаток створюється мною за допомогою AI на сайті Base44. Додаток працює (магазин play Strefa Przemienieni.pl), я не програміст і маю проблему з інтеграцією. Вся система, здається, працює і забирає при першій транзакції гроші у користувача, зберігає в банку як циклічний платіж, але є проблема з псевдонімами BLIK, і коли закінчується підписка, не хоче знову забрати плату. Проблема на лінії відповідних webhook App-> Tpay і Tpay -> App.

Пропозиції 8
Обговорення 0

1988
10 0
Приклад роботи:
Як Gemini API з'їв 180 доларів за місяць: справжня економіка AI
30 днів2500 PLN
Арсеній Антоненко

Проведу інспекцію логів і впроваджу правильну обробку поновлень через API Tpay (метод циклічний з використанням збереженого cli_auth), без залучення користувача до повторного введення коду BLIK. Банальні фінансові питання — в приватному повідомленні.

Проблема з циклічним BLIK найчастіше виникає з того, що при наступній спробі стягнення (коли закінчується термін дії підписки) додаток надсилає запит як стандартний, одноразовий BLIK замість методу api/v1/transaction/execute-saved-alias, або сервер не обробляє правильно асинхронне повідомлення (Notification URL) від Tpay, що підтверджує реєстрацію псевдоніма користувача. Чи маєш ти зараз можливість переглянути, що саме повертає Tpay у логах у момент, коли додаток намагається автоматично поновити підписку?

Схоже виконане замовлення: В модулі OpenCart виправити 5 проблем, пов'язаних з Facebook API
26 травня, 20:40
685
5 0

7 днів2000 PLN
Максим О.

Привіт, я працював над інтеграцією Stripe з мобільним додатком для фітнес-студії, де налаштував автоматичне стягнення місячної підписки з 95% ефективністю транзакцій для 150+ активних користувачів.

Цікаво, чи проблема з webhook'ами виникає тільки для BLIK, чи інші методи платежів також мають проблеми з поновленням підписки?

Пропоную зв'язатися, охоче пораджу тобі безкоштовно з технічних питань. Розгорнути

Бюджет: 18000 PLN Термін: 6 днів

Доброго дня. Завдання зрозуміле: не просто “бот з ІІ”, а нормальна система, яка регулярно забирає тендери Prozorro, фільтрує зайве, пояснює, чому тендер підходить/не підходить і надсилає це в Telegram.

Я б зробив так:
1. Окремий backend-процес для моніторингу Prozorro і зберігання стану, щоб не втрачати нові тендери і не надсилати дублікати.
2. Правила фільтрації + AI-аналіз поверх вже очищених даних, щоб модель не фантазувала, а працювала за зрозумілими критеріями.
3. Telegram-бот з короткими картками: суть тендеру, дедлайн, сума, чому релевантно, посилання, швидкі дії.
4. Логи/помилки/повторні спроби, тому що такі системи повинні спокійно жити без ручного нагляду.

У мене був схожий за логікою проект: n8n/PostgreSQL/OpenAI/Telegram система, яка кожен день аналізувала дані і надсилала людям конкретні завдання, а не просто “AI-текст”.
По термінах: орієнтир 6 днів. По бюджету: 18000 — після короткого уточнення ТЗ скажу точно, але порядок такий.

Якщо ок — почну з короткої схеми архітектури і списку уточнень, щоб одразу зафіксувати MVP без зайвої розробки. Розгорнути

Бюджет: 1000 PLN Термін: 5 днів

Доброго дня. Маю великий досвід в інтеграціях платежів, API та вебхуків. Можу перевірити поточну реалізацію Tpay/Base44 та виправити проблему з оновленням підписок і псевдонімами BLIK. Прошу надати доступ до коду та тестової панелі, тоді оціню точний обсяг і терміни.

Бюджет: 2000 PLN Термін: 5 днів

Вітаю. Мене звати Роман , CVO компанії Echocode. Digital
Маємо досвідчену команду із 8-річним стажем у створенні веб-сайтів «під ключ», мобільних додатків та складних веб-систем.
За 8 років практики сформували глибокий технічний стек.
Вам не доведеться окремо шукати дизайнера, бенкендера та фронтендера. Наша команда працює в єдиній зв'язці, що виключає непорозуміння між дизайном та кодом, суттєво прискорює розробку та гарантує якісний результат з одних рук
Пишіть нам у приватні повідомлення! Обговоримо деталі вашого проекту, прорахуємо точні терміни та бюджет.
Freelancehunt