Безпека Checkout

Tapaya забезпечує поля картки, токенізацію, автентифікацію картки та стягнення оплати, тому ваші системи ніколи не працюють з необробленими даними картки. За вами залишається сервер, який створює платежі й вирішує, коли замовлення оплачено. Ці правила стосуються як Hosted Checkout, так і вбудованих платежів.

Про те, як Tapaya обробляє дані власників карток і персональні дані, див. Захист даних і конфіденційність.

Зберігайте ключі на сервері

• Зберігайте checkout-ключ мерчанта або Secret key організації лише в серверній конфігурації. Жодному з них не місце в коді браузера, пакетах мобільних застосунків чи системі контролю версій. До браузера потрапляють лише publishable key і client secret платежу.
• Викликайте Checkout API мерчанта зі свого серверного середовища. Не виконуйте ці запити в браузері клієнта.
• Checkout-ключ мерчанта має доступ лише до свого мерчанта. Передавайте власному бекенду мерчанта саме цей ключ, ніколи не Secret key вашої організації.
• Secret key організації має повноваження в межах усієї організації. У режимі платформи надсилайте його разом із X-Tapaya-Merchant-Token у кожному запиті; API перевіряє, що мерчант належить до організації цього ключа. Див. автентифікацію Checkout.
• Ключі мерчанта показуються один раз і зберігаються лише у вигляді хешу. Відкликайте ключ, який, на вашу думку, міг бути розкритий, після того як створите йому заміну.

Керуйте замовленням на своєму сервері

• Обчислюйте суму замовлення на своєму сервері та зберігайте замовлення до створення сесії або спроби платежу.
• Беріть суми, валюту та ID замовлень зі збереженого знімка замовлення. Не приймайте замінні значення, надіслані браузером.
• Для вбудованих платежів прив'яжіть свої ендпоінти prepare і submit до оформлення замовлення з автентифікацією користувача або до підписаного HTTP-only cookie та перевіряйте origin запитів, що змінюють дані.

Перевіряйте платіж перед виконанням замовлення

Переспрямування браузера, відвідування вашого URL успіху, параметри запиту, cookie повернення та повідомлення браузера є навігаційними даними. Жодне з них не доводить оплату.

• Отримайте сесію на своєму сервері та порівняйте її референс замовлення, суму, валюту та статус платежу зі збереженим замовленням.
• Виконуйте замовлення лише тоді, коли ця перевірка підтверджує paymentStatus: successful. Сама лише відповідь HTTP 200 не доводить оплату.
• Записуйте виконання замовлення атомарно, щоб повторні повернення чи перевірки статусу не могли виконати те саме замовлення двічі.
• Якщо сесія все ще має статус unpaid або отримати її не вдається, збережіть ID сесії та перевірте знову з обмеженою кількістю повторних спроб. Не створюйте іншу сесію через те, що перший результат невідомий: нова сесія для замовлення замінює стару. Вебхуків поки немає, тому проводьте звірку опитуванням (polling).

Безпечні повторні спроби

• Перед створенням сесії збережіть разом із замовленням унікальний idempotency key. Якщо запит завершився тайм-аутом або його відповідь втрачено, повторіть його з тим самим ключем і незмінним тілом.
• Не генеруйте новий ключ через невизначений результат. Правила повторного відтворення відповідей див. у розділі Ідемпотентність і помилки.

Обмежте origin для переспрямування

• Додавайте до Allowed websites у налаштуваннях Checkout лише origin власних магазинів.
• Використовуйте HTTPS для розгорнутих магазинів. Перевизначення successUrl і cancelUrl для окремих сесій усе одно мають відповідати налаштованому origin.

Повідомлення про проблему безпеки

Якщо ви підозрюєте вразливість або інцидент безпеки, зверніться до команди безпеки, як описано в розділі Контакти.