Контрольний список QA

Пройдіть цей контрольний список у пісочниці (sandbox), а перед прийомом реальних платежів виконайте перевірки для робочого середовища. Список охоплює результати платежів, верифікацію, повторні спроби, конфігурацію та безпеку. Позначайте кожну перевірку, щойно її виконаєте.

1. Результати платежів

Успішний платіжPO-1Оплатіть карткою 4242 4242 4242 4242. Отримана сесія має paymentStatus: successful, а замовлення виконується рівно один раз. Відхилена карткаPO-2Оплатіть карткою 4916 0184 7581 4056. Замовлення залишається неоплаченим, а повторна спроба з карткою для успішного платежу спрацьовує, поки сесія відкрита. 3-D SecurePO-3Оплатіть карткою 4012 0018 0000 0016 і пройдіть перевірку (challenge). Виконання замовлення чекає на отриманий статус. Помилка обробкиPO-4Використайте тестову картку з помилкою обробки для тестового платіжного шлюзу. Замовлення залишається неоплаченим, хоча форма картки прийняла картку. Необроблені станиPO-5Ваш код вважає unpaid, failed, action_needed, cancelled і невідомі значення неоплаченими. Див. Статус платежу.

2. Верифікація та виконання замовлення

Перевірка на серверіVF-1Під час виконання замовлення референс замовлення, сума, валюта та paymentStatus порівнюються зі збереженим замовленням, а не з даними переспрямування. URL успіху без оплатиVF-2Відкрийте URL успіху напряму, не оплачуючи. Замовлення залишається неоплаченим. Посилання для скасуванняVF-3Перейдіть за посиланням для скасування в Checkout. Замовлення залишається неоплаченим, а ваш код не робить висновку про статус cancelled лише на підставі самої навігації. Повторне поверненняVF-4Після успішного платежу двічі перезавантажте сторінку повернення. Замовлення виконується рівно один раз.

3. Повторні спроби та переривання

Для кожного незалежного випадку використовуйте нове тестове замовлення та нову сесію. Для тестів повторних спроб повторно використовуйте початкове замовлення, тіло запиту та idempotency key.

Втрачена відповідь на створенняRI-1У своєму тестовому коді відкиньте відповідь на створення та повторіть запит з тим самим Idempotency-Key і тілом. Повертається початкова сесія, а друга не створюється. Змінене тілоRI-2Повторно використайте ключ з іншим тілом. API повертає HTTP 409, і ваш код не вважає це новою сесією. Клієнт не повертаєтьсяRI-3Оплатіть, а потім закрийте вкладку до повернення. Ваше завдання звірки отримує збережену сесію та записує платіж рівно один раз. Тайм-аут статусуRI-4Змусьте отримання статусу завершитися тайм-аутом. Ваш застосунок зберігає ID сесії, залишає результат невизначеним і не створює сесію на заміну. Замінена сесіяRI-6Створіть другу сесію для того самого неоплаченого замовлення. Перша URL-адреса повідомляє expired і не може прийняти оплату. Після оплати замовлення створення ще однієї сесії повертає HTTP 409. Закінчення терміну дії сесіїRI-5Дочекайтеся, поки мине expiresAt (30 хвилин), і знову відкрийте URL. Новий платіж розпочати неможливо, а замовлення залишається неоплаченим.

4. Налаштування Checkout

Мерчант схваленийCS-1Кожен мерчант, для якого ви приймаєте платежі, є в таблиці Checkout merchants зі статусом Ready. Адреси поверненняCS-2Типові URL успіху та скасування задано для облікових даних, які ви використовуєте (типові значення організації для Secret key, налаштування мерчанта для ключа мерчанта), вони використовують HTTPS, а їхні точні origin указано в Allowed websites цих облікових даних. Перевизначення для окремих сесійCS-3Кожен successUrl або cancelUrl, який ви надсилаєте, відповідає налаштованому origin. ГаманціCS-4Apple Pay і Google Pay увімкнено або вимкнено так, як задумано. Для Google Pay у робочому режимі налаштовано Google Pay merchant ID. Гаманці у вбудованих платежахCS-6Сума в гаманці відповідає замовленню на сервері. Зміна доставки чи знижок оновлює її. Скасування в гаманці залишає оформлення замовлення доступним, а платежі в очікуванні блокують повторне стягнення оплати. БрендингCS-5Колір і логотип виглядають правильно в Checkout preview як у макеті для комп'ютера, так і в мобільному.

5. Безпека

Ключ на серверіSE-1Ваш checkout-ключ мерчанта або Secret key організації є лише в конфігурації сервера, ніколи в коді браузера, пакетах застосунків чи системі контролю версій. Суми визначає серверSE-2Сума, валюта та ID замовлення беруться з вашого збереженого замовлення, ніколи з браузера. Ендпоінти вбудованих платежівSE-3Якщо ви використовуєте вбудовані платежі, prepare і submit прив'язані до оформлення замовлення з автентифікацією користувача або до підписаного HTTP-only cookie, а origin запитів, що змінюють дані, перевіряються. Content Security PolicySE-4Якщо ви використовуєте вбудовані платежі, ваша CSP дозволяє origin скриптів і фреймів Tapaya, а перевірки 3-D Secure за неї й далі працюють.

6. Конфігурація пісочниці

API пісочниціPR-1TAPAYA_CHECKOUT_API_URL вказує на https://api.sandbox.tapaya.com. Ключ пісочниціPR-2Інтеграція використовує checkout-ключ мерчанта або Secret key організації для пісочниці, завантажений з конфігурації сервера. Завдання звіркиPR-3Завдання, яке отримує невизначені сесії, заплановано у вашому тестовому середовищі.

7. Готовність до робочого середовища

Готовність мерчантаLV-1Мерчант у робочому режимі пройшов онбординг з онлайн-платежами, отримав схвалення платіжного процесора та має налаштований платіжний шлюз. У налаштуваннях Checkout мерчант має статус Ready. Облікові дані робочого режимуLV-2Сервер використовує облікові дані робочого середовища та https://api.tapaya.com. Інтеграції через SDK задають TAPAYA_ENVIRONMENT=production. Ключі пісочниці та тестові картки не використовуються для реальних платежів. Гаманці в робочому режиміLV-3Домени магазинів для Apple Pay активні. Для Google Pay у робочому режимі налаштовано merchant ID. Підтримувані гаманці завершують платіж і відновлюються після скасування. Звірка в робочому режиміLV-4URL повернення для робочого середовища, перевірка на сервері, виконання замовлень і завдання звірки використовують конфігурацію робочого середовища. Чогось бракує на цій сторінці?Надішліть запит на функцію. Ми додамо цю сторінку, щоб команда бачила контекст.