Sandbox

Try every outcome of Trida Platform (a payment that fails, a message that is not delivered) without a real provider, without an account at a third party and without money. The sandbox is deterministic: the same input gives the same outcome every time, so your tests can be replayed.

Test keys and live keys

An API key starts with its mode: tp_test_... or tp_live_....

Key	Where it works	What it reaches
`tp_test_...`	any project	the fake providers of this page, always, even in production. No network call to a third party.
`tp_live_...`	a project in live mode only	the real providers

A project in test mode is a sandbox: it only takes tp_test_ keys. Asking the administration for a live key on it is refused, and the database refuses it too.
A tp_live_ key used on a project that is (or became) a test project answers 401 API_KEY_INVALID with a message that says so: it never reaches a real provider from the sandbox.
A live project can also hold tp_test_ keys, to try things on its own sandbox.

How the scenarios work

The data drives the scenario: you do not configure the fake, you send a value and the fake answers the way the table says. Rules are tried in the order of the table, the first one that matches wins, and a value that matches no rule takes the happy path. Nothing is random and nothing depends on the clock or on the previous call.

The same conventions apply to every capability:

Rule	Where it applies	Outcome
`amount` is exactly `1001`	Pay	the intent goes `failed` with the reason `card_declined`
`amount` is exactly `1002`	Pay	the intent goes `requires_action` (strong authentication)
the phone number ends with `00`	Notify (WhatsApp, SMS)	the message is not delivered (`unreachable`)
the e-mail local part is `bounce`	Notify (e-mail)	the message bounces (`bounced`)
anything else	all	success

Status: the framework exists, the capabilities do not yet. The scenario engine (createFakeProvider, in apps/platform-api/src/platform/providers/), the choice between fake and real by key mode (selectProvider), and the mode rules above are built and tested. Pay, Notify and the others do not exist yet: each row of the table above becomes real when its capability ships, with the same rule and the same outcome, and this page is updated with it. Until then, a tp_test_ key cannot create an intent or send a message because those routes are not there.

Writing a fake (for platform contributors)

A capability that talks to a third party ships a fake with the real adapter, never after it:

const payments = createFakeProvider<{ amount: number }, Outcome>({
  name: 'pay',
  scenarios: [
    {
      id: 'amount-1001-fails',
      when: 'the amount is 1001',
      then: 'failed, card_declined',
      matches: when.amountIs(1001),
      outcome: () => ({ status: 'failed', reason: 'card_declined' }),
    },
  ],
  fallback: () => ({ status: 'succeeded' }),
});
const provider = selectProvider(
  { keyMode, projectMode },
  { fake: payments, real: payDunya.createInvoice },
);

Deterministic and without network: a fake never calls fetch; its test cuts the network to prove it.
Self-documenting: describe() lists every rule in order, so this page cannot say something the code does not.
The choice is made in one place: selectProvider decides from the key mode, never the adapter. A test key always gets the fake, even when the real adapter is connected; a live key on a test project is refused.