Payment Orchestrator

Тема

05.16 Test Provider And Sandbox ​

Статус: черновик для обсуждения

1. Назначение документа ​

Этот документ описывает product requirements для test provider / sandbox flow в MVP.

Test provider нужен, чтобы:

  • проверять deposit flow до live traffic;
  • давать merchant возможность протестировать integration;
  • проверять hosted payment URL flow;
  • проверять callbacks;
  • проверять merchant webhooks;
  • проверять статусы;
  • проверять provider error/timeout handling;
  • использовать sandbox flow в public merchant documentation.

2. Core requirement ​

В MVP нужен test provider.

Test provider должен поддерживать все MVP payment methods.

MVP methods:

  • Cards;
  • Apple Pay;
  • Google Pay;
  • Sofort Uber;
  • BLIK;
  • Skrill;
  • Quick Checkout.

Test provider должен быть реализован как provider adapter / integration в рамках проекта.

Он должен проходить через те же основные execution mechanisms, что и real providers:

  • SUB MID / SUB MID AGGREGATOR configuration;
  • routing;
  • hosted payment URL;
  • provider response;
  • provider callback;
  • status mapping;
  • merchant webhook;
  • timeline;
  • transaction list/details.

3. Supported statuses ​

Test provider должен уметь симулировать:

  • PROCESSING;
  • COMPLETED;
  • FAILED;
  • CANCELED;
  • REJECTED.

Test provider должен позволять выбрать expected test result.

Exact control mechanism может быть выбран development/QA team:

  • test amount;
  • test card;
  • test parameter;
  • test provider hosted page option;
  • another explicit sandbox control.

Product requirement:

text
Merchant/admin must be able to intentionally trigger supported test outcomes.

4. Error and timeout simulation ​

Test provider должен уметь симулировать:

  • provider timeout;
  • provider error response.

Эти scenarios нужны для:

  • routing fallback validation;
  • error mapping validation;
  • timeline investigation;
  • merchant webhook error payload validation;
  • support/demo scenarios.

5. What test provider does not need to simulate directly ​

В MVP test provider не обязан иметь special built-in controls для:

  • duplicate callback;
  • ignored callback / unknown status;
  • amount/currency mismatch;
  • invalid signature callback.

Эти scenarios можно проверять на уровне automated/integration tests.

Product requirement:

text
Duplicate/ignored/mismatch/invalid-signature callback scenarios are required tests,
but do not need dedicated merchant-facing test provider controls in MVP.

6. Hosted redirect URL ​

Test provider должен возвращать hosted redirect URL.

Даже если внутри это fake/sandbox page, customer/merchant test flow должен проходить через redirect-based hosted flow.

Reason:

  • real provider flows often redirect customer;
  • hosted payment form behavior must be tested realistically;
  • merchant documentation should describe the same conceptual flow as live integration.

7. Who can use sandbox/test flow ​

Sandbox/test provider flow должен быть доступен:

  • platform users;
  • merchant users;
  • merchants integrating through Merchant API.

Sandbox/test flow работает внутри stg.

Отдельный sandbox environment в MVP не нужен.

Test provider также доступен в prod.

В prod test provider доступен всем merchants.

Access still depends on:

  • environment;
  • API key;
  • merchant/payment configuration;
  • permissions in Back Office;
  • provider/test provider access rules, if implemented.

8. Test transaction marker ​

Transactions created through test provider / sandbox flow must be marked as:

text
test = true

Transaction list and transaction details must clearly show test marker/badge.

Test marker must be available for:

  • filtering;
  • investigation;
  • export, if user has access to the field;
  • support/ops clarity.

9. Transaction list and webhooks ​

Test transactions must appear in normal transaction list.

Test transactions must have normal transaction details and timeline.

Test transactions must send merchant webhooks.

Webhook payload should follow the normal merchant webhook schema.

If needed, test marker visibility in webhook payload should be defined separately.

Product decision for MVP:

text
Test transaction goes through normal webhook delivery.

10. Velocity, fees and turnover ​

Test transactions can participate in:

  • velocity limits;
  • FX / conversion calculations;
  • conversion fee;
  • processing fee;
  • MASTER MID turnover;
  • routing fallback;
  • webhook retry.

This is allowed because test flow may be used specifically to validate these mechanisms.

Important:

text
Test transaction behavior depends on the test context/configuration.

If team later needs test transactions excluded from financial/reporting aggregates, it must be described as a separate reporting/accounting requirement.

11. Merchant documentation ​

Public merchant documentation must describe sandbox/test provider flow.

Documentation must explain:

  • how merchant creates a test deposit;
  • how merchant chooses/simulates expected test status;
  • how hosted redirect URL behaves;
  • which statuses can be tested;
  • how merchant receives webhook for test transaction;
  • how to validate webhook signature in sandbox;
  • whether test transactions are visible in Back Office.

12. Testing requirements ​

Automated/manual test plan must cover:

  • successful test provider deposit;
  • PROCESSING status;
  • COMPLETED status;
  • FAILED status;
  • CANCELED status;
  • REJECTED status;
  • provider timeout simulation;
  • provider error simulation;
  • hosted redirect URL returned by test provider;
  • merchant webhook sent for test transaction;
  • test marker visible in Back Office;
  • test transaction visible in transaction list/details;
  • test transaction interaction with velocity/fee/turnover where configured.

Duplicate callback, ignored callback, amount/currency mismatch and invalid signature callback are still required tests, but can be executed through test tooling rather than test provider UI/control.

13. Acceptance Criteria ​

Test Provider And Sandbox считаются согласованными для MVP, если:

  • Test provider exists in MVP.
  • Test provider supports all MVP payment methods.
  • Test provider can simulate PROCESSING.
  • Test provider can simulate COMPLETED.
  • Test provider can simulate FAILED.
  • Test provider can simulate CANCELED.
  • Test provider can simulate REJECTED.
  • Test provider can simulate provider timeout.
  • Test provider can simulate provider error response.
  • Test provider returns hosted redirect URL.
  • Merchant/admin can intentionally choose/simulate expected test outcome.
  • Sandbox/test flow is available to platform users.
  • Sandbox/test flow is available to merchant users.
  • Sandbox/test flow is available through Merchant API.
  • Sandbox/test flow works inside stg.
  • Separate sandbox environment is not required.
  • Test provider is available in prod.
  • Test provider in prod is available to all merchants.
  • Test transactions are marked as test.
  • Test marker is visible in transaction list/details.
  • Test transactions appear in normal transaction list.
  • Test transactions send merchant webhooks.
  • Test transactions can participate in velocity/fees/turnover in test context.
  • Duplicate/ignored/mismatch/invalid-signature callback scenarios are required tests but do not require dedicated test provider controls in MVP.
  • Public merchant documentation describes sandbox/test provider flow.

14. Open Questions ​

Product open questions отсутствуют.

Technical/QA follow-up:

  1. Development/QA team должна определить exact test outcome control mechanism.
  2. Development team должна определить technical implementation of hosted redirect URL for test provider.
  3. Development/QA team должна определить how timeout/error simulation is triggered.
  4. Development team должна определить exact provider adapter name/identifier for test provider.
  5. Development team должна определить whether test marker is included in webhook payload or only Back Office/data model.