Бюджет: 2000 UAH Термін: 3 дні
Доброго дня.
Готовий допомогти з проєктом.
Якщо у вас є питання можете написати мені в ЛС.
Добрий день! Ситуація така: встановили модуль Stripe на Opencart. Модуль працює, проте є один нюанс: якщо покупцеві в процесі оформлення замовлення не вдалося оплатити замовлення або він передумав платити (або ще щось сталося), статус все одно переводиться в "In process". Вручну перевіряти надходження оплати не представляється можливим, тому що цей модуль посередницький і весь доступ до страйпу складається лише тільки з токена. Відповідно потрібно налаштувати Stripe і Opencart таким чином, щоб замовлення переводилося в статус "In process" тільки за умови, що була отримана оплата. Причому перевірка оплати має бути автоматична - через цей мтокен. Тобто саме формування замовлення - нічого не значить, потрібно створити повторну перевірку (або доробити поточну), яка 100% підвердить отримання коштів на рахунок Stripe в повному обємі і тільки після цього переведе замовлення в статус "In process". Можливо, до речі, що така перевірка налаштовується з коробки - я не знаю точно. Однак у програміста, який налаштовував цей модуль - це не вийшло. Відповідно шукаю людину, яка вже налаштовувала Stripe і знає про такі нюанси.
Додам, що цікавить тільки офіційний модуль Stripe, тому що Stripe сам зберігає дані кредитних карток, за що несе сам відповідальність, відповідно, форма оплати має бути саме страйпівська: https://prnt.sc/rGHQDJWA2lv1 , тому що не хочемо збирати дані про кредитки людей самі. Або щоб це робив сторонній модуль.
Також чомусь зникла кнопка "Confrm order", якщо я обираю спосіб оплати "Stripe", і я не можу протестувати Необхідно її повернути: https://prnt.sc/ov5g9UZnyF3D
Бюджет: 2000 UAH Термін: 3 дні
Доброго дня.
Готовий допомогти з проєктом.
Якщо у вас є питання можете написати мені в ЛС.
Бюджет: 2500 UAH Термін: 1 день
Готовий взятися за роботу, пишіть, зроблю все якісно. Досвід роботи вже більше 12ти років!
Бюджет: 2500 UAH Термін: 3 дні
Добрий день, є досвід роботи з stripe api, готовий займатися рішенням, звертайтеся
Шукаю досвідченого Full-Stack веб-розробника для створення сайту під ключ. Є готовий сайт-зразок, який потрібно взяти за основу, покращити, доопрацювати та реалізувати з урахуванням сучасних рішень. Що потрібно: розробка сайту під ключ; покращення дизайну та користувацького інтерфейсу; підключення платіжної системи; адаптивна верстка для всіх пристроїв; налаштування адміністративної панелі та всього необхідного функціоналу. Готовий розглянути ваші ідеї та пропозиції щодо покращення проекту. Прошу відгукуватися тільки спеціалістів з реальним досвідом та портфоліо. Важливі відповідальність, терпіння та бажання довести проект до якісного результату. По ціні можемо домовитися!
Всім привіт, потрібно створити сайт для створення івентів та продажу квитків. Можливі варіанти на готовому шаблоні, фреймворк, або ваш варіант. Бажано щоб у вас був досід роботи в розробці сайтів для продажу квитків. Приклади сайтів надішлемо у приватні повідомлення. За необхідності створимо прототип. Якщо ви раніше працювали над створенням подібних сайтів надішліть будь ласка приклади в приватні повідомлення. Деталі обговоримо в приватних повідомленнях. Дякую і гарного дня!
Що ми рахуємо у проєкті: Realized PnL, ROI і Win Rate для криптогаманців - наскільки прибутково гаманець торгував певним токеном за обраний період. На яких даних: історія on-chain транзакцій гаманця (свопи, перекази токенів) + ринкова ціна токена на момент кожної угоди. Основне джерело даних - Moralis: два виклики під час первинного завантаження гаманця - нативні ETH-перекази і усі ERC-20 token transfers. З чим порівнюємо: Nansen.io - беремо як еталон, порівнюємо наші розраховані метрики з тим, що показує Nansen для тих самих гаманців за той самий період. Проблема: наші цифри суттєво відрізняються від Nansen, і ми не до кінця розуміємо, за якими правилами частина дій гаманця має класифікуватись для цілей PnL. Потрібно пофіксити розрахунок Realized PnL, ROI і Win Rate, щоб збігались з Нансеном. В заявці напишіть плз : - досвід в схожих задачах - досвід з Nansen - досвід з Moralis - досвід з DeFiLlama - досвід зі статою по криптоопераціям - приблизну вартість і сроки фіксу
Сайт працює на фреймворку Next.js (на базі React). Потрібно зробити всі пункти за ТЗ. ТЗ додається у файлу. Чекаю на пропозиції.
Сайт для оцінки: https://copy.eurobrands-shop.de/ Завдання: виправити frontend-баги на рівні теми Magento 2 / Amasty theme: CSS/LESS/JS, mobile, RTL, minicart, language dropdown, layout shift/CLS. Формат роботи: - без локального розгортання Magento; - робота через DevTools + вихідники теми; - правки в CSS/LESS/JS/template-файлах теми; - результат: diff / коміт / архів змінених файлів; - деплой і збірка на нашій стороні; - робота через безпечну угоду; - NDA до передачі вихідників/доступів. Що потрібно перевірити і оцінити: 1. RTL / арабська версія: - телефон у шапці відображається некоректно; - зміщення елементів у header, minicart, wishlist/account, product page; - відступи, direction, unicode-bidi, позиціонування. 2. Header: - language dropdown; - cart/wishlist; - hit-area іконок. 3. Minicart: - нестабільно відкривається на деяких сторінках; - перевірити Console / Network / Event Listeners / customer-data / z-index / overlay. 4. Mobile: - бейджі корзини/wishlist занадто великі; - блок Categories стискається/обрізається; - mobile menu / Menu-Account. 5. Product page: - layout shift / CLS зображення; - Add to Cart / Quantity / BOX / PALLET в RTL. 6. Wishlist/account: - /wishlist/ - /mwishlist/ - вкладки, Back button, переповнення лічильників. Проблемні URL: - https://copy.eurobrands-shop.de/alpro - https://copy.eurobrands-shop.de/producers - https://copy.eurobrands-shop.de/wishlist/ - https://copy.eurobrands-shop.de/mwishlist/ В відповіді напишіть: 1. Чи є досвід з Magento 2 frontend? 2. Чи є досвід RTL? 3. Скільки годин потрібно на перший етап? 4. Яка вартість? 5. Коли можете почати? 6. Які доступи потрібні? 7. Чи готові працювати через безпечну угоду і підписати NDA? Важливо: потрібен конкретний результат — виправлення або технічне пояснення по кожному пункту: виправлено / не відтворюється / не frontend-проблема.