Skip to main content
This page applies to both the REST API and Payments Library.
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 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 card data, amount, or transaction details
  • Return responses in the same format as real PSPs
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
  • Testing Apple Pay and Google Pay integrations
  • Testing with network tokens
Use real provider sandboxes when:
  • Testing 3D Secure authentication with the Payments Library
  • Testing specific decline codes or error scenarios
  • Testing gateway tokenization
  • Validating gateway-specific features (fraud tools, installments, etc.)
  • 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 the following payment operations:
  • 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
All operations return instant, static responses. The response you receive depends solely on which mock gateway you use (NULLSuccess or NULLFailure), not on the transaction details you submit.
Mock PSPs do not support gateway tokenization operations. To test gateway tokenization, use a real PSP sandbox account.

​
Response Format

Mock PSPs return responses in the same format as real PSPs, with mock data populated in all fields. This allows you to build and test your response handling logic before connecting to real payment providers. Example NULLSuccess response: 
{
  "authorizationCode": "fbbb8b",
  "currency": "USD",
  "amount": 2.56,
  "operationType": "Charge",
  "operationResultCode": "Success",
  "operationResultDescription": "Successful operation",
  "gatewayName": "NULLSuccess",
  "gatewayReference": "b362db",
  "gatewayResultCode": "OK",
  "gatewayResultDescription": "Gateway says: Successful operation",
  "gatewayResultSubCode": null,
  "gatewayResultSubDescription": null
}

​
Digital Wallets (Apple Pay & Google Pay)

Mock PSPs fully support Apple Pay and Google Pay testing. When Orchestra receives an encrypted wallet payload, it extracts the virtual card details and sends them to the PSP as a regular card transaction. Since mock PSPs accept any card data, wallet transactions work seamlessly.

​
Network Tokens

Mock PSPs accept network tokens without any special handling. Network tokens use the standard PAN format, so they’re processed the same as regular card numbers.

​
3D Secure Behavior

How 3DS works with mock PSPs depends on whether you’re using the REST API or the Payments Library:

​
REST API

With the REST API, you handle 3DS authentication externally and pass the authentication results to Orchestra inline with the card details. Mock PSPs accept this 3DS data and respond with their static response (success or failure). This allows you to test your 3DS data handling logic.

​
Payments Library

With the Payments Library, 3DS authentication is triggered at the point of card entry. Whether 3DS is attempted depends on:
  1. The customer has enabled 3DS in their CardPay eWallet configuration
  2. The PSP integration supports passing 3DS data
The mock PSP integration does not support passing 3DS data. Therefore, when using the Payments Library with a mock PSP, 3DS authentication will not be triggered, even if the customer has 3DS enabled.
To test 3DS flows with the Payments Library, use a real PSP sandbox account that supports 3DS. See 3D Secure Integrations for a complete list of supported PSPs.

​
Limitations

Mock PSPs are designed for integration testing. They have several 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. However, you can use them to:
  • Verify your system handles success correctly (NULLSuccess)
  • Verify your system handles failure correctly (NULLFailure)
  • Design decision trees based on the consistent error format returned

​
Gateway Tokenization

Mock PSPs do not support gateway tokenization operations. To test creating and using gateway tokens, use a real PSP sandbox account.

​
Gateway-Specific Features

PSP-specific functionality (fraud tools, installments, recurring billing setup, etc.) is not available with mock PSPs.

​
Test Data

Mock PSPs accept any card data: test cards, real card numbers, any amount, any expiration date, any CVV. The response depends only on which gateway you use (NULLSuccess or NULLFailure), not on the transaction details. This means you can use whatever test data is convenient for your development workflow.

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

Quickstart

Get started with mock PSPs in 5 minutes

Add Payment Provider

Connect real gateways

Testing & Going Live

Sandbox vs production environments

Gateway Accounts API

Manage gateway accounts programmatically