What Are Mock PSPs?
Mock PSPs are “dumb” static responders that return the same response every time, regardless of card number, amount, or other transaction details:- NULLSuccess - Always returns successful approval
- NULLFailure - Always returns decline/failure
- Available by default to all Orchestra accounts
- Require no credentials or configuration
- Return instant responses (no network latency)
- Accept any test card, amount, or transaction data
- Building initial integration (getting started)
- Testing success/failure handling logic
- Running automated tests in CI/CD
- Demonstrating payment flows without real credentials
- Testing 3D Secure authentication (mock PSPs do not support 3DS)
- Testing specific decline codes or error scenarios
- Testing digital wallets (Apple Pay, Google Pay)
- Validating gateway-specific features
- Testing complete response structures with all gateway fields
- Preparing for production deployment
Available Mock Gateways
| Gateway Name | Behavior | Use Case |
|---|---|---|
NULLSuccess | Always approves transactions | Test happy path logic |
NULLFailure | Always declines transactions | Test error handling |
Setup
See the Quickstart for step-by-step instructions on creating mock gateway accounts in the Portal.Usage
Use mock PSPs the same way as real payment gateways - reference the account name in your API calls. See the Quickstart for complete REST API and Payments Library examples.Supported Operations
Mock PSPs support basic payment operations with success or failure responses:- Charge - Returns instant success or failure
- Authorize/Capture - Returns instant success or failure
- Refund - Returns instant success or failure
- Void - Returns instant success or failure
- Tokenize - Returns instant success or failure
Limitations
Mock PSPs are designed for basic integration testing. They have several important limitations compared to real payment provider sandboxes:Static Responses Only
Mock PSPs return predetermined success or failure responses regardless of input. They cannot:- Simulate specific decline codes or error scenarios
- Vary responses based on transaction amount or card details
- Test edge cases or gateway-specific behaviors
No 3D Secure Support
Mock PSPs do not support 3D Secure authentication flows. This is particularly important for Payments Library integrations: How 3DS Works in Orchestra:- REST API: You handle 3DS authentication externally and pass the results to Orchestra, which forwards them to the PSP
- Payments Library: Orchestra performs 3DS authentication by contacting a real 3DS provider
- In the Payments Library, the selected payment gateway (UPG) determines whether 3DS is attempted
- Mock PSPs don’t provide 3DS data, so the 3DS authentication process is never initiated
- Even 3DS test cards that would normally trigger authentication won’t activate 3DS flows with mock PSPs
1
Choose a Compatible PSP
Select a PSP with 3DS-enabled sandbox (e.g., NMI, Stripe, Adyen)
2
Understand Test Card Requirements
You’re dealing with two sandbox environments:
- 3DS provider sandbox - Has its own set of test cards
- PSP sandbox - Has its own set of test cards
3
Find Compatible Cards
Some PSPs (like NMI) accept the 3DS provider’s test cards, enabling full 3DS testing. Check with your PSP’s documentation.
3DS testing limitations only affect sandbox environments. Production accounts with live PSP connections handle 3DS normally.
Other Limitations
- Digital wallets: Mock PSPs don’t support Apple Pay, Google Pay, or PayPal
- Network tokenization: Not available with mock PSPs
- Gateway-specific features: PSP-specific functionality (fraud tools, installments, etc.) is unavailable
Test Data
Mock PSPs accept any test data (card numbers, amounts, expiration dates, CVV) since they return static responses regardless of input. The response depends only on which gateway you use (NULLSuccess or NULLFailure), not on the transaction details.Graduating to Real Providers
When you’re ready to process real transactions, add a payment provider to Orchestra, then change the gateway account name in your API calls:Best Practices
Start with Mocks
Use mock PSPs for initial development. They’re instant and require no external accounts.
Test with Real Providers Early
Switch to real provider sandboxes before production to catch integration issues.
Don't Mix in Production
Never use mock PSPs in production. They don’t process real transactions.
Automate with Mocks
Use mock PSPs in CI/CD pipelines for fast, reliable test runs.