Use provider test credentials
Each gateway controls its own sandbox account, credentials, test data, supported simulations, and environment limitations.
Non-production payment testing
Payment Sandbox Mode in CMS Max
Test the real provider integration against its test environment without pretending a dummy payment proves production readiness.
Sandbox Payment is not a standalone payment provider in the current CMS Max architecture. The historic plugin setting maps into the shared payment sandbox mode, which selects test endpoints for configured native gateways such as Authorize.Net, CardPointe, and Paya where supported.
- Shared environment mode
- Provider test credentials
- No real fulfillment
- Controlled live cutover
Current support boundary
Sandbox mode and a sandbox provider account must agree.
Do not mix production credentials with test endpoints, test credentials with production endpoints, or provider test cards with live customer data. Label the environment visibly for staff and prevent test orders or submissions from triggering real fulfillment, service, accounting, or customer communication.
Separate downstream effects
Suppress or clearly route fulfillment, inventory, tax, email, shipping, CRM, webhooks, accounting, and reporting actions created by payment tests.
Require production acceptance
A sandbox pass does not prove live credentials, underwriting, funding, settlement, fraud rules, disputes, or production network behavior.
Operational controls
Test outcomes, not just the happy-path button.
The scenario set should represent the selected provider, payment method, checkout or form, merchant policy, downstream integrations, and operational owners.
Environment
Confirm the CMS Max sandbox switch, provider endpoint, merchant test account, credentials, keys, and browser scripts all match.
Authorization
Test approved, declined, invalid, timeout, duplicate, amount, billing, AVS, CVV, and token failure behavior where supported.
Capture and hold
Verify immediate capture or held authorization, amount rules, later capture, expiry, failure, and support procedures.
Void and refund
Prove the original transaction reference, gateway eligibility, amount, response, CMS Max state, customer message, and audit history.
Forms and checkout
Test each enabled checkout and payment-enabled form path separately, including validation, retries, receipts, and records.
Downstream systems
Confirm test activity cannot create unintended fulfillment, shipping, inventory, accounting, CRM, tax, or production notifications.
Implementation workflow
Build a test plan that ends in a controlled live acceptance.
Keep evidence for every scenario and name the person who approves the move from sandbox to production.
- 01
Define
List providers, methods, environments, journeys, amounts, customer data, expected outcomes, downstream effects, owners, and evidence.
- 02
Configure
Use test accounts and credentials, enable sandbox mode, label the environment, and isolate real fulfillment and communications.
- 03
Execute
Run success, validation, decline, provider failure, duplicate, retry, reversal, reporting, and permission scenarios.
- 04
Reconcile
Match CMS Max records to the provider sandbox and every connected system, then document gaps and rerun fixes.
- 05
Accept production
Switch under change control, use production credentials, run a small live transaction and eligible reversal, verify settlement, and obtain signoff.
Clear responsibility
A safe sandbox has owners beyond the developer.
Finance, operations, support, fulfillment, and integration owners should know which records are tests and what must never happen downstream.
- CMS Max
- Owns the shared sandbox setting, supported provider endpoint selection, integration behavior, and CMS Max support scope.
- Payment provider
- Owns the test account, credentials, test data, simulated responses, sandbox limitations, documentation, and provider support.
- Merchant project owner
- Owns test scope, participant access, data policy, evidence, defect decisions, launch approval, and rollback.
- Operations and finance
- Own test-order handling, fulfillment isolation, reports, reversal evidence, reconciliation, and controlled live acceptance.
Current references
Use the provider account and documentation as the live source.
Use the documentation for the selected native gateway because sandbox credentials, cards, responses, and limitations are provider-specific.
Payment sandbox FAQ
Resolve the practical questions before production.
Treat sandbox as one stage in release acceptance, not a substitute for a live operational test.
Is Sandbox Payment a standalone CMS Max gateway?
No. The current architecture uses a shared sandbox mode for configured native payment providers rather than a dummy standalone provider.
Can production credentials be used in sandbox mode?
No. Use environment-matched test credentials, keys, scripts, endpoints, and provider test data.
Does a sandbox approval move real money?
Provider sandboxes are designed for testing and do not prove live funding or settlement. Confirm the exact behavior and limitations in the selected provider documentation.
Should sandbox orders trigger fulfillment and customer messages?
Only when explicitly isolated and approved for the test. Prevent test activity from creating unintended real shipping, inventory, service, accounting, CRM, or customer effects.
What should happen before production launch?
Switch under change control, verify production credentials and settings, run a controlled live transaction, test an eligible reversal, confirm settlement and reports, monitor, and record signoff.
Security requires operations
Build the payment test plan before changing the environment.
Bring the gateway account, test credentials, checkout and form journeys, downstream systems, fulfillment rules, refund policy, finance owners, support path, and production acceptance criteria.
Building Relationships with Web Developers and Marketing Agencies that want better results
The world's fastest and most SEO friendly website code.