Skip to main content
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. Source: Silverflow 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. 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. 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 or Payment failure. 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 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

1

Successful Payment

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.
2

Terminal decline

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.
3

3D Secure

Exercise the 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.
4

Idempotency

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.
5

Refunds

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.
6

Payouts

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.
7

Request failures

Exercise invalid authentication, malformed JSON, invalid fields, idempotency conflicts, and a safe transient retry. Preserve Request-Id without recording sensitive request data.
8

Webhooks

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.

​
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.