Skip to main content
Orchestra provides two mock payment gateways for testing: NULLSuccess always approves transactions, NULLFailure always declines them. This lets you test both success and failure handling in your integration without external accounts.

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
This predictability lets you reliably test both code paths in your integration. No actual payment processing occurs - mock PSPs simply return instant, static responses so you can verify your application handles success and failure correctly. Key characteristics:
  • 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
Use mock PSPs when:
  • Building initial integration (getting started)
  • Testing success/failure handling logic
  • Running automated tests in CI/CD
  • Demonstrating payment flows without real credentials
Use real provider sandboxes when:
  • 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 NameBehaviorUse Case
NULLSuccessAlways approves transactionsTest happy path logic
NULLFailureAlways declines transactionsTest 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
All operations return instant, static responses without network latency or actual processing. The response you receive depends solely on which mock gateway you use (NULLSuccess or NULLFailure), not on the transaction details you submit.

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
Why Mock PSPs Don’t Support 3DS:
  • 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
Testing 3DS in Sandbox: To test 3DS authentication in sandbox environments, use a real PSP sandbox account that supports 3DS:
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
These test card sets usually don’t overlap.
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
AWAITING STAKEHOLDER CLARIFICATION: Do mock PSP responses populate all response fields that real PSPs return (gateway codes, transaction IDs, metadata), or only basic success/failure status?Action requested: Provide actual response examples from both a real PSP and mock PSPs for comparison.

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:
// Before (mock)
paymentGatewayAccountName: 'test-success'

// After (real provider)
paymentGatewayAccountName: 'your-provider-name'
Everything else in your code stays the same.

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.