Skip to main content
To streamline and simplify the testing process, Yabetoo provides a set of predefined test users and test accounts. These users and accounts are pre-configured with realistic data and are associated with predefined test scenarios that simulate various use cases. This allows developers to quickly test key functionalities of the platform—such as creating payment sessions, confirming payment intents, or handling callbacks—without needing to manually configure data each time. Each test user is linked to a specific account and has preset attributes (e.g., balance, account status, transaction history) designed to cover a wide range of typical business flows. By using these predefined entities, you can ensure consistency in your test cases and accelerate the integration process.

​
How to use numbers

All tests are conducted within the sandbox environment, which is specifically designed to simulate real-world payment flows without processing actual transactions. This environment allows you to safely integrate and validate your implementation of the Yabetoo API without any financial impact. To interact with the sandbox environment, you must use test API keys. These keys are distinct from your live API keys and are intended solely for development and testing purposes. When a test API key is provided during SDK or API initialization, all requests are automatically routed to the sandbox endpoint, ensuring complete isolation from the live production system. Test API keys behave similarly to live keys, allowing you to perform all core operations such as creating payment sessions, generating payment intents, confirming transactions, and receiving webhooks—within the boundaries of the sandbox.
Important: Never use test API keys in your production application, and vice versa. Test keys are prefixed with sk_test_ for secret keys and pk_test_ for public keys.

​
Test numbers

The following test numbers are provided for the sandbox environment. Each number simulates a mobile money user with a predefined transaction outcome.
These numbers are only valid in the sandbox environment and cannot be used for real transactions.

​
Successful Transactions

These numbers simulate a successful payment flow where the transaction is completed and confirmed.

​
Failed Transactions

These numbers simulate different types of transaction failures. Use them to verify how your system responds to specific failure reasons.

​
Expired / Timeout Scenarios

These numbers simulate delayed or unresponsive transactions. They are ideal for testing time-based logic like retries or expired payment sessions.

​
Explanation of Failure message Values

The failure_message field provides additional context about the transaction outcome. Here’s a breakdown of the possible values Each test number is associated with a predefined status (succeeded, failed, or expired) and a corresponding reason. This helps simulate various real-world failure scenarios when testing payment flows in the sandbox environment.
These reasons are especially useful when testing your application’s error handling, retry logic, and user feedback.