Це Розкриття інформації щодо ескроу та платежів («Розкриття») пояснює, як у PRE-ORDER використовується платіжна термінологія, як очікується обробка платежів і, зокрема, що PRE-ORDER має і не має на увазі, коли в інтерфейсі, транзакційних документах, технічних описах або повідомленнях використовуються слова «утримується», «зарезервовано», «в очікуванні», «депозит», «передоплата», «вивільнення», «розрахунок» або «ескроу».
Мета цього Розкриття – не допустити припущення, що PRE-ORDER самостійно утримує кошти на регульованому ескроу–рахунку або діє як банк, платіжна установа, установа електронних грошей, довірчий керуючий чи ескроу–агент. Документ слід читати разом з Умовами користування, Умовами маркетплейсу, Угодою з Покупцем, Угодою з Продавцем, Політикою платежів та передоплати, Політикою повернень і скасувань, а також конкретними документами замовлення чи B2B-транзакції.
Важливе розкриття
- PRE–ORDER Europe EOOD керує цифровою Платформою, але самостійно не надає регульовану ескроу-послугу.
- Інтегровані онлайн-платежі передбачається обробляти через Stripe та/або відповідну компанію групи Stripe чи іншого регульованого постачальника платіжних послуг, зазначеного в платіжному процесі.
- Кошти, які авторизовані, очікують обробки, затримані, зарезервовані, захищаються, розподілені або ще не виплачені в інфраструктурі платіжного провайдера, не стають через це коштами, які PRE–ORDER утримує в ескроу.
- Продавець, зазначений у лістингу або замовленні, залишається продавцем Товару та стороною, відповідальною за виконання, скасування і повернення коштів за Договором купівлі Товару, з урахуванням імперативного законодавства.
- Якщо в майбутньому PRE–ORDER запровадить справжню ескроу-послугу або подібну регульовану послугу зберігання через належно авторизованого провайдера, постачальник, правова структура, умови вивільнення коштів, комісії та застосовні умови будуть окремо розкриті до того, як користувач візьме на себе зобов’язання.
1. Оператор і мета документа
1.1 Платформу PRE–ORDER експлуатує “PRE–ORDER Europe” EOOD, UIC/EIK 208904127, зареєстрована за адресою: Arthur Residential Complex, Block C, Floor 3, Apartment C44, 8229 Sveti Vlas, Nessebar Municipality, Burgas District, Bulgaria («PRE–ORDER», «Оператор», «ми», «нас» або «наш»).
1.2 PRE–ORDER надає цифрові функції маркетплейсу, передзамовлення, комунікації, керування замовленнями та платіжної оркестрації для fashion-брендів, B2B Покупців і B2C Клієнтів. Це Розкриття стосується платіжних потоків, доступних через такі сервіси або у зв’язку з ними.
1.3 Мета цього Розкриття – прозорість. Воно не замінює умови Stripe, банку, емітента картки, Продавця чи іншого регульованого учасника платежу та не створює з боку PRE–ORDER послугу з приймання депозитів, довірчого управління, ескроу або платіжну послугу.
2. Структура транзакції та сторони
2.1 Якщо checkout прямо не визначає іншу законну структуру, Договір купівлі Товару укладається безпосередньо між визначеним Продавцем і Покупцем. PRE–ORDER надає посередницькі й технічні сервіси та може сприяти передаванню платіжних інструкцій.
2.2 Продавець визначає або затверджує ціну Товару, умови виробництва та графік платежів, що застосовуються до його Товару, з урахуванням правил Платформи й імперативного законодавства. Покупець сплачує відповідно до платіжної моделі, показаної до виникнення відповідного платіжного зобов’язання.
2.3 Stripe або відповідний платіжний провайдер обробляє чи забезпечує авторизацію платежу, автентифікацію, списання, сторнування, повернення, розрахунки та пов’язану перевірку в межах власних регуляторних дозволів і договірної структури.
2.4 У платіжному ланцюгу також можуть брати участь банк Покупця, емітент картки, платіжна система, постачальник способу оплати, банк-кореспондент або постачальник конвертації валют. Строки та правила їх обробки не контролюються PRE–ORDER.
3. Що означає «ескроу» і чого PRE–ORDER не надає
3.1 У юридичній та фінансовій практиці ескроу зазвичай передбачає утримання коштів або активів нейтральною третьою стороною на визначених умовах і їх вивільнення після виконання встановлених умов. Точне юридичне значення та регуляторні вимоги залежать від юрисдикції і структури.
3.2 PRE–ORDER не є ескроу-агентом і не обіцяє, що кошти Покупця зараховуються на юридичний ескроу-рахунок, який веде PRE–ORDER. PRE–ORDER не приймає кошти Покупця на свій звичайний корпоративний банківський рахунок з метою утримання їх як довірчий власник або ескроу-утримувач конкретної транзакції.
3.3 Платіжний процес може відкладати списання, відкладати виплату, розміщувати суму в резерві провайдера або залишати її в статусі очікування в балансі провайдера без створення ескроу-відносин із PRE–ORDER.
3.4 У технічних специфікаціях, екранах продукту, внутрішніх або зовнішніх описах іноді можуть використовуватися практичні позначення «escrow», «held funds», «release» або подібні слова для опису поетапного платіжного потоку. Якщо платіжний процес прямо не визначає авторизованого постачальника ескроу чи зберігання та не надає застосовні умови ескроу, такі позначення не створюють юридичні відносини ескроу, трасту, фідуціарні чи кастодіальні відносини з PRE–ORDER.
3.5 Користувач не повинен покладатися на PRE–ORDER як на ескроу-сервіс для розподілу ризиків, захисту від неплатоспроможності, переходу права власності або умовного вивільнення коштів, якщо окрема регульована послуга прямо не запропонована і не прийнята.
4. Роль Stripe та інших учасників платежу
4.1 PRE–ORDER обрав Stripe для інтегрованої обробки платежів. Конкретна юридична особа Stripe, спосіб оплати, регульована послуга та застосовні умови можуть залежати від налаштування Продавця, місцезнаходження Покупця, способу оплати, валюти та реалізації, що використовується на момент транзакції.
4.2 Stripe може виконувати або підтримувати токенізацію платіжного методу, Strong Customer Authentication, авторизацію, capture, повернення, спори, onboarding підключених акаунтів, перевірку, settlement, резерви або контроль виплат, якщо це доступно в реалізованому сервісі.
4.3 PRE–ORDER може створювати платіжну сесію, передавати параметри транзакції, отримувати callback/webhook про статус, відображати платіжний статус, розраховувати пов’язані з Платформою суми, ініціювати запит на повернення або підтримувати звірку. Такі технічні дії не роблять PRE–ORDER регульованим утримувачем коштів.
4.4 Платіжний екран, інтерфейс Stripe, документація акаунта Продавця або запис транзакції можуть містити найточнішу інформацію про провайдера, отримувача, merchant descriptor і модель обробки конкретного платежу.
5. Значення поширених платіжних статусів
5.1 Платіжна термінологія може описувати різні технічні та юридичні події. Статус, показаний PRE–ORDER, є користувацьким відображенням інформації, доступної з платіжної інфраструктури та процесу транзакції.
Авторизовано / зарезервовано
Авторизація зазвичай означає, що емітент схвалив або зарезервував платіжну спроможність для можливого подальшого списання. Це не обов’язково завершений переказ Продавцю. Авторизації можуть спливати та потребувати поновлення для довгих періодів передзамовлення.
В очікуванні
Статус очікування може означати, що автентифікація, банківська обробка, capture, settlement, перевірка, risk review або інша подія провайдера ще не завершена. Точне значення залежить від способу оплати і запису провайдера.
Сплачено / списано
Статус paid або captured зазвичай означає, що списання завершено в платіжній системі. Це не обов’язково означає, що Продавець уже отримав виплату на свій банківський рахунок.
Утримується / резерв / відкладена виплата
Ці вирази можуть означати, що кошти залишаються в інфраструктурі провайдера, що виплату відкладено або сума підпадає під контроль провайдера чи Платформи. Це не означає, що PRE–ORDER керує юридичним ескроу-рахунком.
Розраховано / виплачено
Settlement або payout зазвичай означає, що доступні надходження були або перебувають у процесі переказу Продавцю через платіжного провайдера, з урахуванням відрахувань, резервів, сторнувань, повернень або правил провайдера.
6. Платіжні моделі передзамовлень
6.1 PRE–ORDER може підтримувати різні платіжні моделі залежно від колекції, типу Покупця, налаштувань Продавця та етапу запуску. Для конкретної транзакції застосовується модель, показана в підсумку замовлення або погодженому B2B-документі, з урахуванням імперативного законодавства.
- Модель авторизації: платіжна спроможність може бути спочатку авторизована, а списання здійснюється лише після розкритої події.
- Депозит + залишок: спочатку може бути списаний визначений депозит, а решта підлягає сплаті у визначену дату або на етапі.
- Повна передоплата: повна сума може бути списана до виробництва або відправлення, якщо це чітко розкрито.
- Поетапна B2B-оплата: Бізнес-покупець може сплачувати за визначеними виробничими, інвойсними, відвантажувальними або приймальними етапами.
- Модель часткового відвантаження: якщо B2B-замовлення відправляється частинами, платіжні зобов’язання можуть бути прив’язані до кількості або частини поставки, що готова.
6.2 Наявність затримки між оплатою Покупця та виплатою Продавцю сама по собі не є ескроу. Вона може відображати логіку авторизації, цикли розрахунків, обробку підключених акаунтів, контроль ризиків, резерви, потенційні повернення або інший механізм платіжного провайдера.
7. Депозити та передоплати
7.1 Депозит або передоплата – це кошти, сплачені або списані до остаточної доставки. Checkout або B2B-документ має показувати суму до сплати, валюту, строки, подальший залишок, відповідний тригер, умови виробництва та основні правила скасування чи повернення до того, як Покупець буде зобов’язаний.
7.2 PRE–ORDER не описує депозит як захищений ескроу, якщо справжня регульована ескроу-структура прямо не визначена. Депозит може оброблятися і залишатися в платіжному потоці під контролем провайдера або виплачуватися Продавцю відповідно до реалізованої платіжної моделі.
7.3 Формулювання про «неповернення» депозиту не скасовує імперативні права Споживача, обов’язкові засоби захисту у разі невиконання, права за платіжним законодавством або інші права, від яких не можна законно відмовитися.
7.4 Продавець залишається відповідальним за виконання Договору купівлі Товару та за фінансування або схвалення повернень, які належать за законом чи договором, навіть якщо надходження вже були виплачені Продавцю.
8. Поетапні та часткові B2B-платежі
8.1 Оптові транзакції можуть використовувати поетапні платіжні структури, прив’язані до виробництва і доставки. Конкретна quotation, purchase order, invoice, Collection Agreement або інший Договір купівлі Товару може визначати кількості, етапи, строки, Incoterms, часткові відвантаження та платежі.
8.2 Якщо Платформа підтримує депозит до виробництва та сплату залишку після готовності товару до відправлення, це є договірним графіком платежів, а не твердженням, що PRE–ORDER утримує кошти в ескроу.
8.3 Для часткових відвантажень кожна частина поставки може мати відповідний інвойс, суму або строк платежу. Перед оплатою користувачі повинні перевіряти кожен етап у записі замовлення.
8.4 Бізнес-покупці та Продавці можуть погоджувати додаткові гарантії, документарні умови або сторонні платіжні механізми поза стандартним потоком Платформи, якщо це дозволено відповідними угодами. PRE–ORDER не стає гарантом таких механізмів лише через те, що пов’язана інформація записується на Платформі.
9. Виплати Продавцю та вивільнення надходжень
9.1 Виплата Продавцю – це переказ доступних надходжень через платіжного провайдера на визначений розрахунковий рахунок Продавця. Час виплати може відрізнятися від часу оплати Покупцем.
9.2 Статус на кшталт «released to Seller» означає, що відповідний платіжний процес дозволив або ініціював розрахунок провайдера за налаштованими правилами транзакції. Це не означає, що до цього PRE–ORDER утримував суму як ескроу-агент.
9.3 На виплати можуть впливати перевірка, графік розрахунків провайдера, банківські дні, повернення, chargeback, резерви, негативні баланси, санкційна перевірка, fraud review, технічні інциденти або юридичні обов’язки.
9.4 PRE–ORDER не гарантує точний час зарахування банком, якщо конкретний екран транзакції прямо не містить строку, підтвердженого провайдером.
10. Резерви, затримки виплат і контроль ризиків
10.1 Stripe або інший учасник платежу може застосовувати резерви, затримки виплат, rolling balances, verification holds або інші механізми за своїми умовами та застосовним законом. PRE–ORDER також може вимагати або застосовувати пропорційне обмеження транзакції, якщо це передбачено договором і обґрунтовано необхідно для боротьби з шахрайством, повернень, chargeback, недоставки, безпеки, санкцій або виконання закону.
10.2 Резерв або відкладена виплата не є автоматично окремим ескроу-рахунком для Покупця. Правовий захист коштів в інфраструктурі провайдера залежить від провайдера, сервісу, юрисдикції та регуляторної моделі.
10.3 Користувачі не повинні припускати, що резерв провайдера усуває кредитний ризик Продавця, ризик платіжного провайдера, банківський ризик або ризик невиконання транзакції.
10.4 PRE–ORDER може повідомляти про hold, reserve або delayed payout, коли це доречно, але може не мати права розкривати конфіденційні risk rules, методи безпеки або інформацію, обмежену законом.
11. Скасування, сторнування та повернення
11.1 Права на скасування і повернення визначаються імперативним законодавством, Договором купівлі Товару, Політикою повернень і скасувань, Угодою з Покупцем, Угодою з Продавцем та умовами конкретної транзакції.
11.2 Якщо платіж лише авторизовано і транзакція не продовжується, провайдер може зняти або сторнувати авторизацію замість повернення вже завершеного списання. Банк Покупця визначає, коли вивільнена сума знову стане доступною.
11.3 Якщо завершене списання підлягає поверненню, відповідальний Продавець повинен схвалити або профінансувати повернення відповідно до вимог. PRE–ORDER може передати технічну інструкцію на refund через Stripe у межах доступних Платформі повноважень.
11.4 Повернення зазвичай спрямовуються на початковий платіжний метод, якщо закон, правила провайдера або законна домовленість не вимагає іншого. Строк обробки залежить від Stripe, платіжних систем, банків і початкового способу оплати.
11.5 Запит на повернення, статус скасування або спір на Платформі не означає, що кошти перебувають в ескроу під час розгляду питання.
12. Chargeback і платіжні спори
12.1 Покупець може мати право через банк, емітента картки або спосіб оплати оскаржити несанкціоноване чи спірне списання. Такі права існують незалежно від внутрішнього support-процесу PRE–ORDER.
12.2 Продавець і PRE–ORDER можуть надавати Stripe або іншому учаснику платежу записи транзакції, дані автентифікації, комунікацію, інформацію про відправлення чи інші релевантні матеріали у відповіді на chargeback з дотриманням вимог приватності.
12.3 Рішення платіжної системи або провайдера щодо chargeback не обов’язково остаточно вирішує всі договірні права між Покупцем і Продавцем. Окремі вимоги можуть залишатися доступними за Договором купівлі Товару та застосовним законом.
12.4 Шахрайські, дубльовані або зловживальні chargeback заборонені та можуть призвести до обмеження Акаунта або стягнення законно належних сум.
13. Комісії, валюта, податки та відрахування
13.1 Валюта і суми, які сплачує Покупець, мають бути показані до платежу. Банк Покупця або платіжний провайдер може застосувати власний валютний курс або комісію за міжнародну транзакцію, що не контролюється PRE–ORDER.
13.2 Комісії Платформи, комісії Stripe/платіжного провайдера, повернення, chargeback, резерви, податки або інші погоджені відрахування можуть впливати на суму, що зрештою виплачується Продавцю, якщо це дозволено відповідною угодою і платіжною структурою.
13.3 Продавець залишається відповідальним за свої податкові, інвойсингові та бухгалтерські обов’язки, якщо конкретний закон або письмова платіжна угода не покладає обов’язок на іншу сторону.
13.4 Транскордонні покупки також можуть передбачати імпортний ПДВ, мито, брокерські або перевізницькі збори. Це не ескроу-комісії; їх розподіл визначається Договором купівлі Товару та застосовним законом.
14. Перевірка особи, шахрайство, AML і санкційний контроль
14.1 Stripe, PRE–ORDER або інші релевантні провайдери можуть запитувати дані про особу, бізнес, бенефіціарних власників, податки, банківський рахунок, транзакцію або джерело інформації, коли це необхідно для onboarding, запобігання шахрайству, платіжної безпеки, санкцій, AML-контролю, податкової звітності або інших юридичних обов’язків.
14.2 Перевірка або risk review може затримати платіж, виплату, повернення або функцію Акаунта. Така затримка не створює ескроу-відносин.
14.3 Користувачі не повинні структурувати транзакції для обходу перевірок, неправдиво повідомляти особу чи місцезнаходження, використовувати викрадені платіжні дані, приховувати заборонену транзакцію або використовувати PRE–ORDER для переміщення коштів без реальної базової marketplace-транзакції.
14.4 Додаткова інформація наведена в AML/KYC Notice та застосовних умовах Stripe або іншого платіжного провайдера.
15. Захист коштів, safeguarding і ризик неплатоспроможності
15.1 PRE–ORDER не надає загальної обіцянки, що кошти Покупця відокремлені, safeguarded, застраховані, гарантовані або захищені від банкрутства так, ніби вони утримуються на ескроу-рахунку PRE–ORDER.
15.2 Якщо регульований платіжний провайдер зобов’язаний за законом або налаштований за договором safeguarding, segregate чи іншим чином захищати певні кошти, такий захист виникає з регуляторної та договірної структури провайдера, а не через те, що PRE–ORDER діє як ескроу-агент.
15.3 Наявність та обсяг захисту на рівні провайдера можуть залежати від платіжної послуги, юрисдикції, структури транзакції та статусу сторін. Користувачам слід покладатися на розкриття провайдера, що застосовуються до фактичного платежу, а не припускати єдину модель захисту.
15.4 PRE–ORDER не може гарантувати від неплатоспроможності або операційного збою незалежного Продавця, банку, платіжного провайдера, платіжної системи чи іншої третьої сторони. Імперативні права залишаються чинними.
16. Платіжні дані та безпека
16.1 PRE–ORDER проєктується так, щоб повні номери платіжних карток і CVV/security codes оброблялися Stripe або іншим платіжним провайдером, а не зберігалися як звичайні дані застосунку PRE–ORDER.
16.2 PRE–ORDER може зберігати ідентифікатори транзакцій, платіжний статус, суму, валюту, часові позначки, статус повернення або спору, payer/payee references та обмежені платіжні метадані, необхідні для адміністрування замовлення, підтримки, звірки, безпеки та виконання закону.
16.3 Користувачі ніколи не повинні надсилати повні дані картки, CVV-коди, паролі або секрети автентифікації через чат PRE–ORDER, support-повідомлення чи комунікацію з Продавцем.
16.4 Обробка платіжних та персональних даних додатково описана в Privacy Policy, GDPR Notice та застосовній інформації Stripe про приватність.
17. Записи Платформи та авторитетні платіжні записи
17.1 PRE–ORDER показує платіжні статуси, щоб допомогти користувачам розуміти стан замовлення, але через мережеві затримки, webhook delivery, банківську обробку або технічні інциденти може тимчасово виникати розбіжність між Платформою і зовнішньою платіжною системою.
17.2 За наявності очевидної технічної розбіжності PRE–ORDER може виправити статус Платформи на підставі авторитетного запису транзакції від Stripe, відповідного платіжного провайдера або банку.
17.3 Користувачам слід зберігати підтвердження замовлень, інвойси та платіжні записи й оперативно повідомляти про незрозуміле дубльоване списання, неправильний статус або відсутнє повернення.
18. Відсутність автоматичної програми захисту Покупця або гарантії Продавця
18.1 PRE–ORDER може надавати підтримку, маршрутизацію спорів, транзакційні записи і технічний контроль, але автоматично не надає страховий поліс, банківську гарантію, акредитив, ескроу-гарантію або універсальний фонд захисту Покупців.
18.2 Будь-яка конкретна програма захисту, функція на основі резерву, гарантія або регульований платіжний захист застосовується лише тоді, коли це прямо описано для відповідної транзакції і умови доступні до того, як користувач покладається на такий захист.
18.3 Перевірка PRE–ORDER Продавця, платіжного акаунта або транзакції зменшує певні ризики, але не є гарантією виконання Продавцем, його платоспроможності, відповідності Товару або доставки.
19. Не кредитний, не інвестиційний продукт і без відсотків
19.1 Передоплата або депозит за Товар є транзакційним платежем, а не інвестицією в PRE–ORDER або Продавця, якщо окремий регульований інвестиційний продукт прямо не передбачає інше.
19.2 PRE–ORDER не обіцяє відсотки, дохідність або фінансовий прибуток на кошти, які авторизовані, перебувають в очікуванні, зарезервовані або очікують settlement.
19.3 PRE–ORDER не надає споживчий кредит, позику чи депозитну послугу лише через те, що Товар оплачено до виробництва або доставки. Будь-який майбутній фінансовий продукт вимагатиме окремих умов і регуляторних розкриттів.
20. Транскордонні платежі та доступність
20.1 PRE–ORDER призначений для користувачів у ЄС/ЄЕЗ, Україні та інших країнах, де відповідні послуги можуть законно надаватися. Способи оплати, валюти, сервіси Stripe і функції payout можуть відрізнятися залежно від країни.
20.2 Транзакція може бути недоступною або обмеженою через покриття провайдера, санкції, юридичні обмеження, валютні обмеження, правила емітента картки, місцезнаходження Продавця або контроль ризиків.
20.3 Транскордонна обробка платежів може включати більше ніж одну юридичну особу або фінансову установу. Платіжний інтерфейс і умови провайдера, що застосовуються до транзакції, слід уважно переглянути.
21. Майбутнє запровадження регульованого ескроу або подібної послуги
21.1 У майбутньому PRE–ORDER може інтегрувати регульовану сторонню послугу ескроу, safeguarding, conditional payment або подібну послугу для окремих B2B чи інших транзакцій.
21.2 Якщо це відбудеться, PRE–ORDER не покладатиметься лише на загальне слово «ескроу». До того, як користувач буде зобов’язаний, відповідний процес має визначити постачальника послуги, пояснити його роль, зазначити істотні умови вивільнення або виплати, розкрити істотні комісії та надати посилання на умови провайдера і транзакції.
21.3 Запровадження такої послуги для одного типу транзакцій не означає, що всі платежі PRE–ORDER є ескроу-платежами.
21.4 До моменту, коли авторизована послуга прямо визначена і прийнята для конкретної транзакції, користувачі повинні розглядати стандартну платіжну функціональність PRE–ORDER як обробку й оркестрацію платежів, а не ескроу.
22. Співвідношення з іншими умовами та імперативним законом
22.1 Це Розкриття пояснює структуру платежів і термінологію. Політика платежів та передоплати регулює операційні правила платежів; Угоди з Покупцем і Продавцем регулюють відповідні ролі на Платформі; Договір купівлі Товару регулює продаж Товару.
22.2 Якщо checkout конкретної транзакції або B2B-документ містить більш конкретні законні платіжні умови, вони застосовуються до цієї транзакції тією мірою, якою узгоджуються з імперативним правом і відповідними угодами Платформи.
22.3 Ніщо в цьому Розкритті не обмежує імперативні права Споживача, законні права у сфері платежів, засоби захисту від шахрайства, chargeback-права чи інші права, які не можуть бути законно виключені.
23. Контакти та питання щодо платежів
23.1 Питання щодо платіжного статусу PRE–ORDER, інструкції на повернення або цього Розкриття можна надсилати на info@b2b–agency.cc. Вкажіть номер замовлення, дату транзакції, суму, валюту та короткий опис питання.
23.2 Не надсилайте повні номери карток, CVV/security codes, паролі акаунта або одноразові коди автентифікації електронною поштою чи в чаті.
23.3 У разі несанкціонованого платежу, проблеми з безпекою картки або банківської проблеми з транзакцією Покупець також повинен оперативно звернутися до свого банку або платіжного провайдера. Питання, специфічні для Stripe, можуть підпадати під відповідні процедури підтримки та спорів Stripe.