Testing financial integrations can be challenging. You’ve written the code, mocked the responses, and unit tested everything. But when it’s time to test the real flow where actual money changes hands, you need confidence in your implementation.
Payment testing requires careful attention to avoid unintended charges or disruptions to live systems.
Why most sandbox environments fall short
Many payment sandboxes have limitations that make testing difficult. They’re often slow, use unrealistic test data, and can be unreliable.
Additionally, many require separate accounts, different URLs, and completely different integration patterns. This means you end up testing one implementation while shipping another.
How sandbox mode should actually work
Open your Bias dashboard. See that environment selector in the top left? Click it. You just switched from production to sandbox. Same interface, same API, same everything, just with test data.
Your sandbox is yours. Not shared with other developers, not cluttered with someone else’s test transactions. When you create a sandbox, you get a clean environment that behaves exactly like production but with zero real-world consequences.
Each sandbox comes with its own set of API keys prefixed with sk_test_. These keys scope every request to your sandbox environment. Same code, same endpoints, same responses, but completely isolated from production. No environment variables to remember, no special configuration. Just swap the key and you’re testing safely.
// Production
const bias = new Bias({
apiKey: 'sk_live_1ydvNDuNmnjOt1kBVJAU2MCTm2sxMQkdRLy6Kbxx',
});
// Sandbox (same code, different key)
const bias = new Bias({
apiKey: 'sk_test_OTyK6RQLNkbkyumx2dmCUABnMtj21MyDxxJsdNVv',
});The isolation is complete. Your sandbox webhooks won’t trigger production fulfillment. Your test disputes won’t show up in live reporting. Your development testing won’t charge real cards.
The scenarios that matter
Sandbox testing goes beyond checking if payments work. You need to test your entire flow comprehensively.
Success cases: Test that payments work, including edge cases. What happens when a payment succeeds but takes 30 seconds to process? What about authorization-only scenarios where you capture the payment later? Your sandbox can simulate these timing scenarios.
Failure modes: Use test cards that trigger specific decline reasons. 4000 0000 0000 0002 is a generic decline. 4000 0000 0000 0259 creates a disputed payment. Check our documentation for a complete list of test cards.
Interactive flows: If you’re using checkout sessions, test them thoroughly. Different browsers, payment methods, currencies. Mobile vs desktop. The sandbox handles all of this exactly like production.
// Test different failure scenarios
const testCards = {
success: '4242 4242 4242 4242',
insufficientFunds: '4000 0000 0000 9995',
expired: '4000 0000 0000 0069',
disputeFraud: '4000 0000 0000 0259',
};
const payment = await bias.payments.create({
amount: 1000,
payment_method: {
card: {
number: testCards.success,
exp_month: 12,
exp_year: 2030,
cvc: 123,
},
},
});Beyond manual testing
Once you’ve verified the basics manually, sandbox mode becomes your automation platform.
CI/CD Integration: Point your integration tests at sandbox and run them on every deploy. This prevents payment bugs from reaching production.
Load Testing: Need to know how your system handles 1000 concurrent payments? Your sandbox can handle the load without processing fees.
Onboarding: New team members can experiment safely without concerns about test charges.
The key insight: when testing is frictionless, you test more. When you can simulate edge cases easily, you handle them properly in your code.
The confidence factor
A proper sandbox environment changes how you approach deployments. Instead of hoping your payment integration works, you know it works. You’ve tested every scenario, handled every edge case, verified every webhook. When you switch to production, it’s straightforward.
The most successful payment integrations are invisible. Customers don’t think about them because they just work. Sandbox mode helps you build that kind of reliability.
Start testing better
Ready to improve your payment testing? Open your Bias dashboard, click the environment selector, and create your first sandbox. Same interface, same API, zero consequences.
Test the happy path, then test everything else. Simulate failures on purpose. Load test. Your production environment will benefit.
Want to dive deeper into testing best practices? Check out our testing guide for more information on sandbox mode as well as a list of test card numbers and payment methods.