> ## Documentation Index > Fetch the complete documentation index at: https://docs.flowlix.eu/llms.txt > Use this file to discover all available pages before exploring further. # Sandbox testing > Verify payment, refund, payout, retry, and failure handling without moving real money Sandbox requests create test objects and move no real money. Use your Sandbox secret key and test data for your account's payment processor. ## Test cards For accounts using Silverflow Sandbox processing, the examples below are constructed from Silverflow's published 3DS ranges. They have valid Luhn check digits; Silverflow publishes the ranges, not these individual examples. | Network | 3DS prefix | Length | Example test number | | ---------- | ---------------- | ------ | ------------------- | | Visa | `46354400000022` | 16 | `4635440000002207` | | Mastercard | `55203300000022` | 16 | `5520330000002205` | Source: [Silverflow Sandbox](https://docs.silverflow.com/guides/sandbox). These are 3DS test ranges, not a Payout eligibility list or a guarantee of successful payment. Use account-specific test data for other processing routes. For Hosted Payment Page, enter card data only in the hosted form. For Direct API, submit it only from your PCI-compliant Sandbox backend using `payment_method_data.card`. Supply the other required card fields as described in the [Direct API guide](/guides/direct-api). Request examples are not universal expiry/CVC test fixtures. Never copy a card request body into logs, screenshots, issue trackers, or support messages. ## 3D Secure cases The following are Silverflow's documented authentication scenarios for its Sandbox, not promised Flowlix response statuses. Use a card from the ranges above and test one condition at a time. | Input | Silverflow authentication scenario | | ------------------------------------------------------- | --------------------------------------------- | | `amount: 2500` (below `3000`), ordinary cardholder name | Frictionless, unless a challenge is requested | | `amount: 5000` (above `3000`), ordinary cardholder name | Challenge | | Cardholder name `fake` | Unauthenticated | | Cardholder name `error` | Provider HTTP `500` | Amounts are minor units: `2500` EUR means €25.00. For Direct API, the name field is `payment_method_data.card.holder_name`; do not substitute billing names. Silverflow does not define the outcome at exactly `3000`. Its `challengeIndicator: challenge-preferred` also selects a challenge, but `challengeIndicator` is not a Flowlix request field. Account processing settings can affect which flow you observe. Use instructions on the authentication page; there is no universal test OTP specified in the linked catalogue. A provider HTTP `500` is not a promise of Flowlix HTTP `500`. Handle the actual [request error](/guides/errors) or [Payment failure](/guides/operation-failures). For each different scenario, create a new Payment with a new `Idempotency-Key`. When the Payment is `REQUIRES_ACTION`, follow the latest `next_action.redirect_url`, including any browser action before a challenge. [Frictionless and challenge](https://docs.silverflow.com/guides/3d-secure) are both authentication flows; a completed authentication is not proof of payment. Retrieve the Payment and fulfil only on `SUCCEEDED`, never on `return_url` alone. ## Verification checklist When your supplied test data includes a successful scenario, complete one HPP or Direct Payment and retrieve it until `SUCCEEDED`. Confirm your order is fulfilled only after that API status. When a decline scenario is available, confirm that your checkout branches on `failure_code`, shows neutral customer copy, and creates a new Payment for another attempt. Exercise the [3D Secure cases](#3d-secure-cases). Confirm that both frictionless and challenge handling use the returned Payment status, not the presence or absence of a challenge screen, to decide fulfilment. Retry with the same key and an equivalent effective request identity, then change a non-card field such as `merchant_reference` while retaining the key. Confirm replay and `idempotency_key_reused` handling without recording card data. Create a partial Refund and retrieve the parent Payment until that Refund is `SUCCEEDED` or `FAILED`. Only after `SUCCEEDED`, retrieve the Payment again, read the latest `amount_refundable`, and create a remaining Refund when the business still intends to return that amount. If the Refund is `FAILED`, do not automatically issue another one; follow the [Refund failure procedure](/guides/operation-failures#refund-failures). Submit one test Payout, retrieve it by ID, and locate it in the paginated Payout list. Keep `PENDING` and `PROCESSING` nonterminal; track `SUCCEEDED` or `FAILED` through retrieval and payout events. For `FAILED`, handle `failure_code` and `failure_message` without an automatic retry. A repeated creation can return its original response, so use GET for the latest state. See the [Payout guide](/guides/payouts). Exercise invalid authentication, malformed JSON, invalid fields, idempotency conflicts, and a safe transient retry. Preserve `Request-Id` without recording sensitive request data. Create a Sandbox endpoint and subscribe to the Payment and Refund events you handle. Verify a real delivery, persist it before acknowledging, and confirm that repeating the same Event ID does not repeat fulfilment. Locally test altered payloads, an incorrect signing secret, and stale timestamps; these must fail signature verification. See [Webhooks](/guides/webhooks). ## Keep test evidence safe Record operation, HTTP status, object status, machine-readable error code, and `Request-Id`. Do not record a secret key, `Authorization` header, PAN, CVC, full request body, or provider response.